Relevance of column order in a SQL Server table

Discussion created by micsbjc on Mar 4, 2014
Latest reply on Mar 5, 2014 by micsbjc
A typical table created in  SQL Server Geodatabase 10.0 (with default type of SDE_BINARY) has the following columns..

[SHAPE] [int] NULL

After you issue 'sdetable -o register' and 'sdelayer -o add' you get an additional column called 'FID', so the columns look like
[SHAPE] [int] NULL,
        [FID] [int] NULL

If you then issue MIGRATE command with -'k geometry' the columns look like..

[FID] [int] NOT NULL,
[SHAPE] [geometry] NULL

Note that the SHAPE field is now GEOMETRY (as expected) and that the FID and SHAPE column order has been reversed.

This reversal of column order appears to be transparent to the majority of ESRI functions.

However we have a program that issues the 'SE_stream_set_shape' function call from 'ARcSDE 10.0 SDK' that gets a 'a -114 error (Wrong column type)' when accessing the migrated table. Manually altering the order of the FID and SHAPE columns fixes the problem. I am assured by the developer that he is dynamically locating the SHAPE column and is not relying on any preconceived column order.

My question then is 'does the ESRI code (in particular, the 'SE_stream_set_shape' function, rely in any way on the fact that the FID column must be the last column in the table'.