The FB 2.5 client libraries are "thread-safe" according to http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html#rnfb25-engine-threading 

and on this page: "Tracker reference CORE-707.

The client libraries, including the embedded one, can now be used in multi-threaded applications without any application-level synchronization."

 

"Thread-safe" has aspects I have not had to deal with till now.Example:

Its time for me to use running a stored procedure in my FB/IBO program in a separate thread. I want to perform a task on the database and not wait for the task to complete. So having a new thread to achieve this seems a good way to proceed. By not using an isql script I'll keep maintenance tasks inside the program. I'll not have to set up a scheduled isql task at several sites.

I have now one task I want to run in a parallel thread: send a request to the DB server to perform a stored procedure when the first user of the day logs into the program. I may think of more tasks suitable to run in a separate thread, to keep response to user as fast as possible.

Rob has suggested I create a TIB_Session and its Connection, transaction and dsql in the Execute event of the new thread and helpfully provided some indicative code. 

I am wondering if this is necessary. I am not confident I grasp the issues involved with multi-threading in IBO so I ask this. Does anyone see a problem on making a separate datamodule with its own TIB_SESSION, making it in the main thread startup and using it as the connection for a separate thread? The separate thread would be made when needed and freed when complete. The datamodule would be present for the program lifetime. This looks simpler than creating the TIB_SESSION and connection each time a separate thread is wanted.

Thanks,

Russell