<html><head></head><body>Hi all,<br><br>This is really worth a more fuller understanding – the actual lifecycle of Delphi objects in db activity.<br><br>So aside from multi usage requiring "locking", let's take a single user scenario as discussed by Gary, this then is essentially an entirely internal Delphi thing, in that the db engine is essentially agnostic as to where it is getting it's properly credentialed instructions from?<br><br>Though a local Sqlite type of thing would be more tightly Delphi integrated? - so may raise other issues?<br><br>But more generally, if the query object is essentially an internal Delphi object, is there any (private) referencing/reference counting on it which would disqualify it from "safe" reuse, or is it essentially in a neutral "state" agnostic to whether it's being recycled?<br><br>Does the completion of a db engine transaction set a flag in the Delphi query object or in ram with Delphi?<br>— If not (and there being no other considerations) then it would appear to be entirely recyclible? <br>In that Delphi is unaware to its previous usage at that point? — it's essentially no different to a freshly instanced, now inactive, and so far equivalently unused query object?<br><br>If there is a flag in a private property, might require enquiry into component and class source code if any one has access to it?<br><br>Regards,<br>Paul<br>-- <br><a href="https://PaulANorman.info">https://PaulANorman.info</a><br><br><div class="gmail_quote">On 13 June 2022 10:55:50 am NZST, Tech Benner <tech@benner.nz> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">HI Adrian,<br><br>I may be wrong for it is many moons ago that I taught this, but under <br>the hood TTABLE and TQUERY access the database(s) in the same way. And <br>so editing the record received from either method of database access, <br>and then posting back is identical from an academic point of view.<br><br>In working with client server databases with multiple users - if that is <br>how you are using it in your system - you come across record locking <br>issues, and in that case going into EDIT mode may block access to other <br>users, especially if the UI keeps blocks on the data for some time.<br><br>My preference is to develop separate UPDATE queries that modify data. <br>However this must be designed with reference to how user(s) are to be <br>accessing and updating (modifying) the data, and the chances of <br>overwriting data.<br><br>If there is only one user, or users are not likely to be editing the <br>same record at one time, then there is little to worry about. If there <br>are to be multiple users accessing the same record, potentially at the <br>same time, then you need to look at record locking, and develop the UI <br>to take this into account.<br><br>HTH<br><br>Gary<br><br><br><br><br>On 13/06/2022 10:37 am, Bevan Edwards wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hi Adrian,<br><br> I have used TQuery objects to read data from databases (sometimes<br> complex, sometimes simple), and then other TQuery objects to perform<br> update/insert/delete operations.<br><br> The fact that you "can" perform update/insert/delete on a (presumably<br> simple) TQuery seems like a side-effect of how it is implemented, rather<br> than an acceptable/intended approach.<br><br> In my view, a SELECT query is for read-only purposes and should not then<br> be used to directly update the database.<br> If you wanted to update the database like that, you would use a TTable<br> rather than a TQuery.<br> Again, that's probably better suited to file-based databases (like<br> Paradox and MS Access) rather than SQL-based databases.<br><br> That's my two cents worth anyway.<br><br> Regards,<br><br> Bevan<br><br><br> On 13/06/2022 10:05 am, Adrian Williams wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Hi all<br><br> I wonder if someone could clarify something regarding Queries.<br><br> I understand that if you run a query on a table it returns a subset or<br> snapshot of data from the table based on the SQL statement supplied. (In<br> my Paradox days, a query created an 'ANSWER' table that could be<br> navigated as a table, but was separate from the original data).<br><br> What I have discovered (more by accident), is that if you edit records<br> in the query data and call the query's POST method it will post the<br> changes back to original table. Also by using the APPEND and INSERT<br> methods on the query, you can create new records in the base table. What<br> I have been able to ascertain is that the database engine seamlessly<br> creates the SQL code to run UPDATE and INSERT statements to amend the<br> original table in the background.<br><br> My question is: Is this a 'proper' and acceptable way of updating a<br> table by modifying the Query data? Or is this fraught with danger and<br> bad practice?<br><br> Appreciate any comments on this.<br><br> Regards<br> Adrian Williams<hr> NZ Borland Developers Group - Delphi mailing list<br> Post: delphi@listserver.123.net.nz<br> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a><br> Unsubscribe: send an email to delphi-request@listserver.123.net.nz with Subject: unsubscribe<br></blockquote><hr>NZ Borland Developers Group - Delphi mailing list<br>Post: delphi@listserver.123.net.nz<br>Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a><br>Unsubscribe: send an email to delphi-request@listserver.123.net.nz with Subject: unsubscribe<br></blockquote><hr>NZ Borland Developers Group - Delphi mailing list<br>Post: delphi@listserver.123.net.nz<br>Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi">http://delphi.org.nz/mailman/listinfo/delphi</a><br>Unsubscribe: send an email to delphi-request@listserver.123.net.nz with Subject: unsubscribe</pre></blockquote></div></body></html>