<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Relevance of column order in a SQL Server table in Data Management Questions</title>
    <link>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334459#M19008</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;A typical table created in&amp;nbsp; SQL Server Geodatabase 10.0 (with default type of SDE_BINARY) has the following columns..&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [int] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;After you issue 'sdetable -o register' and 'sdelayer -o add' you get an additional column called 'FID', so the columns look like&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [int] NULL,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [FID] [int] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;If you then issue MIGRATE command with -'k geometry' the columns look like..&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt; [FID] [int] NOT NULL,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [geometry] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Note that the SHAPE field is now GEOMETRY (as expected) and that the FID and SHAPE column order has been reversed.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;This reversal of column order appears to be transparent to the majority of ESRI functions.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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'.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 05 Mar 2014 02:03:22 GMT</pubDate>
    <dc:creator>JohnCuthbertson</dc:creator>
    <dc:date>2014-03-05T02:03:22Z</dc:date>
    <item>
      <title>Relevance of column order in a SQL Server table</title>
      <link>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334459#M19008</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;A typical table created in&amp;nbsp; SQL Server Geodatabase 10.0 (with default type of SDE_BINARY) has the following columns..&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [int] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;After you issue 'sdetable -o register' and 'sdelayer -o add' you get an additional column called 'FID', so the columns look like&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [int] NULL,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [FID] [int] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;If you then issue MIGRATE command with -'k geometry' the columns look like..&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt; [FID] [int] NOT NULL,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; [SHAPE] [geometry] NULL&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt; &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Note that the SHAPE field is now GEOMETRY (as expected) and that the FID and SHAPE column order has been reversed.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;This reversal of column order appears to be transparent to the majority of ESRI functions.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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'.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 05 Mar 2014 02:03:22 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334459#M19008</guid>
      <dc:creator>JohnCuthbertson</dc:creator>
      <dc:date>2014-03-05T02:03:22Z</dc:date>
    </item>
    <item>
      <title>Re: Relevance of column order in a SQL Server table</title>
      <link>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334460#M19009</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;No, this is a programmer error issue. SE_WRONG_COLUMN_TYPE can &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;only be generated by using a setter/getter with an assumed type order.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;After creation, the SE_STREAM should be polled for column type by &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;position with SE_stream_describe_column() over the range 1 to the&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;count returned by SE_stream_num_result_columns(). &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Using the setter/getter functions is also measurably slower than using &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;SE_stream_bind_{input|output}_column (but failure to identify types &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;correctly with a bind will cause a segmentation violation). &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I should note that the 'C' API is now deprecated, and won't be available&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;post-10.2.2.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;- V&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 05 Mar 2014 03:25:41 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334460#M19009</guid>
      <dc:creator>VinceAngelo</dc:creator>
      <dc:date>2014-03-05T03:25:41Z</dc:date>
    </item>
    <item>
      <title>Re: Relevance of column order in a SQL Server table</title>
      <link>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334461#M19010</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Vince, thanks for your input, especially regarding deprecation.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;We managed to get around our problem by using our own unique key column rather than having sdetable generate the FID column&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;sdetable -o register -c OBJECTID -C USER &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Once we did this the problem magically dissappeared&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 06 Mar 2014 00:11:35 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/relevance-of-column-order-in-a-sql-server-table/m-p/334461#M19010</guid>
      <dc:creator>JohnCuthbertson</dc:creator>
      <dc:date>2014-03-06T00:11:35Z</dc:date>
    </item>
  </channel>
</rss>

