We have a multithreaded app written in Clarion 9 (win32), running on several win 2012 64 bits r2, connecting to Firebird 3 (latest build) via ODBC 32 bits (latest ODBC). We are experiencing a rare propblem, that happens not very often. The issue is as follows:
The application does not use "begin transaction and commit", so we let the database commit automatically after a write process, we read the table from another thread inside the app or from another app inside the same OS session, and the data is not there. Of course after a few seconds (or milliseconds) the data is available. Our concern is that we have a sequence of code that assume whatever was written 5 lines above is already available for reading, but it is failing every so often. One solution we are considering is to use "explicit" begin transaction and commit instead of implicit, any thoughts? (in the past, when firebird was on version 1.5 or 2) we tried to use explicit transactions and the system would lock up every 20 minutes... probably deadly embrace, but we believe it was not related to the application itself, we attributed at the time to a possible bug somewhere betweeen the ODBC or the Firebird engine because the same app running against another DB engine would not lock up. Any suggestions? Cheers, Fabian
