Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!bellcore!faline!sabre!gamma!pyuxp!pyuxv!cim2
From: cim2@pyuxv.UUCP (Robert L. Fair)
Newsgroups: comp.databases
Subject: Re: Flaw in RTI INGRES
Message-ID: <312@pyuxv.UUCP>
Date: Thu, 20-Aug-87 08:36:42 EDT
Article-I.D.: pyuxv.312
Posted: Thu Aug 20 08:36:42 1987
Date-Received: Sat, 22-Aug-87 16:04:01 EDT
Distribution: world
Organization: CHC
Lines: 70

>References: <640@lll-winken.ARPA>
>Problem with 
>
I've been working with RTI ingres for over 5 years  (both QUEL and SQL
versions) and havn't found any problems like you are discussing.

I assume you are programming in EQUEL/C or ESQL/C rather than 
interactively

* For ESQL/C simply use DEFINE CURSOR... FOR UPDATE then
do UPDATE <updatestat> WHERE CURRENT OF <cursor>; to update the
values in the current record.

* For EQUEL/C single record updates are simple do, quickest is to use
  the tid for the update:
##	long	itid;
##	begin transaction	/* Ensure updates are atomic */
##	retrieve (<data>, itid=<table>.tid ) where <qual>
	<munch data>
##	replace <table> ( <update> ) where <table.tid>=itid
##	end transaction

*       For multi-record updates either do a calculated update, for example:

##	replace  emp (salary=emp.salary*raises.percent) 
##	where emp.dept="sales" 
##	and emp.grade=raises.grade

*	or use program variables:
	
##	int	iraise;

##	replace emp (salary=emp.salary*iraise) where ...

There are basically two types of updates:

1.	Single record updates
2.	Set or group updates

INGRES allows both of these (as shown above) with no problems. Note
that the QUEL language doesn't allows nested queries, so attempts
to emulate the SQL UPDATE WHERE CURRENT OF don't work in QUEL (Of
course you can always use ESQL/C from RTI if you need that)

If you are having problems try stepping back and rethinking your
application design, in particular if you are an SQL person learning
QUEL you will need to "unlearn" a number of things. If your application
involves showing the user a number of records, allowing random update
by the user then writing the changes away, try one of:

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.

Having implemented both QUEL and SQL languages from scratch (my version
of QUEL *does* allow nested updates by the way) it's my humble 
opinion that QUEL is generally a cleaner, easier to use, and more powerful
language than SQL.

Tough sh*t that IBM invented SQL, so thats the new standard :-(

Regards, 
Bob Fair
Bellcore/CHC
ihnp4!pyuxww!pyuxv!cim2