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 emad
26●29●29●31
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?
Hello Denis, should i send the model assembly and its dependent assemblies to support@dataobjects.net?
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.
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).
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
Recreatemode it's fully rewritten with new values. When you build domain withPerformorPerformSafelymode this table is fully cleared too, however TypeIds for existing entities are preserved.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.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.
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.
To fix the problem you could simply change values in TypeId column for the tables in question to match values in Metadata.Type.
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