0

Delphi Xe2 + ZeosLib 7.0.3 Stable + Firebird 1.0

I am doing updates to the several tables and data is retaining on memory. It is not reflected on the database in a way that other applications can see it.

I have tried using auto-commit only and did not work.

I have also used explicit transaction control, ZConnection.StartTransaction and ZConnection.Commit and did not work either.

I am updating data in a webserver created on delphi with Indy httpServer. I get post requests then act reading or updating the database. The connection is stateless, however it is maintained a list of client apps that are connected and an a instance of ZConnection for each client to have isolation since the requests are threaded.

Besides that I am having the problem of not saving having only one client connected and doing one request per time, no overlapping or re-entrance.

I need to hear advice on using this scenario of Firebird, What I should do to make the commit work.

Arioch 'The
  • 15,799
  • 35
  • 62
Eduardo Elias
  • 1,742
  • 1
  • 22
  • 49
  • Firebird 1.0 ??? what forces you to use this ancient and buggy version... Well... 1) what are parameters for reading transactions? 2) what are parameters for updating transactions 3) "I have also used explicit transaction control" this looks like most of your app is written with auto-transactions of unknown mode and unknown life timespan. In this case most probably your application still uses them, you made explicit control on some minority of procedures, but most of the codeflow still does not use them. 4) what is the OS and what are the connection strings for all the programs? – Arioch 'The Jun 14 '13 at 15:28
  • *I am having the problem of not saving having only one client connected and doing one request per time* - it seems you do all your processing in a single thread for all clients. then the processing will be... ahem... singlethreaded. For middle load you should make your program multithreaded, using something like OmniThreadLibrary thread pool. And you would need Firebird with mt-aware client library. Maybe swwitching from ZeosDB to more light-weight UIB would help too. For heavy-loaded apps you'd better switch to actor-based approach (like in OTL pipeline). – Arioch 'The Jun 14 '13 at 15:33
  • Also read "Datasnap performance analyzis" articles. Perhaps you'd be able to embrace Synopse mORMot approach to servers. – Arioch 'The Jun 14 '13 at 15:34
  • @Arioch'The It is a shame, i know, to be using this firebird 1, but no option for now. This database is in use by POS software, they have thousands of customers. What I am trying to do is to add android devices to their system. I have created a webserver with Indy and supply the Http get requests with JSon data from the Firebird database. I made something like that with firebird 2.5 and I had no problem at all. I am not experienced with firebird neither ZeosLib. I was going auto-commit, mostly of the code is only select, i have 4 places where a insert or update happens. – Eduardo Elias Jun 14 '13 at 16:08
  • @Arioch'The for these few places I am using starttransaction and commit. I tried ApplyUpdates after ZQuery. Everything is done using Zconnection and Zquery. Firebird is running on windows 7 with the POS system that works fine with it. My webserver is runnig on a windows Xp (virtualbox dev machine) all SQL commands are processed fine. "just" do not save back to the database. For my webserver it shows up as saved transactions. It is singlethreaded because I am not testing it with many clients at same time, but it should work. But tipical scenarios is less than 10 client connected. – Eduardo Elias Jun 14 '13 at 16:13
  • Who knows... we recently were solving a customer's problem and found that while using FB 2.1 he used database file of Interbase 5.6 format. And it more or less worked. I mean, try updating POS or two to later FB, maybe it would be compatible enough. Then... go Firebird forums and ask, perhaps GDS32.DLL of some last versions, thread-safe, can be used to connect to FB 1.0 using fall-back legacy "wire protocol". While discouraged and non-supported it has chance to work. What about Android - Jaybird works directly, without using GDS32, and recently they started porting to Android. 2-tier APK ? – Arioch 'The Jun 14 '13 at 19:58
  • Now, IB/FB bening versiones server, the classic mode of work was bi-transactional (or two connection, if DB lib (like dbExpress) lack support of several concurrent transactions within single connection). Then... why Zeos ? You say you're bound to FB1, than means you do not need any non-FB servers. Then why bother all those extra indirections, only adding more bugs and less control ? use FB-targeted libs, like IBX, UIB or FIB+ or IBObj. You said that IBX works better than ZeOS and ZeOS 7 was terrifically painful version, delayed by years and that implies buggy. Switch the lib! – Arioch 'The Jun 14 '13 at 20:03
  • Oh, damn! bi-transactional mode. Try to separate reading and writing. Reading transaction(or connection+transaction) should go in read-only read-commited mode. It even may be never closed, using CommitRetaining instead of Commit, or may be long-time transaction. But read-only is mandatory flag for this and read-committed is mandatory for seing the changes. Changing should be done via a separate short "bursts" of read-write snapshot(serialized-read) transactions, those should be as short as possible for many reasons, one of them is that reading t-s would only see the change after rw-t committs – Arioch 'The Jun 14 '13 at 20:08
  • And in general, working with early pre-Yaffil FB on modern windows, try to avoid "local" protocol. Ensure you connect via TCP/IP even if client and server runs on the same machine. Also try not using GDB file extension. – Arioch 'The Jun 14 '13 at 20:09

0 Answers0