Wow thanks for that Helen

> So it is bumping into "something nasty" (a corrupt record or an out of memory condition) when trying to retrieve the set.
>
> If your r/o transaction is long-running, make sure its isolation is Read Committed.
>
> And, since you are using IBO, make sure the app is compiled with IBO 4.8.7.
>
>
>

I believe all my transactions in the web service are very short
running. However my other app may have longish transactions i.e. start,
copy 15000 records to / from the other DB. I will investigate further.
Counld Ctrl_Alt _Del the other app cause this issue (I had assumed the
current transaction would roll back), the other app has been stopped in
this way after it appears to lock, however we had assumed it was locking
because of the gds error.

> Release versions so far of v.2.0.x don't handle an out of memory condition properly - the best the engine can do under these conditions is to throw an internal gds consistency check error and crash. It is fixed in the forthcoming v.2.0.5. The test builds should be available within the week.
>
>

The machine now has 2GB ram (the old machine had 256mb !). I am not
seeing memory usage in task manager go much over 300MB. Would that rule
out the out of memory situation?

> But, if this is the source of the problem, then the fix won't *prevent* an out of memory condition. I'd want to scour those triggers and find whether there are rogues there that are recursing infinitely. Another thing that can blow up memory is repeatedly hitting the same record with updates inside the one uncommitted transaction. This becomes likely if you have After triggers that are targetted at a small set of "bottleneck" records.
>
>

Will go through all triggers with a fine tooth comb !!!

>> I plan to try running just the Web side of the app for a time to see if
>> this app is the culprit.
>>
>
> If out-of-memory turns out to be the source of the problem, then it's probably also the source of the kind of corruption that you're encountering - the kind that gfix can find and fix (i.e., logical damage like broken relationships) - especially if the application code is not totally careful about task atomicity.
>
> If the Web app is doing updates, etc., then disabling the local application won't disable problem triggers. It might mitigate the problem to the degree that you stop getting a crash condition in the engine. In that case, disabling the local app simply masks the problem.
>
> Don't overlook the fact that a Win32 process can't use more than 2 Gb of RAM at any point. SS is one application operating many threads. If your web app is also threading within its threads then it's likely to be eating lots of resources at times...with this installation it could be just a case of too many straws on the camel's back...too many connections in the pool, perhaps?
>
>

As 2.0.1 isn't reporting out of memory situations correctly would
watching task mgr be enough to rule out memory as an issue?

>> Does anybody have pointers for where to start looking?
>>
>
> With trying to be too boring...have you run MemTest over the RAM in the new machine?
>

The machine is physically remote (in another country than me - your
home, Australia). I have remote access but will need to orgainise
someone on site to do the memcheck. As it is a different machine I
doubt it is memory related, but you never know.


Thanks
Rob