At 03:52 AM 17/03/2008, you wrote:

>No, I don't mean on server side. That is OK.
>
>On client side TIBTransaction should somehow keep track of the queryes sent using it, and avoid these conflicts.

Here is the architecture:

-- Any Delphi data access components, as with all programming language interface layers, are wrappers for the many functions exposed by the engine's API as the client library

-- The API is the window to the server's soul. It is designed to allow client programs to make legal requests and to handle the responses from the server as transparently as possible

-- Beneath the API is the network layer. It cannot be controlled by either the server or the API (although direct connect on POSIX Classic and IPServer local on Windows are special cases)

-- A "connection" consists of a number of physical and logical pieces, including a logical network "socket" at each end of it. The life of a connection depends on the existence of both of these sockets behaving normally. This provides the both the physical context for the transport of messages between the API and the server and the logical context by which the client identifies itself to the server and the server is accessed by the client.

-- Within the context of a connection are transactions. A transaction is the property of that connection. (A transaction may be the property of connections to more than one database - that requires a special context that is handled differently)

-- Within the context of a transaction are statements. Statements execute within the context of a transaction.

-- In your Delphi data access layer, statements are wrapped by various kinds of component classes (such as TIBQuery).

So, you see, you cannot take an IBQuery object that belongs in the context of one transaction and refer to it in the context of another concurrent transaction. And you cannot take an IBTransaction that belongs to the context of one connection and refer to it in the context of another connection.

The db engine itself has no control over a client program that breaks this layering. If you attempt to do so, by trying to use one connection context for multiple inner contexts concurrently, you will cause memory access violations.

So, you see, it is not about whether the Delphi components are "thread-safe" or not but about whether you use them in a way that is thread-safe, i.e., in a way that does not break the intrinsic layering model.

Some programming interface layers do provide ways for your application to monitor each level of context discretely and take certain actions according to the results. IBO, for example, reflects the engine's layering model by allowing you to wrap the entire layered structure inside a session component and you can apply timeouts, refer to engine messages and access many other context-sensitive attributes at session level. Less sophisticated sets, such as IBX, don't provide these capabilities.

./heLen