Hmm.. well, I can't tell much from this; Sorry. Do you log the call stack
when you have unhandled exceptions? This might help in diagnosing the problem.
-Brock
DevelopMentor
http://staff.develop.com/ballen
I guess the answer to if we log the call stack for unhandled exceptions is no
(I'm not sure how to do that).
We email the exception info to system admins when we catch an error. That's
what I included in my original post.
This morning we identified the exact line of code that's throwing the
exception:
ldrStoreTills = ldtTills.Select(lsFilter, lsSort)
It's happening when we invoke the Select method of our DataTable object.
We added code to our exception handler to include the contents of the
lsFilter and lsSort varibles to make sure we're not passing invaid or empty
arguments to the Select method.
We have checks in the method that retrieves the DataTable from cache to make
sure it is a DataTable object, it actually has rows in it, and the HasErrors
property is false. I put a page out on the site that lists these properites.
I went to it when our app was throwing errors and all these properties looked
normal. However the cache wasn't searchable (apparently).
Would you have any thoughts as to why the Select method on the datatable
would be throwing an exception?
Or do you think the main problem is that a 50,000 row data table is just to
much to keep in cache?
One last question: When our code gets the DataTable object from Cache, and
puts it in a DataTable variable, is this a copy of the DataTable in Cache, or
a reference to the actual cache object?
Thank you for your thoughts.
Keith
> Hmm.. well, I can't tell much from this; Sorry. Do you log the call stack
> when you have unhandled exceptions? This might help in diagnosing the problem.
[quoted text clipped - 139 lines]
> >>> Thank you,
> >>> Keith F
Brock Allen - 03 Apr 2005 19:00 GMT
> Would you have any thoughts as to why the Select method on the
> datatable would be throwing an exception?
Hmm, yeah looking back at the callstack you provided from the first post...
the exception isn't that the DataTable is null, it's further down... so yeah,
hard to diagnose in the bowels of their code.
> Or do you think the main problem is that a 50,000 row data table is
> just to much to keep in cache?
Well, my sense is that the DataTable wasn't designed for this; Hundreds,
maybe a couple of thousand rows, but 50K seems like you're pushing the envelope.
I've not done a ton of stress testing on the DataTable to know what it's
breaking point is though, so this is all just my sense of things not backed
by any hard data or testing. So, YMMV :)
> One last question: When our code gets the DataTable object from Cache,
> and puts it in a DataTable variable, is this a copy of the DataTable
> in Cache, or a reference to the actual cache object?
It's a reference back to the same object in the cache.
> Thank you for your thoughts.
NP -- sorry I've not been more helpful.
-Brock
DevelopMentor
http://staff.develop.com/ballen
Ben Strackany - 26 Apr 2005 15:28 GMT
Maybe try creating a new DataView off of the DataTable after you pull it out
of cache, & using that DataView to access the data? Seems like some parts of
the DataTable are getting killed off.

Signature
Benjamin Strackany
http://www.developmentnow.com
> I guess the answer to if we log the call stack for unhandled exceptions is no
> (I'm not sure how to do that).
[quoted text clipped - 171 lines]
> > >>> Thank you,
> > >>> Keith F