[SOLVED] Editing values in DBGrid lazarus / 16-Databases ---------------------------------------------------------------------- Elmug · 2012-07-20 04:07 Hi everyone, Doesn't editing values in DBGrid already is editing the local dataset? If so, do we still need "ApplyUpdates"? Of course, ultimately, I'd issue a 'CommitRetaing' for actual database storage. Meaning I am not sure of what "ApplyUpdates" does exactly. Thanks for helping out. ---------------------------------------------------------------------- taazz · 2012-07-20 05:30 If you are talking about SQLDB then think of it like this you edit data in memory inside your application before destroying the form or dataset you call the applyupdates method which in its turn will walk down all the rows in the dataset and if they have changed data it will create an update or insert sql statement and execute it on the data server. This pushes the data back to the server. After you have pushed the data back to the server you need to inform the server that you are done with this transaction and to make the data available to other transaction so you call the transaction.commit or commitRetaining. ---------------------------------------------------------------------- Elmug · 2012-07-20 05:40 Quote from: taazz on July 20, 2012, 07:30:11 amIf you are talking about SQLDB then think of it like this you edit data in memory inside your application before destroying the form or dataset you call the applyupdates method which in its turn will walk down all the rows in the dataset and if they have changed data it will create an update or insert sql statement and execute it on the data server. This pushes the data back to the server. After you have pushed the data back to the server you need to inform the server that you are done with this transaction and to make the data available to other transaction so you call the transaction.commit or commitRetaining. Thanks Taazz, "Are you talking about SQLDB?" -> I am using SQLite3 now and plan to move also to PostgreSQL. This is a very good explanation. I just would appreciate what I believe is meant, that even though the data is pushed to the server with ApplyUpdates, if CommitRetaining is not done, then it would be the SERVER which would just discard the changes? If so, can I do several ApplyUpdates, like maybe 3 or 4, and have the Server do make them permanent with just one Commit, or CommitRetaining? Thanks for helping! ---------------------------------------------------------------------- taazz · 2012-07-20 05:53 Quote from: Elmug on July 20, 2012, 07:40:49 am Thanks Taazz, "Are you talking about SQLDB?" -> I am using SQLite3 now and plan to move also to PostgreSQL. This is a very good explanation. I just would appreciate what I believe is meant, that even though the data is pushed to the server with ApplyUpdates, if CommitRetaining is not done, then it would be the SERVER which would just discard the changes? If so, can I do several ApplyUpdates, like maybe 3 or 4, and have the Server do make them permanent with just one Commit, or CommitRetaining? Thanks for helping! I do not use SQLite my self so I do not know how the transaction is handled by the library. In general a Server transaction is there to "protect" your data and to force various rules on them so you can have as many "data pushes" as you want before calling commit or cancel I'm not aware of any limitations and if there are any they are imposed by the server so you have to read the servers documentation. ---------------------------------------------------------------------- BigChimp · 2012-07-20 07:04 FYI, SQLDB are the FPC/Lazarus built-in data access components that can access PostgreSQL, SQLite, Firebird etc. An alternative for that would be Zeos, that can also access Firebird, etc. ---------------------------------------------------------------------- Elmug · 2012-07-20 07:21 Quote from: taazz on July 20, 2012, 07:53:27 amI do not use SQLite my self so I do not know how the transaction is handled by the library. In general a Server transaction is there to "protect" your data and to force various rules on them so you can have as many "data pushes" as you want before calling commit or cancel I'm not aware of any limitations and if there are any they are imposed by the server so you have to read the servers documentation. Thank you, Taazz. I appreciate this good reply and will take it from there. I read SQLite3 was ACID compiant, but it is a small case and may have limitations that I then need to learn about. My question, though was more of a theoretical one (but for getting basis for likely use), so on the more robust databases, I gather the answer is a qualified "yes, only ONE commit can take care of several ApplyUpdate's". I feel I do have much better grasp of what is happening on a transaction, much due to your kind help. ---------------------------------------------------------------------- Elmug · 2012-07-20 07:29 Quote from: BigChimp on July 20, 2012, 09:04:03 amFYI, SQLDB are the FPC/Lazarus built-in data access components that can access PostgreSQL, SQLite, Firebird etc. An alternative for that would be Zeos, that can also access Firebird, etc. Thank you much, BigChimp. Yes, I am aware that the default database components can open Postgres. I tried Postgres first and was happy, but decided to learn with SQLite3 as it is easier in that it has local files that I can just copy to folder2, folder3 when I get to a certain level, and then do changes to the code as I keep learning, while leavin Folder1 when it is working to a point, as a reference, and so forth, to try more things I want to include. I read about Zeos, and would try it later; and that it has some components that default Lazarus may not have. Although I read also that Zeos has not been updated in sometime. I also read that there are additional ones at cost, and would try if I need so. But first I want to be more firm in the fundamentals, and do it with the default ones of Lazarus. It's a big learning experience, but I feel it is worth it. Thanks everyone, again.