🚀 go-pugleaf

On Thu, 18 Feb 1999 12:28:53 +0100, teamb@opto-pps.com (Romain Strieff
[TeamB]) wrote:

>In article <36cc3350.1357578@forums.inprise.com>, Steve Koterski politely 
>paraphrased ...
>> 
>> This is true. All multi-table join result sets will be read-only. It is up
>> to the application front-end to accommodate such read-only result sets and
>> provide a means for updating the data in the separate base tables.
>> Different front-end software packages handle this differently. Gary pointed
>> out how you might go about handling this in Visual dBASE. In C++Builder and
>> Delphi, it is handled different from that (using cached updates).
>---
>Also with normal DBFs? AFAIK the only way the big guys doing it is by 
>sending SQL code to the server which then need a way to uniquely identify 
>the concerned row(s) which can only be done if all the tables have a 
>primary key, no?

The existence of a primary key might uniquely identify a row in a base
table, but does not itself make an association between a rows in a result
set and that row in the base table. When columns from multiple base tables
are combined to produce a single result set (i.e., a join), the result set
is essentially the same as a table, only it is virtual. The columns in the
result set belong to the result set, not to a base table. Thus the result
set itself cannot be editable.

In Delphi, with cached updates such a result is made to appear editable.
But it is not really. It is just smoke and mirrors. The data-aware controls
make it look like the result set is being edited but the changes are really
going into a separate, cached dataset. Once all data modifications (new
rows added, existing rows edited, and rows deleted) have been made, these
cached changes are applied. That is, each cached change record is evaluated
and an SQL statement executed to take the change for any one cached record
and update the appropriate base table (UPDATE, INSERT, or DELETE). The
trick is that the SQL statement must correctly identify the right base
table, something done manually in composing the individual update SQL
statements.

Delphi and to some extent Visual dBASE are more low-level in treating this.
No presuppositions are made about how the programmer wants the base tables
updated. That must be handled manually and explicitly; the programmer must
specify how and in what tables any changes will be made. For this reason,
multi-table queries are read-only, but the means for handling that manually
provided as a side dish. A more high-level environment (Microsoft Access?)
might just do this handling for you, applying the changes in a manner that
seems most logical -- most logical to whoever programmed the environment
software. But even there, the multi-table query is still read-only. It is
just that the software automates the processes to make the result set
appear updatable and that apply changes.

//////////////////////////////////////////////////////////////////////////
Steve Koterski                       "For people who like peace and quiet:
Technical Publications               a phoneless cord."
INPRISE Corporation                                             -- Unknown
http://www.inprise.com/delphi