SDE_GEOMETRY tables in 10.6.1 GDB?

[AmyRose1]

Hello,

Should there be SDE_GEOMETRY tables in a 10.6.1 geodatabase?

We have a 10.6.1 geodatabase that has several (not just SDE_GEOMETRY1).

Does this mean the data did not properly upgrade?

Any help appreciated,

Amy Rose

City of Dallas

[George_Thompson]

What RDBMS are you using (i.e. Oracle, PostgreSQL, SQL Server, etc.)?

Can you provide a screenshot of what you are seeing from the ArcGIS client?

I looked at my SQL Server that was created at 10.6.1 and see this in SSMS:

There is no data in the highlighted table:

[AmyRose1]

Hello George,

Thanks so much for replying!

Our DB is SQL Server 2016

I see the SDE_GEOMETRY1 but I also see more:

We are trying to upgrade to 10.6.1 from a 10.2.1 geodatabase.  A colleague used basically copy/paste for their older geodatabase into their new 10.6.1 geodatabase so he wants to do the same for us, but I don't think it is working.  I think we need to truly upgrade.

I am not sure, but I think that the SDE_GEOMETRY tables (besides SDE_GEOMETRY1) should not be in 10.6.1, unless someone needs to keep a feature class on an older schema inside the 10.6.1.  I am trying to confirm this.

We also had editing errors like Trina Nair had in this post: 

https://community.esri.com/message/760431-re-migrate-storage-tool?commentID=760431#comment-760431 

I have asked if she was able to solve it, waiting for a reply.

Any help always appreciated!

Thanks,

Amy

[George_Thompson]

Ok, thanks for the clarification.

Are you currently experiencing any issues after the upgrade?

*********************************************************************************************************

I was able to find this presentation from the Esri Dev team; Administering Your Microsoft SQL Server Geodatabase. Chet Dobbins Shannon Shields - PDF Free Downloa...    Look at Page 6

I did find this at 10.3.x & 10.4.x: SQL Server configuration parameters—Help | ArcGIS Desktop  which would be consistent with what we see above.

It appears that we did not create these starting at 10.5.x.

GEOMTAB_OUT_OF_ROW, GEOMTAB_PK, and GEOMTAB_STORAGE

These three parameters affect the storage of the CAD side tables that can be used with feature classes that use SQL Server geometry or geography storage types. These side tables are created for feature classes that are enabled to store CAD entities, such as curves. All feature classes created through ArcGIS for Desktop are set to store CAD entities. The name of the CAD side table follows the convention SDE_geometry<ID>, where the ID is the associated feature class's layer_id from the SDE_layers table.

The GEOMTAB_OUT_OF_ROW parameter denotes if the data in the CAD column of an SDE_geometry<ID> table can be stored in the data row. Since data rows can store a maximum of 8,000 bytes in row, only data smaller than that can be stored in row, and only if the GEOMTAB_OUT_OF_ROW parameter is set to 0 (off). If the GEOMTAB_OUT_OF_ROW parameter is set to 1 (on), the values are always stored outside the data row and a 16-byte pointer to the external page is stored in the data row.

The GEOMTAB_PK parameter specifies the fill factor for the primary key index on an SDE_geometry<ID> table. By default, this is set to WITH FILLFACTOR=75.

The GEOMTAB_STORAGE parameter specifies the file group location for the SDE_geometry<ID> tables. Use the ON keyword to control location, for example, ON cad_fg.

[AmyRose1]

Hello George,

Thanks for this.  I think the problem is that the data is not being upgraded.  Just copied and pasted.

I had not heard of the Migrate Storage tool.

I will take a look at it and the references you have provided.

Thank you,

Amy

[George_Thompson]

If you copy and paste, it will be added to the EGDB at the version of the client. Example: you originally had the data in SDEBINARY geometry in your 10.2.1 EGDB and used a 10.6.1 client to copy into a new 10.6.1 EGDB, it would default to SQL Server Geometry storage.

I do not think that there is an issue with the data and once you run the migrate storage tool, it will "update" it to the latest functionality.

NOTE - When running the migrate tool, make sure that you have plenty of space available for the SQL Server DB. That tool basically does a behind the scenes copy/paste. So if the table is large, it will take up that much space "extra" during the running process. The beauty of the tool is that if the data is versioned, archived, etc. it will keep it all with the updated geometry type.

Read this page before running the tool: Data migration from one storage type to another—ArcMap | Documentation 

**Always take a full backup before completing this task**

[AmyRose1]

Thank you so much George.  I think we may just need to run the migrate storage tool.

I will have to wait until my colleague is back from vacation next week to run it.  

Thank you,

Amy Rose

[AmyRose1]

Hello George,

I was able to copy over our data from 10.2.2 using ArcPro 2.6.

I then ran the migrate storage tool.

I did some edits in Pro and no SDE_GEOMETRY tables were created.

BUT, when I ran a Python script that truncates and appends to a feature class, a SDE_GEOMETRY table was created on a feature class that is not even involved in the script. I had to use Python 2.x aka ArcMap.

I ran the migrate storage tool on this feature class and it said it worked but the SDE_GEOMETRY table is still there.

Another thing that might be a factor is that we do not have the sde account access.  We have been given a dbo account but it is not sde.

Any thoughts are appreciated.

Amy Rose

[George_Thompson · Accepted solution]

I would not worry about if that table is there or not. If the client created them when loading, then it thinks that they need to be there (even if empty).

Are you experiencing any issues with the Enterprise Geodatabase and those feature classes?

Is the issue that there is an extra table?

I have not heard or seen an issues with these tables. It may be that the older Python 2.x had different logic than the newer Python 3.x in terms of the tables.