Re: updateable recordsets



On jeu, 20 jui 2000, you wrote:

> 
> At any rate, this to me would seem logical:
> 
> - let the provider implement the code to do the updating
> - if the provider has some kind of updateable cursor mechanism in
> it's client libraries, use that.
> - otherwise, use the metadata "Primary key determination" method.
> - OR (user/application/programmer/provider/etc specified): 
> - use unique row ids. 

Another solution would be, just after opening a connection, to give the
provider some meta information on the structure of the database. This could be
primary keys (if the provider can't find them), foreign keys, or other kinds of
links, default values, etc.  So when a SELECT is made, the provider can, if
necessary, add some 'hidden' columns which will help him make
updates/inserts/removals (this operation would be even easier if the query is
an XML query because it can have access to the structure of the query). 

That meta data could be altered in the same way as is a graphical context, and
any insert/update/remove query would then use that meta data

If the provider, for an update/remove operation cannot alter/remove only one
row, then it will issue an error. 

Another thing to mention is that for select queries with several tables, one
must tell which table he wants updated.

What do you think?

Vivien




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]