Is IBX able to save data to the data when network connection is restore again without need to restart the app?I guess that's not possible. Queries linked to a dataset are prepared when the dataset is opened and are associated with the given connection.
a "manual" Workaround could be
1) Check Connected-Property before saving. If True everything OK, if False you have no Network.
2) If 1) is answered False, instead of "saving" implement a "queue" (Could be a StringList with the SQL-Statement).
You would also need a Procedure to try to reconnect back (own Thread?). TIBConnection's Ancestor TCustomConnection offers a published "AfterDisconnect"-Event. You could start the reconnect try from there. You would need a logic to exempt this code, if the User really wants to disconnect.
3) TIBConnection's Ancestor TCustomConnection offers a published "AfterConnect"-Event. If in 2) you reconnect successfully, "AfterConnect" should fire, and you could check if there are SQL-Statements waiting in the Queue
honestly? No Idea. Never used DB-bound controls (never in 20 years of Visual Basic, and never in 4 years of Lazarus), since i want to do the CRUD's on a Database myself (more fine-control).
But i think you're on the right path.
Then the only "fail"-safe method i know of would be to use a local database, which replicates itself to the server if network is availableI think local database is to complicated.
https://www.firebirdfaq.org/faq249/
I think of table in memory that holds all data before it is updated to the database server.And that's different to my proposal of a Queue, how?
I don't know much of Lazarus, perhaps there is a LCL components that could be served for storing temporary data in memory.
I think of table in memory that holds all data before it is updated to the database server.And that's different to my proposal of a Queue, how?
I don't know much of Lazarus, perhaps there is a LCL components that could be served for storing temporary data in memory.
But my question is not that, I want to know whether IBX has capabilities to handle database operations under unstable network connection.I wouldn't know of a component in any language capable of that. It's the programmers job to provide for that eventuality.
I think local database is to complicated.
Not all data needs to be replicated, only the data that are being input / edit by users.That's the core-definition of Replication.
Hi guys,
I have this situations :
- Use IBX for database operations
- Use TIBDataset with CacheUpdate Enabled
I have an TDBEdit, with value = 'abc', then edit its value to 'abcde'
To Update database, I clicked Save button, which codes something like this
That code works OK when network connection is OK, database value updated to 'abcde', but when network connection is lost, Dialog box showed with error message and option to click OK or Abort.
Error reading data from connection
That error was expected, if users click Abort, app closed, if user click OK, app not closed, value of TDBEdit in the screen still 'abcde'.
Problem is, when network connection restored again while app still open/ not restarted again, clicked again button Save still got same error like above.
Is IBX able to save data to the data when network connection is restore again without need to restart the app?
1. In your client systems firebird.conf file set DummyPacketInterval=0. This will avoid timeouts on inactive connections when the underlying network is unstable. However, this will not help drop outs during an update. Could be problematic.
2. Don't use ApplyUpdates or cached updates in general. All this does it make it more likely that you will lose all your updates when a connection fails. Instead, set each dataset's AutoCommit property to acCommitRetaining. This will ensure that every update is written through to the database i.e. minimising the risk of data loss.
3. Add an event handler to your TIBDatabase component to automatically re-open the database after an unexpected disconnection. You will probably want to use Application.QueueAsyncCall in the event handler to queue the re-open to ensure a tidy-up before re-opening. Your re-open procedure should re-open all previously open datasets. They should then open in the state they were in after the last autocommit.
1. Usually, I don't install firebird in client, only supplied my app + fbclient.dll to client.
1. Usually, I don't install firebird in client, only supplied my app + fbclient.dll to client.
2. Back in C++ Builder, always use ApplyUpdates. If I use dataset's AutoCommit, in Master Detail table, wouldn't it be problems when only data in Master table saved, while data in Detail not saved due to some errors?
3. I am able re-open the database with this code
Dba must be closed first (which means lost all data entry/edit from users), otherwise, when tried to saved again, same error about reading connection occur again.
I think we can agree that, there are no build in features in IBX to resume database operations (insert/update/delete) on an unstable network.
The one thing I would suggest is that before you put too much effort into reinventing the wheel you investigate whether any other database backend has something in its client libraries which does this.
Also tried LCL from DevArt, only need to set three properties on the connection component to solve this problem.
Also tried LCL from DevArt, only need to set three properties on the connection component to solve this problem.
More detail please.
However note that anything at the client end is (probably) only a partial fix: a broken connection will still almost certainly abort a transaction irrespective of server type.
MarkMLl
There's a trial version of DevArt LCL, you can try it yourself.
There's a trial version of DevArt LCL, you can try it yourself.
Link please. Not something I'm familiar with.
If this is specifically an LCL thing but still uses the underlying FCL/RTL it might be reportable as a fixable bug or at least wishlist item.
MarkMLl
OK, but that is "for Lazarus" rather than "fixes the LCL"What do you mean? Sorry, I am new to Lazarus, isn't LCL is short for Lazarus Components Library? Is there a different between Lazarus and LCL?
MarkMLl
Also the limited time I can spare to look at the documentation suggests that it doesn't buffer when disconnected... or that only buffers up to the limits of the visual components and then requires a connection before work can continue.
https://www.devart.com/ibdac/IBDAC.pdf (section 4.7, "Working in an unstable network").
At the moment the best way I can see of fixing this in the general case is to use the database-specific LCL components to collect data, copy the data into non-DB components for editing/display, and buffering locally-enetered data using e.g. SQLite subject subject to requirements of sequential fields etc.
MarkMLl
What do you mean? Sorry, I am new to Lazarus, isn't LCL is short for Lazarus Components Library? Is there a different between Lazarus and LCL?
(Sigh) This is not something that fixes a problem in the LCL. It is something that exists in various variants that install onto a Delphi or Lazarus development system. Go read the description.QuoteI don't know if there is a buffer or not in IBDac, so far, never experienced data lost when using this components in C++ Builder.
There isn't. Read the docs.
Come on man, you're the one who threw that particular hat into the ring: it's your job to know what it actually does.QuoteFor now, I still thinking whether to use Sqlite or sql scripts as a buffer. Perhaps sql scripts is simpler than Sqlite.
Both are viable, but I'm not sure how you'd get an SQL script out of a DB-aware component. Use components as a front-end for a local SQLite database and "all" you'll need will be something non-graphical that detects when the backend is contactable (using ping etc.) and transfers the local data in the context of a pair of nested transactions.
MarkMLl
If I use Sqlite, I don't know, perhaps for every datasets, there must be a correspondence Sqlite tables. If I have 4 datasets in a form, I have to create 4 Sqlite tables for buffer.
With sql scripts, only series of strings for all datasets.
I can store these strings onto Dbstring grid, then send them all to database server.
Back in C++ builder, I have functions that can convert values stored from any datasets to sql scripts, plan to convert those functions to Lazarus functions.
Remember that a ping is not sufficient.
Ping the machine, machine answers „ok, I’m online“, but the db-server/service is not running
Certainlt looks worth doing, but will that capture locally-entered data?
MarkMLl
Yes, but at that point an attempt at reconnecting will fail. A ping is a good first step provided you know the IP address, some schools of thought have it that you should do a database server name lookup manually so that connections are not also at risk of failure due to a failed DNS server.
There's other useful tests, but depending on OS things like finding the current gateway and next-hop router can be surprisingly tricky.
MarkMLl
Please keep us updated.
MarkMLl
This thread does seem to be going off at a tangent to the original post.
What you need to decide is what are you trying to achieve in terms of recovery from database connection loss. Broadly speaking, there are three levels of response to this event:
1. Let the user work it out.
This is a minimal approach and ok for basic applications and when connection loss is rare. All you need to do is to report the exception and exit the program. The user is then responsible for restarting the program, working out what data was lost, if any, and restoring any important changes. The users task is simplified if updates are committed soon after they are made, even auto-committed as then they only have to look at the last thing they did. Caching too many updates before applying/committing them just makes the problem worse.
2. Assisted Restart
On connection loss, your program closes down the connection (usually a forced disconnect) in order to restore itself to a known state. It then re-opens the connection, reopens the datasets that were open when the connection was lost and tells the user that some data may have been lost. Again, it is the user’s responsibility to work out what was lost, etc.
3. Journaling
This is where you pre-empt the problem by recording, in some journal file, every SQL Update, Insert and Delete statement, the transaction they were executed under and when each transaction starts and is either committed or rolled back. The journal file can be no more than a text file with one statement per line,
When a connection is lost, your program does a forced disconnect and re-opens the connection, It then looks in the journal for any uncommitted transactions and, for each one, starts a new transaction with the same parameters, and executes the recorded SQL statements in the same order as they were journaled and under that transaction. The datasets are then reopened and the user should see exactly the same state as when the connection was lost. Note that the recovery transactions are not committed. That is because the view is restored to exactly the same state and it is up to the user to decide whether to commit or rollback.
The problem with the above comes if the connection is lost when committing a transaction, You then do not know if it was committed or is still in limbo. You need to save some information server side with each transactions that allows a simple way of determining whether the commit succeeded. This could be as simple as a last transaction identifier recorded by an update statement that is executed under the transaction.
IBX does not include an actual journaling capability – although this is an idea for a future release. However, it does include TISQLMonitor. This allows you to snoop on every transaction and sql statement and use this to record to a journal file.
or point your browser at
https://svn.mwasoftware.co.uk/viewvc/public/ibx/branches/journaling/
and click on "Download Tarball" to get an archive of the experimental version.
or point your browser at
https://svn.mwasoftware.co.uk/viewvc/public/ibx/branches/journaling/
and click on "Download Tarball" to get an archive of the experimental version.
Downloaded and tried to unpack, got an error, see attachment