Re: Reversal of Records

>> > [ text deleted ] >> > The reason for this is the reason that SERIAL exists - it provides >> > an automatically generated primary key. The only implied >> > requirements are that a type SERIAL be UNIQUE and NOT NULL. >> > In addition, a quick review of several Informix 4.0 manuals >> > indicates that there is no promise made there about ordering >> > of type SERIAL with respect to INSERT sequence. >> > [ text deleted ] >> >> Greg, please tell us which pages of the 4GL manuals discuss "ordering of type >> SERIAL with respect to INSERT sequence." I can't find anything. >> > >Sorry if I wasn't clear here - what I am saying is that I can't find >anything either. If Informix doesn't make the promise, they won't feel >obligated to keep it (exactly as in the case of ROWID). The Informix SQL Version 4.00 User Guide (page 2-20) states: Serial numbers ensure that a sequential number is assigned to each row of the table. You do not need to enter data in a SERIAL column. Eash time you add a new row to a table, INFORMIX-SQL automatically assigns the next number, in sequence, to the SERIAL column. Normally, the starting number is one, but you can select any number greater than zero as your starting number. The highest serial number INFORMIX-SQL can assign is 2,147,483,647. So I would say that Informix has made a promise about the order of the values in a SERIAL column. Making a clustered index on a serial column will keep the data in the table in the order it was entered. However, SQL (and perform) make no guarentees of the order the data will be returned unless you put an order by on the select. I do not know of any way to do this in perform. jeffl ---- Jeffrey F. Lawhorn Information Systems Group Programming Manager Unix, C, and Database Consulting jfl0@isg.com 450 B Street 16th Floor sdsu!isg100!jfl0 San Diego, CA 92101 (619) 234-3405 x274