SDELayer fails in simple case

[JohnCawley_III]

I am trying to register a very simple MSSql table (with a Geometry shape) as a feature class in ArcSDE using SDELayer, but am unable to do so. I am using ArcSDE 9.3.1 on a SQL Server 2008 database.

I start with a good feature class, Bldg, that has a single (MSSql Geometry) shape in it and which is viewable in ArcCat/ArcMap. Then from MSSql, I make a copy of the table/FC with "select * into sde.Bldg2 from sde.Bldg". (On an aside, I understand that user sde should not own user data, but will fix that later.)

Now I try to register this new table/FC with ArcSDE using this command:

sdelayer -o register -l Bldg2,shape -e na+ -t GEOMETRY -C objectid,SDE %auth

where %auth contains my connection and authentication information for user sde. I receive this error:

ArcSDE 9.3.1  for SQL Server Build 1632 Thu Feb 26 12:05:37  2009
Layer    Administration Utility
-----------------------------------------------------
Error: Invalid entity type (-29).
Error: Cannot Create Layer.

After I receive this error, Bldg2 does show up under ArcCat, but as a table, not a feature class.

I've searched the forums here and tried advice from somewhat-related problems, with no success. Thanks in advance for any assistance,
--John

[JohnCawley_III]

Okay, I got slightly further.

Running "sdelayer -o describe %auth", I noticed that the Bldg table (that the single feature was copied from into Bldg2) has an Entities value of "nac3+". (c for CAD I understand, as this feature ultimately came from a CAD; 3 for 3-dimensional, I have no idea the source of.)

So I tried "nac3+" instead of "na+" in the register command:

sdelayer -o register -l Bldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth

This did successfully create a layer. However, from ArcCat, I am able to preview the Bldg feature class, but the new feature class Bldg2 just has a blank preview panel.

So there still seems to be something wrong with the FC it registered, as it is un-preview-able (which in my experience leads to it having other problems further down the line) ...

Would the falsex/falsey/xyunits perhaps have something to do with it being un-preview-able?

[JohnCawley_III]

Tried adding the -P and -G arguments:

sdelayer -o register -l Bldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100

The table registered again, but is still un-preview-able.

[VinceAngelo]

The "3" corrupted the layer definition, since your geometries are 2-D.  You should have
the "-x" flag on the command line, in addition to -P and -G.

- V

[JohnCawley_III]

Thanks for all your assistance. I tried -P, -G and -x, both with and without the "-e 3", and both with the -x args you used and with the values from srid 54, but all four combos had problems:

sdelayer -o register -l zBldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -10000000,0,10000 # created but unpreviewable
sdelayer -o register -l zBldg2,shape -e nac+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -10000000,0,10000 # invalid entity type error
sdelayer -o register -l zBldg2,shape -e nac3+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -20037700,-30241100,10000 # created but unpreviewable
sdelayer -o register -l zBldg2,shape -e nac+ -t GEOMETRY -C objectid,SDE %auth -P HIGH -G102100 -x -20037700,-30241100,10000 # invalid entity type error

So it looks like sdelayer thinks it needs the "3" entity type (even though I have no idea where it is determining that from the 2-dimensional MSSql Geometry type). Is there perhaps a way to strip the "c" and the "3" from the "sdelayer describe" attributes of the source FC (Bldg) prior to using MSSql to copy the single feature from that class to the new table Bldg2 that I'm trying to register?

Or perhaps some other way to prevent the registered layer from being corrupted?

Thanks again,
--John

[JohnCawley_III]

The SDELayer register command is insisting that the entity argument include a "3" (eg "nac3") or it fails. When the "3" is included, it registers the MSSql table as a feature class, but the FC is corrupted (Symptoms: from ArcCat, the FC shows up blank; from ArcMap, it shows up blank. In ArcMap, if I open the attribute table, I can get an outline of the shape; but using the Info tool, and clicking on the shape, no information appears.)

To see if I could get SDELayer to work without the "3" in the entity class (which we're assuming is the culprit here), I created a new SRID in sde.sde_spatial_references and verified that it has a zero for its falsez and falsem, and a 1 for its zunits and munits, and a zcluster_tol of 0.001 (which all the rest of my SRIDs have). I set the SRID of the GEOMETRY shape to the SRID I created (71). Still, SDELayer refuses to work unless the "3" is in the entity types.

I found a reference that the "c" cannot be removed from the entity types (http://forums.esri.com/Thread.asp?c=2&f=59&t=238988); but is there a way to get SDELayer to register the FC without a "3"? Or might some other factor than the "3" be causing the corruption in the registered feature class?

Thanks,
--John

[VinceAngelo]

At this point, I think you'd be better off taking this issue to Tech Support.

- V

[JohnCawley_III]

Thanks, V,
--John

[DuaneAnderson1]

Not sure if you ever solved your problem but we have successfully registered a SQL spatial table with the SDELayer command using the following syntax:

sdelayer -o register -l pcown.datest,shape -e a+ -C objectid,SDE -t geometry -R 111 -i xx -s xx -u xx - p xx

where the -R parameter is the SRID value that we know the feature class belongs to.

In our case we generated the non registered SQL table from a feature class that was registered with a know SRID so that helped.  It worked however.

I believe in ArcMap/ArcSDE 10 there is a new feature to recognize SQL spatial tables without having to register them.

Duane