> Note that for the server to use shared memory only makes sense if
> either
> - the server itself is implemented as several (more than one)
> communicating processes, or
> - its clients *also* use shared memory.

The Ingres installation is a set of processes ... it uses shared
memory for the locking system and other internal resources, and also
the transaction logging system, as well as for an internal table cache
which can be quite large, if you use multiple dbms servers. The
Ingres client software is completely independent of the dbms server,
using tcp sockets for all "client/server" communication, even if the
client software is local. The dbms server can be remote, which of
course rules out any possibility of using the dbms shared memory.

> Whether this is due to a bug in the server (provides "wrong" answer),
> or in the clients (which do not anticipate all possible answers),
> is hard to tell without more details.

I understand how the possibility of corrupted data sent back from the
server would look like a likely possibility based on the symptoms,
but, although I don't completely rule it out, there are reasons to
believe it is unlikely.

Today I opened an issue with Ingres Corp tech support, since the user
app is based on Ingres development tools. They of course want a test
case, which is almost impossible based on the spurious nature of the
error, but hopefully we will be able to get them some diagnostics
which may aid in discovering what is going on.

Thanks for your help!

Regards,

Jim