Tim

I just moved a column using EDBManager and looking at the SQL History a MOVE TO is generated for each up / down move eg

ALTER TABLE "Users"
ALTER COLUMN "_DisplaySettings" MOVE TO 21,
ALTER COLUMN "_DisplaySettings" MOVE TO 20,
ALTER COLUMN "_DisplaySettings" MOVE TO 19,
ALTER COLUMN "_DisplaySettings" MOVE TO 20,
ALTER COLUMN "_DisplaySettings" MOVE TO 21,
ALTER COLUMN "_DisplaySettings" MOVE TO 22

I don't know what happens under the bonnet but unless its sorting it out it looks very ineffective, especially on a big table.

Roy Lambert

Roy,

<< I don't know what happens under the bonnet but unless its sorting it out
it looks very ineffective, especially on a big table. >>

Internally, the column moves happen all before any row data is actually
modified.

The table alteration SQL generation has to work like this.  Remember, it has
to track everything you're doing in the exact same order that you're doing
it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Internally, the column moves happen all before any row data is actually
>modified.

I was hoping it would be something like that so fairly efficient.

>The table alteration SQL generation has to work like this. Remember, it has
>to track everything you're doing in the exact same order that you're doing
>it.

Yes, but, if there are two moves following one another on the same column you could discard the first one. As long as its done efficiently under the hood who cares.

Roy Lambert