🚀 go-pugleaf

In article <36d7bdd3.11272288@forums.inprise.com>, Steve Koterski 
politely paraphrased ...
> 
> 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.
---
Even not with Interbase or Oracle? 

> 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.
---
I understood the SQL servers did it the same way. 
 

-- 
Romain Strieff [TeamB]
Please read this newsgroup guide below before 
posting on the private Inprise newsgroups.
http://www.inprise.com/newsgroups/guide.html
--