Re: REPOST: Trouble with SQL conversion

Ok, now the academic part - why do you have to "GROUP BY" all columns
selected? Would one not suffice and have the optimizer figure out the
rest? I am no standards guru and have not studied SQL92 or SQL99 so
would just like to know.

Another inconsistency that I have picked up is with transactions. If I
insert a record and violate a primary key (in a transaction block, on
both databases) I get an error to the fact - correct. After the error, I
am not allowed to do anything, even a select. I am trying to simulate a
replace into the database, but using an insert, if failure update does
not work. I have worked around this by first trying an update, check the
number of affected rows, if zero then insert. This works.

So my question: If an insert fails in a transaction is all access dead
forever, even selects till the transaction is rolled back or committed?
Once again what does the standard say.

>>> Christopher Kings-Lynne <chriskl@familyhealth.com.au> 2002/04/11
05:36:12 >>>
> I am an idiot! Actually your suggestion does work - it would help to
do
> it against a customer that actually has records!

Phew!  Lucky that "other" database didn't have one over us, huh? ;)

Chris