I am afraid I am a complete newbie to GIS and ArcGIS and it has fallen on my shoulders to try and resolve a problem with our ArcGIS installation. Assume I know nothing about GIS or the software please...until 2 weeks ago I hadn't even touched a GIS system. Anyway we have ArcCatalog 9.1 and ArcMap 9.1 installed on a very old server.

I can see the tables/views created in the database but the user's layers are not being populated (red exclamation marks in ArcMap).

I have opened up ArcCatalog and I can see the database connections on the server under Admin User's app data folders. If I open up these (there are a number) some or all have at least one of the tables missing or a necessary view missing.

I think the error is related to registering the tables with the sde.

Sorry for any mistakes I have made, I have spent a bit of time on this and will edit/correct the above as I receive further information.

EDIT (content removed above as I try and focus in on the true problem)

I have recreated the table the scripts are failing to create from a database backup. I can then see this in one of the database connections on ArcCatalog. However when I try and import the feature class into the other connections it comes up with an error stating:

Table Already registered.....violation of UNIQUE KEY constraint....

Obviously the table exists now but I cannot see anything within the DB Connections relating to the same name. I believe I need to unregister or re-register the table with the sde...or something?!

Edit - Full error when trying to "copy features":

Error in creating output c:\....... table already registered 
[Microsoft OLE DB Provider for SQL Server: Violatio of UNIQUE KEY constraint 
'registry_uk2'.  Cannot insert duplicate key inobject 'sde_table_registry'.]  
Failed to execute (Copy Features)."
  • Hope my use of the words "database connections" makes sense, I am referring to the "connections" available underneath the "Database Connections" options in ArcCatalog. – n34_panda Nov 6 '14 at 14:47
  • can you connect in ArcCatalog an in Command Line use the port:5151 (it might be blocked) – Mapperz Nov 6 '14 at 15:34
  • yes but that's the first time ever and I don't know how to test/what to type...I can see some of the commands executed in the scripts but nothing related to registering (sdetable -o unregister -t tablename?!) – n34_panda Nov 6 '14 at 15:35
  • I think I actually have to unregister, as the error states (when trying to import into another database connection (now realising these maybe actually cause geodatabases) "table already registered" - the error when tyring to unregister is above – n34_panda Nov 6 '14 at 15:43

Geodatabase corruption is difficult to resolve even when you've been using it for several years. When you add in ancient hardware, unsupported database software, and long-retired ArcGIS versions, you're approaching an intractable problem.

I can say this: You will not solve this by using command-line tools. The corruption is in a place where they do not reach. You can, however, make the situation worse with command-line tools, so I would strongly discourage further efforts.

Unfortunately, the only solution to fixing the database as-is (as opposed to moving to a pre-failure backup) involves executing SQL commands as the SDE user, which if done incorrectly, will destroy the still-accessible data as well. Usually this would be done under the guidance of Esri Tech Support, but it's been nearly 4.5 years since 9.1 was last supported. Worse yet, the geodatabase implementation changed significantly at 10.0, so that there might not be many folks with the experience to fix this instance.

I would recommend you first archive everything as it is. Then export all the data you can, into personal geodatabase or shapefile (if possible), and via 'sdeexport', and place a copy of the files on semi-permanent storage (for a system that old, a modern thumb drive might suffice).

Then you should contact your local Esri office and plead for assistance. It will likely take a contract or other legal document that holds those providing assistance blameless if the instance is not recoverable before they'll be willing to touch the system. Your best solution will likely be a new database in the old server with whatever tables can be recovered in it.

At that point your organization should review the costs of not upgrading, and plan for a future where this old hardware fails completely.

| improve this answer | |
  • Nicely said, Vince! – geogeek Nov 6 '14 at 20:27
  • Coming back years later but I’ll add, we didn’t bother. We migrated what we could to a new system and luckily for me I went back to what I knew rather than what I didn’t 😀 – n34_panda Apr 11 at 18:47

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.