Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!uunet!lll-winken!manatt
From: manatt@lll-winken.UUCP
Newsgroups: comp.databases
Subject: Re: Flaw in RTI ingres
Message-ID: <817@lll-winken.ARPA>
Date: Mon, 31-Aug-87 18:14:33 EDT
Article-I.D.: lll-wink.817
Posted: Mon Aug 31 18:14:33 1987
Date-Received: Tue, 1-Sep-87 05:48:29 EDT
References: <640@lll-winken.ARPA>, <312@pyuxv.UUCP>
Organization: Lawrence Livermore Labs, Livermore CA  94550
Lines: 53
Keywords: Update impossible
Summary: Clarification of RTI ingres flaw

In my article: About updates in RTI ingres

In article <640@lll-winken.ARPA>, manatt@lll-winken.ARPA (Doug Manatt ) writes:
> 
> From all I know about it, it is impossible to have their
> RDBMS provide your program with a row of your data, allow you program to 
> transform it and the replace the transformed data in the same table in place
> of the original data.  Their RDBMS provides a "REPLACE" capability, but only
> replaces that can be computed in the "BACKEND" are allowed.  The other 
> alternatives are to load the rows to be worked on into arrays, temporary
> files, or "form" structures.

In article <312@pyuxv.UUCP>, cim2@pyuxv.UUCP (Robert L. Fair) writes:
>
> * For EQUEL/C single record updates are simple do, quickest is to use
>   the tid for the update:

  Thanks for pointing out that this is possible using SQL.  Note on tids: RTI
repeatedly claims that TIDs are unsupported and may change with any
future release

> *       For multi-record updates either do a calculated update, for example:
> 
> ##	replace  emp (salary=emp.salary*raises.percent) 
> 

  This works fine only if you are performing a function supported by the ingres
backend.

> Note that the QUEL language doesn't allow nested queries, so attempts
> to emulate the SQL UPDATE WHERE CURRENT OF don't work in QUEL
> 
> a)	Loading the data into a FORMS TABLEFIELD dataset then doing a batch
> 	update with ##unloadtable once the user has viewed/changed all 
> 	the data.  TABLEFIELDS are *really* useful. This is probably
> 	best for up to a few hundred records.
> 
> b)	Write the updated records into a temp file, then use
> 	COPY to bulk-update the database. This is fastest if many 
> 	records have been changed.

  These seem to be rather drastic measures when all that one wants to do
is perform a simple update operation with a function that is not provided by 
RTIs backend.

Note: What is needed is not the nested query capibility, but the ability to 
"check out" data that will be returned as the next database operation.
This could also be worked around by allow the user to specify a library of 
transformation functions that would be called by the backend.

					Doug Manatt
					Lawrence Livermore Lab
					(415)422-7257
					manatt@lll-winken.arpa