Recently, I promoted SQLRelay <http://www.firstworks.com> a bit: as a means to connect from Unix to an MS SQL Server. I now have more experience that I want to share: SQLRelay seems quite complex and very sensible to disruptions. It consists of a set of processes that communicate via shared memory and synchronize via semaphores. These communication resources are allocated and initialized by the first process that needs them. This works fine when everything goes well. However, when there are faults causing a process to abort, the semaphores are in an inconsistent state and almost surely, you will get a deadlock. As SQLRelay is very quiet, the deadlock may not be obvious. In case of a deadlock, it is necessary to delete the communication resources manually (using "ipcs" and "ipcrm"). SQLRelay has problems with processor architectures that have alignment requirements (such as e.g. SPARC): When writing the communication ports into shared memory, it may make a word access on a byte aligned address. This will give a SIGBUS exception when the processor does not support such accesses. The process dies and the semaphores become inconsistent. Rudiments, a base of SQLRelay, has some "short read issues" (at least when used together with SQLRelay): It assumes that when a writer writes an n byte message, then the reader will be able to read this entire n byte message in a single read. But this is not guaranteed by Unix. It may split the message in many subpackets. SQLRelay raises an error in this case: something went wrong. You can choose from about several dozen possible reasons. When it does, it seems that some data structures are not in a clean state, such that destructors can enter infinite loops, crash or release indeterminate memory. I will package some patches addressing some of the issues above and submit them to Firstworks. Dieter