4

I have an ArcSDE 10.0 enabled SQL Server 2008 R2 database on a development server. We are using TeamCity to run continual deployment to this development server, which runs through the following steps:

  1. The production database is restored from a recent backup.
  2. ArcSDE deregistrations are run to remove a layer that isn't used anymore.
  3. Some SQL scripts are executed to make any schema changes that are not in the backup.
  4. Lastly, some ArcSDE registration are run to add new layers.

The deregistration script that runs has no problems:

E:\ESRI\bin\sdelayer.exe -o delete -l jobsite,activityarea -i sde:sqlserver:[server]\[instance] -s [server]\[instance] -D [database] -u [redacted] -p [redacted] -N

ArcSDE 10.0  for SQL Server Build 685 Fri May 14 12:05:43  2010
Layer    Administration Utility
-----------------------------------------------------
Successfully Deleted Layer with Table jobsite.

The registration scripts are both having issues:

Executing E:\ESRI\bin\sdetable.exe  -o create_view -T spatial.vw_seasoncell -t RS_AOI_Grid_Final -c RS_AOI_Grid_Final.shape -i sde:sqlserver:[server]\[instance] -s [server]\[instance] -D [database] -u [user] -p [password]

ArcSDE 10.0  for SQL Server Build 685 Fri May 14 12:05:43  2010
Attribute    Administration Utility
-----------------------------------------------------
    Error: DBMS table not found (-37).
    Error: Unable to create view spatial.vw_seasoncell

And secondly... (note that JobSiteActivityArea is an existing SQL table with a spatial column ActivityArea)

Executing E:\ESRI\bin\sdelayer.exe -o register -l jobsiteactivityarea,activityarea -e p+ -C Id -t GEOGRAPHY -E [extent] -i sde:sqlserver:[server]\[instance] -s [server]\[instance] -D [database] -u [user] -p [password] -G 4283

ArcSDE 10.0  for SQL Server Build 685 Fri May 14 12:05:43  2010
Layer    Administration Utility
-----------------------------------------------------
Error: DBMS table not found (-37).
Error: Unable to create registration for table jobsiteactivityarea.

The real point of interest is if I run these commands remotely (i.e. in my own command prompt - I have ArcSDE on my local machine) targeting that server, everything works correctly. In my mind that would seem to rule out any permission issues with the credentials I'm supplying. This works from a couple of different machines.

I've tried:

  • Different casing for the tables, as I know they can be temperamental. The JobSiteActivityArea table is pascal cased, but again - it works when it's run remotely.
  • Adding the schema to the table names. These tables and views are all in the spatial schema, and the credentials that I'm supplying is for the 'spatial' user (i.e. my user is the same name as my schema, because I know it's fussy about that too).

Any suggestions would be greatly appreciated. I'm hoping I'm missing something obvious.

1

A couple of thoughts and comments..

First off, for a direct connect setup you shouldn't need or use the -s parameter. Your connection is wholly defined by the -i service parameter.

Second, I find it highly suspicious that you say things work differently when running the commands locally on the database server vs. remotely. That indicates to me that the connection being made isn't the same: either you're connecting to different database instances, different database under the instance, or with different credentials. Is there a naming issue with the server going on?

The previous answer about changing -i to -i 5100 or similar assumes you have an SDE service setup and running (often called 'application connect' or 'three-tier'). Your command snippets indicate direct connect so unless you also have an SDE service that wouldn't an option.

  • Good spotting the -s parameter being used redundantly. – chriswithpants Jun 26 '13 at 5:15
0

Try changing the -i parameter to just "5100" (or whatever your server is) instead of "sde:...."

  • Trying that now - any idea why that would fix the issue? – chriswithpants Jun 18 '13 at 4:23
  • Now getting this instead: Error: Operation Failed (-1). Error: Cannot get configuration information – chriswithpants Jun 18 '13 at 5:45
  • 1
    Have you tried turning it off and on again? – Robert Wagner Jun 20 '13 at 10:01
0

Turns out there was nothing wrong with the commands we were using. The issue was the exe's we were calling on that particular server. ArcSDE commands had not been installed, someone had just copied the bin folder from another installation somewhere (unsure of versions). Correctly installing ArcSDE commands onto the machine in question resolved the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.