I guess a folder in TDbf might be the database in sql thinking and all the dbf tables are separate files where in SqLite all the tables and indices are in one file, i.e. the Database.
If that helps you understand better then yes, you could make that analogy.
So, my components Connection, Transaction, Query I'm going to locate to datamodule or the like once I totally understand just accessing the database and or table or tables within say Clients Mgt, Sales Orders, Counties Maint., etc. Below, from reading I feel this is a round-robin.
It isn't really so I wonder how or what gave you that idea/feeling. Could you elaborate on how you were able to come to that feeling ?
I'm understanding to connect to the database but not just opening and updating just the Countries table?????
Once a query is "active" (e.g. executed correctly) the countries table /is/ open (sort of, it actually is the query), well at least with these particular SQL statement(s) in the query.
Because the initial countries example that was shared also used a navigator, the navigator component takes care of the editing and posting.
Please have another look at the first example from
this reference documentation. Can you spot the SQL statement of the query and the query being opened with Q.open ? You should be able to recognize the EOF and Next methods that are used later on because those are the same for a dbf table/dataset. In a similar fashion the results that match the query can be edited, modified and posted (the things that a navigator component does behind the scenes).
If you want to access another table, certain fields inside a table or make a query that combines different tables then either modify the current query or create another one, set the SQL statement to match the criteria, open the query and do to the data what you want to do to it (the latter is a bit with a grain of salt because things somewhat needs to cohere with the rest of the flow of your code/GUI).
The only real difference in comparison when using traditional DBF tables is a transaction. There is no need for a deep analyses of a transaction but you have to grasp that depending on how things are setup that a transaction can keep track of whatever was applied to a query and only performs all the (previous) actions when instructed to do so (with a commit). In a similar manner a transaction can be used to rollback previously performed actions (f.e. in case there is a duplicate in one table and all the other related modifications that where done should then be reverted). Again, depending on how the transaction was setup/configured.
Note that in light of the posted countries example that such a form could perfectly well create and destroy the query on the fly and as such does not has to reside in a datamodule. But that has more to to with a (personal) design decision rather than anything else. Whatever works best for the use case or floats the boat
