Hi Kerry, thought you might have something to say about this... :)
>Somebody needs shooting! Unless people have been silly and written lots
>of code that assumes the structure of the table will never change (eg:
>SELECT * FROM table, or used INSERT without listing the columns), a
>serial column won't make a difference to anybody. If they *have* been
silly, >you should rewrite the DML code anyway!
Yes, quite!
(Having said that, I think the best reason to use "SELECT * FROM table"
is if you know the table definition _is_ likely to change. That way you
keep your rewriting of code to a minimum).
>I hope you never need to partition the table -- rowids stop being
unique
>then :-)
Well, that's a useful piece of information! Most of our clients are
still using SE rather than Dynamic Server (or Personal Edition), but I'm
definitely going to use that as leverage to add serial columns. :)
>Don't tell me you've got other tables that have foreign key
relationships to
>this 'rowid' table, which I guess you must, otherwise you've got no way
to
>access them. rowid's aren't especially permanent -- if you need to
unload
>your data / recreate your table / reload the table all your rowids will
be
>different, and you'll be screwed!
No, thank goodness, we're not using rowids as foreign keys! As you say,
an unload and a reload would completely stuff things up. No, it's just
when we're doing maintenance that we need some sort of unique identifier
of every record in order to successfully edit or delete it.
These are detail tables with millions of records. Sometimes people
don't see the value in having unique keys for that sort of thing - but
then they don't envision maintenance. There _are_ programs in Informix
4GL to maintain these tables though. And would you like to guess what
they use to do that? :)
Hmmm... better check on whether any of our dynamic server clients have
been partioning their tables recently...
>You've really got to NOT use rowid -- it's a disaster waiting to
happen!
It's a stopgap measure. Sooner or later, serial columns will arrive on
those last few legacy tables without unique ids (and if I have my way it
will be sooner) but in the meantime the company is trying to hold off
until all the old 4GL programs become obsolete, which will happen when
everyone is able to do all the maintenance through Delphi. This might
not quite happen by 1/1/2000, but it'll be close. And besides, our
programs run on MS Access as well, and they'll eventually have to
provide maintenance on that too, and MS Access wouldn't know Jack about
rowids (or serials, or "TDate" fields, or "rename table" etc.).
Now sit down and breathe deeply... :) :)
Cheers,
Carl Reynolds Ph: +64-9-4154790
CJN Technologies Ltd. Fax: +64-9-4154791
[EMAIL PROTECTED] DDI: +64-9-4154795
PO Box 302-278, North Harbour, Auckland, New Zealand
12 Piermark Drive, North Harbour Estate, Auckland, NZ
Visit our website at http://www.cjntech.co.nz/
> -----Original Message-----
> From: Kerry Sainsbury [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, October 15, 1999 9:39 AM
> To: Multiple recipients of list database
> Subject: Re: [DUG-DB] (Informix) Where can I get sqlca.h?
>
> Carl Reynolds said:
>
> > I'm in the unenviable position of having to do updates on some
> tables
> > without unique keys (and I'm not even allowed to stick serial
> columns
> > in)
>
> Somebody needs shooting! Unless people have been silly and written
> lots of
> code that assumes the structure of the table will never change (eg:
> SELECT *
> FROM table, or used INSERT without listing the columns), a serial
> column
> won't make a difference to anybody. If they *have* been silly, you
> should
> rewrite the DML code anyway!
>
> > so I'm having to do my updates using - you guessed it - rowids.
>
> I hope you never need to partition the table -- rowids stop being
> unique
> then :-)
>
> > Works to a point - the problem is of course retrieving the rowid
> once
> > you've inserted a new row, and there doesn't seem to be any
> equivalent
> > for a rowid that's like the "select DBINFO('sqlca.sqlerrd1')
>
> There is no equivalent. rowid's are meant to be secret internal
> things.
>
> Don't tell me you've got other tables that have foreign key
> relationships to
> this 'rowid' table, which I guess you must, otherwise you've got no
> way to
> access them. rowid's aren't especially permanent -- if you need to
> unload
> your data / recreate your table / reload the table all your rowids
> will be
> different, and you'll be screwed!
>
> You've really got to NOT use rowid -- it's a disaster waiting to
> happen!
>
> Cheers,
> Kerry "Informix was once my middle name" S
> Inprise NZ
>
> ----------------------------------------------------------------------
> -----
> New Zealand Delphi Users group - Database List -
> [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
application/ms-tnef
