Nacef,

Simply add a SERIAL column to your table. When you add a new row, a new value will be stored in this column if you do not specify the column name in the insert query.
In your select query, always order by this column.
When doing an update , do not update this column. When re-ordering, update this column to indicate order. So if you want to move a row up, issue two update queries, updating this column. Make sure you have some primary key in this table to uniquely identify these row.

Never rely on the internal implementation of a database to keep the data in the order you insert/update.

Padam

Nacef LABIDI wrote:

You are right about the fact that the rows don't keep the order they where created with at the start. I have verfied this.

I will explain more my case :

I am writing an application where here is some resources to plan events on. I want to provide the user with the ability to customize the order in which resources are displayed on the screen. So there is a mapping between the rows positions in the dataset and they display positions. After updating one of these resources the row jumps to the end of the dataset so does the resource on the display. And the order gets scrambled. I cannot set this order in the databe since it is customizable for each user.

When I have tested this with SQLServer it works well, since the rows doesn't change position on the DB.

I hope that you understand my issue and I will provide any explanations if someting isn't clear enough.

Thanks to all
Nacef

On Tue, Apr 22, 2008 at 12:15 PM, hubert depesz lubaczewski <depesz@depesz.com> wrote:

On Tue, Apr 22, 2008 at 12:10:41PM +0200, Nacef LABIDI wrote:
> Yes I don't issue any sort statement, and I indeed want the data to be show
> as it is stored in the database. But after updating a row (I don't update
> the ID, just some fields), it keeps its same place on the DB but jumps to
> the end of the dataset and by the way to the end of the DBGrid.

why do you think it stays in the same place in db?

besides - without "order by" you cannot depend on the order of rows.
basically i treat them as in "random" order (which is not true, but
helps me remember to never count on the "default" ordering.

depesz

--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)

-- 
PGP Id 9EED2E09