Hello, i got "Index was outside the bounds of the array" when executing query on a specific entities, the stack trace is not clear, also its not related to our code(all in dataobjects.net code). when using SQL Profiler the query return records but in the application code it throws the above mentioned exception, so i need to know if its a bug in dataobjects.net or its in my code, and if so what is the actual error as the exception doesn't mention a clear error(note we just upgrade from version 4.3.3 to version 4.6).

here is the stack trace and error message:

Error Message:Index was outside the bounds of the array.
Stack Trace: at Xtensive.Orm.Linq.Materialization.MaterializationHelper.CreateSingleSourceMap(Int32 targetLength, Pair`1[] remappedColumns)
 at Xtensive.Orm.Linq.Materialization.MaterializationContext.GetTypeMapping(Int32 entityIndex, TypeInfo approximateType, Int32 typeId, Pair`1[] columns)
 at Xtensive.Orm.Linq.Materialization.ItemMaterializationContext.Materialize(Int32 entityIndex, Int32 typeIdIndex, TypeInfo type, Pair`1[] entityColumns, Tuple tuple)
 at lambda_method(Closure , Object[] , Tuple , ItemMaterializationContext )
 at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
 at Xtensive.Core.EnumerableExtensions.<Batch>d__20`1.MoveNext()
 at Xtensive.Core.EnumerableExtensions.<ApplyBeforeAndAfter>d__28`1.MoveNext()
 at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()
 at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
 at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

asked Feb 03 '13 at 05:51

ahmad%20emad's gravatar image

ahmad emad

Hello Ahmad, it's hard to say with provided information. Is it possible to see your original query and part of your model that relates to that query?

(Feb 04 '13 at 03:09) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Hello Denis, should i send the model assembly and its dependent assemblies to support@dataobjects.net?

(Feb 04 '13 at 06:19) ahmad emad ahmad%20emad's gravatar image

I think this wouldn't help too much, because error occurs when actual data is read from the database.

What you could do is to check that TypeId-s are assigned correctly in the database. When you're reading entities TypeId column is used to determine actual type of the entities. If for some reason TypeId is incorrect querying will likely fail with similar errors.

To check TypeId you could execute translated LINQ query manually (i.e. get it from SQL Profiler and run in Management Studio) and then check if TypeId in the result matches with values in Metadata.Type table.

(Feb 04 '13 at 06:38) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

hello Denis, i tried your suggestion and indeed the query returned a wrong type id (the type id returned within the select statement assigned to another type in metadata.type), but i don't know why that happened and how to solve it. also after we returned back to release 4.3.3 the problem hasn't solved(for a specific databases).

(Feb 10 '13 at 03:51) ahmad emad ahmad%20emad's gravatar image

Let me explain some details about TypeId handling in DataObjects.Net. TypeId is used to uniquely identify particular persistent type. Metadata.Type table contains mapping between type names and TypeIds. This table is only touched during upgrades. When you build domain with Recreate mode it's fully rewritten with new values. When you build domain with Perform or PerformSafely mode this table is fully cleared too, however TypeIds for existing entities are preserved.

(Feb 10 '13 at 04:51) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

For regular operation (i.e. Validate) DataObjects.Net will cache Metadata.Type contents and use that for providing TypeIds for entities you create and getting type of entities loaded from database.

(Feb 10 '13 at 04:51) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

It's worth mentioning that there is no guaranty that two databases will have the same TypeId for the same type. It's easy to get into such situation. Suppose we build domain with single type A. It gets first TypeId (100). Then we add type B and upgrade database. B would have TypeId=101. On the other hand if you start with single type B it would have TypeId=100. So the first possible reason is importing data from the other database without adjusting TypeId.

(Feb 10 '13 at 04:52) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Another possible reason is recreating database schema while the other domain operates on the same database. After recreate TypeIds might be different thus if second domain creates new entity it might provide it incorrect (i.e. not conforming to Metadata.Type) TypeId. As far as I remember you had issues with random schema recreates so incorrect TypeIds might appeared after such recreate.

(Feb 10 '13 at 04:52) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

To fix the problem you could simply change values in TypeId column for the tables in question to match values in Metadata.Type.

(Feb 10 '13 at 04:52) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Hello Denis, sorry for being late in my replay. this problem exists only after upgrade to release 4.6, then it continued even after we returned back to release 4.3.3, but we are going to do your suggestion and complete testing the application on the new release, then inform you with any problem appear, thanks

(Feb 13 '13 at 05:05) ahmad emad ahmad%20emad's gravatar image
Be the first one to answer this question!
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA