Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> ReadRowIntoFields Exception
 

Pages: 1
Bugs & Issues
ReadRowIntoFields Exception
Page:1/1 

  Print all messages in this thread  
Poster Message
DaveR
User



Location:

Joined on:
15-Jun-2004 16:37:10
Posted:
43 posts
# Posted on: 20-Feb-2008 17:55:32.  
We continue to see intermittent errors such as this:

Code:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.ReadRowIntoFields(Object[] values, IEntityFields rowDestination, Dictionary`2 fieldIndexToOrdinal)
at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.FetchOneRow(IDataReader dataSource, IEntityFields rowDestination)
at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.ExecuteSingleRowRetrievalQuery(IRetrievalQuery queryToExecute, ITransaction containingTransaction, IEntityFields fieldsToFill)
at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.PerformFetchEntityAction(IEntity entityToFetch, ITransaction containingTransaction, IPredicateExpression selectFilter, IPrefetchPath prefetchPathToUse, Context contextToUse)
at SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.FetchExisting(IEntity entityToFetch, ITransaction containingTransaction, IPrefetchPath prefetchPathToUse, Context contextToUse) at Commissure.Data.EntityClasses.OrderEntityBase.Fetch(Int32 orderID, IPrefetchPath prefetchPathToUse, Context contextToUse)
at Commissure.Data.EntityClasses.OrderEntityBase.InitClassFetch(Int32 orderID, IValidator validator, IPrefetchPath prefetchPathToUse)
at Commissure.Data.EntityClasses.OrderEntity..ctor(Int32 orderID)


We are unable to replicate this or find a pattern. The same code runs successfully 95% of the time.

We are using the latest LLBLGen 2.0 libraries.

At this point I am looking for some ideas on how to debug this issue. I believe it is either an LLBLGen bug, or an ADO.NET bug, or maybe even SQL Server bug, since it implies that the data returned from the server is incomplete.

Any suggestions for how to debug this issue would be appreciated.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37805 posts
# Posted on: 20-Feb-2008 21:24:14.  
As you're using selfservicing, it might be that a multi-threaded issue is the cause. Is this a webapplication? If so, do you share the entities in some shared construct like the Application object ?

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
DaveR
User



Location:

Joined on:
15-Jun-2004 16:37:10
Posted:
43 posts
# Posted on: 22-Feb-2008 17:39:16.  
It is a Windows Forms application, but we do use threads. In these scenarios, however, we are not sharing entities across threads. However, it is possible that multiple threads are accessing the database at the same time, but using their own entity objects. Is this something to be concerned with?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37805 posts
# Posted on: 23-Feb-2008 12:54:50.  
DaveR wrote:
It is a Windows Forms application, but we do use threads. In these scenarios, however, we are not sharing entities across threads. However, it is possible that multiple threads are accessing the database at the same time, but using their own entity objects. Is this something to be concerned with?

In the same application, it shouldn't be a problem, as long as data isn't shared among threads. the object which reads data into an entity is instantiated per call so it can't be shared among threads. It also might be that you share collections, or other objects among threads?

However from looking at the stacktrace, it's not very possible to make this a multi-threaded issue because it's a single-entity instantiation which triggers this fetch action as you can see. However as you didn't paste the trace through your own code, I don't know if this ctor call is in your own code or if this is lazy loading triggered somewhere.

The thing is: this routine is called by the routine which executes the query and fetches the data. it determines the indexes of each field in the query result from the fields used for the query and passes that to the routine. This particular case is from fetching a single entity. Please load the runtime sourcecode in vs.net and check DaoBase.FetchOneRow's code.

There you'll see it calculates the indexes from the fields used for the query. Do you have code in place which produces additional fields for the order entity at runtime? Fieldindexes are static data, so these don't change, never.

Once the indexes are calculated, it passes them to ReadRowIntoFields. This is a simple routine which uses per field the index it has in the row read and with that index it reads the value from that row.

As the error is a hard index error, the only place where that could be thrown in that routine is at line 2048, so when the index of the field was wrong.

Hence my question of multi-threaded usage: if the list of fields passed into FetchOneRow was changed in between calls, this could happen (but that's not the case here).

What you could do is add some guard code to ReadRowIntoFields's sourcecode and run the application with your custom build of the runtime library. The guard code checks on the ordinal being in range of the array. if not, it should log or throw an exception with the field name of the field to fetch and the ordinal which didn't fit as well as the length of the row of data. That could reveal more information about what happens.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.