I've been looking around for some kind of known issue or something, but can't find anything. Here's what I'm experiencing:
I have a table with about 50,000 rows. I open several connections and use a command to ExecuteResultSet against each command, with CommandType.TableDirect, CommandText set to the name of the table, and IndexName set to various indexes. In the end, I have several SqlCeResultSet instances which are then maintained for the life of the AppDomain.
In a loop, I call SqlCeResultSet.Read() on one of the instances, and if it returns false, I call SqlCeResultSet.ReadFirst() - essentially creating a circular pass through the result set.
In a Visual Studio debug session, this approach goes swimmingly for a short time, and then after a successful Read(), I'm pegged with an InvalidOperationException (text: "No data exists for the row/column") for a column which was succesfully read on the previous Read(). If, in the immediate window, I call SqlCeResultSet.Read() again on the result set instance, the Get methods work as they had been in the previous reads.
It seems like the internal state of the ResultSet is getting corrupted somehow, but it is opaque to me. Any insights on why this suddenly throws this exception?
Well, the way around this, apparently, is to keep trying the operation until it succeeds. I have a governer on this repetition, and I've never had a problem with setting it to 5 - so it apparently succeeds after 5 or fewer retries, at least in my testing
|||I got this error when I was using the SqlCeResultSet.Seek().
Use a breakpoint on this method to see what happens internally to the SqlCeResultSet
The values are restored once a read() is done, but after the seek and before the read is performed, the fields are unintelligible.
In other words a SqlCeResultSet.Seek() should always be followed up by a read of some kind.
No comments:
Post a Comment