Re: SERIAL DATA TYPE
Posted in 1995
I've been half-way following this thread, and I think there may have been some statements made that aren't completely correct. I say "may" because the following is from memory, and I can't research it right now. With that disclaimer in mind: I believe that the uniqueness of a serial column does not result from the fact that it's data type is serial, but because it is uniquely indexed in most applications. If a column is SERIAL, Informix saves the most recently auto-assigned value. If a row with a zero (0) in that column is inserted (also updated?), the saved value is incremented and used as the column's value in that row. The new value is then saved. If the column value is set before inserting and is higher than the old saved value, the new inserted value is saved. That's pretty much it for the auto-incrementing function. If you don't mess with it, you'll get a set of increasing positive integers. If you delete some or do an insert that bumps the value, you'll have gaps, but the values in the table will still be unique. These values will not break a unique index. When the automatic value reaches the maximum value for an INTEGER, it will wrap back to one (1). The auto-increment function will continue to work from there as described above. As Informix makes its second pass through the positive intgers, I don't think it scans the entire table for used values before using a new incremental value. If a new auto-increment value is already in the database and the column is uniquely indexed, you will get an error when Informix tries to update the index on that column. Excuse the redundancy if this point has already been made, but I didn't remember seeing it. If I have any of the above incorrect, please let me know. Thanks, Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648