Theres a good reason pavel recommends starting with SPT, as you first need to retrieve data, before you can send back changes to a remote database, but as said TABLEUPDATE() is a universal data commit command, also for DBFs, therefore I sugget you add tableīuffering to DBFs and then use TABLEUPDATE() to save changes into DBFs and only the next step will be querying remote data. SPT as it's named in short is a good thing to know, too. You can do more, especially with SQL pass through, as it allows to send any remote sql dialect the remote database understands, besides SQL that also includes definition of tables, indexes, stored procedures, user defined functions and calling those, therefore To be able to use TABLEUPDATE() on remote data like on buffered DBFs, you need to specify some things, especially what fields are primary keys and what fields should be updatable, and that is also true for any of the remote data access techniques. TABLEUPDATE() behind the scenes computes the needed insert/update/delete SQLs for remote databases, and in regard to DBFs simply copies what's in it's buffers to the DBF file.

Therefore this is a basis technology across all data persistation techniques. Once you create updatable remote views, updatabale passthrough cursors or updatable cursoradapters you can commitĪll changes in them via TABLEUPDATE() and this is working with DBFs, too, if you use them buffered. While I second pcelba in general I think a good first base knowledge working with any remote data access is knowing how TABLEUPDATE() works.

Dbf to sql