Is it possible to open a query, select the data, transfer it to a buffer, cut the connection, work with the query and data, reconnect and then 'Apply Updates'.
The reson is, the application have to work on some windows tablett pc. Sometimes the WIFI connection is bad and not working. The datastructure is simple and able to be cached. The problem at the apply updates time can be handled by code.
In Delphi 7 times with ADO (so i remember correctly) it was possible if i set the connetion in the query to nil without deactivating. And the connection could be inactive from now. The query was working too. To reconnect, only bind the new reactivated connection back to querry and apply all updates (and handle the problems).
It this possible with Lazarus Zeos ?
Andreas
Buffered Dataset (possible to cut connection to server)
Moderators: gto, cipto_kh, EgonHugeist
-
marsupilami
- Platinum Boarder
- Posts: 1918
- Joined: 17.01.2011, 14:17
Re: Buffered Dataset (possible to cut connection to server)
Hello Andreas,
Zeos cannot work in an environment like this. Zeos needs a stable connection to the database. In my opinion you have two possibilities:
Jan
Zeos cannot work in an environment like this. Zeos needs a stable connection to the database. In my opinion you have two possibilities:
- Copy the data to some memory dataset (TBufDataSet?) and find a solution to copy modifications from there to the server.
- Use a local database (like Firebird in its embedded version) and synchronize data with the main database. I have come up with a solution for small databases to do the synchronization but it has quite some shortcomings. I could share that with you if you want to.
Jan
Re: Buffered Dataset (possible to cut connection to server)
Thank you for your offer, i accept. So i can compare some solutions.marsupilami wrote:I have come up with a solution for small databases to do the synchronization but it has quite some shortcomings. I could share that with you if you want to.
It is not a problem to this for the actual project, because it is so simple with the data and i can deal with text or xml. But if the projects are growing ....
Andreas
Re: Buffered Dataset (possible to cut connection to server)
@marsupilami pthank you for the offer of sharing code. How can we do this ?
Andreas
Andreas
-
marsupilami
- Platinum Boarder
- Posts: 1918
- Joined: 17.01.2011, 14:17
Re: Buffered Dataset (possible to cut connection to server)
Hello Andreas,
if we do it I will have to do some work that I already wanted to get done. I will have to slit out the code into a separate package that I can distribute. I would then upload that either into the Zeos SVN or create a new project on github.
But currently the code is not very intelligent. I would like to improve it but I don't have the time to do so. Currently the code more or les simply walks through all tables and tries to identify changes based on the data it finds in the tables. The code is agnostic to things like stored procedures and primary keys. So this means it will read all table data for each synchrnisation run. It doesn't care about foreign keys. Foreign keys will most probably break the synchronisation. Rows are identified by their primary key, so you need to have a primary key on every table. Also the primary keys must not change. Your databases - or at least the tables that you want to synchronize - must have the same structure. The code is inspired by the three way synchronization that products like subversion use. Since databases don't keep old versions, like subversion does, the code requires two databases on the synchronization client. One that you work with (your data) and one that has the data like it was when it was last synchronized (base data). Basicly changes are found by comparing the base data vs. your data and the server (their data). You have to ensure that all three databases always have the same stucture before you synchronize. And finally - synchronization is only done on request. For a scenario like you pointed it out, I would suggest to have two progams on the client. One that does the work and one that synchronizes the data.
If you think, you can live with those restrictions, let me know and I will start to sort out things.
With best regards,
Jan
if we do it I will have to do some work that I already wanted to get done. I will have to slit out the code into a separate package that I can distribute. I would then upload that either into the Zeos SVN or create a new project on github.
But currently the code is not very intelligent. I would like to improve it but I don't have the time to do so. Currently the code more or les simply walks through all tables and tries to identify changes based on the data it finds in the tables. The code is agnostic to things like stored procedures and primary keys. So this means it will read all table data for each synchrnisation run. It doesn't care about foreign keys. Foreign keys will most probably break the synchronisation. Rows are identified by their primary key, so you need to have a primary key on every table. Also the primary keys must not change. Your databases - or at least the tables that you want to synchronize - must have the same structure. The code is inspired by the three way synchronization that products like subversion use. Since databases don't keep old versions, like subversion does, the code requires two databases on the synchronization client. One that you work with (your data) and one that has the data like it was when it was last synchronized (base data). Basicly changes are found by comparing the base data vs. your data and the server (their data). You have to ensure that all three databases always have the same stucture before you synchronize. And finally - synchronization is only done on request. For a scenario like you pointed it out, I would suggest to have two progams on the client. One that does the work and one that synchronizes the data.
If you think, you can live with those restrictions, let me know and I will start to sort out things.
With best regards,
Jan
Re: Buffered Dataset (possible to cut connection to server)
I will have the problem of sync with very simple tables (yet).
I have looked inside of some file sync (unison, tiOPFsync) and the ideas behind. Indeed i need those feature in the future more and more, i think. But all my knowledge is filebased, not DB. I understand your concept, but i didnt kow, if it is oversized for my (aktual) project or not. But if want/can to spend your time :-) i will it do too.
Zeos SVN or Github, both are ok.
Andreas
I have looked inside of some file sync (unison, tiOPFsync) and the ideas behind. Indeed i need those feature in the future more and more, i think. But all my knowledge is filebased, not DB. I understand your concept, but i didnt kow, if it is oversized for my (aktual) project or not. But if want/can to spend your time :-) i will it do too.
Zeos SVN or Github, both are ok.
Andreas