Copy ArcSDE Enterprise Geodatabase

4893
11
Jump to solution
04-15-2013 07:20 AM
LeoDonahue
Occasional Contributor III
Is it possible to make a copy of an enterprise ArcSDE 10.0 geodatabase on SQL Server 2008 R2 and move it to another instance of SQL Server 2008 R2 and rename the copy to some other name?  Using only SQL - no Arc products?
1 Solution

Accepted Solutions
VinceAngelo
Esri Esteemed Contributor
While it's possible, rewriting the majority of the triggers in a database is not
a supportable activity.  I certainly wouldn't attempt it, not when you can use
a named instance with the existing database name.

- V

View solution in original post

0 Kudos
11 Replies
VinceAngelo
Esri Esteemed Contributor
No.  The "rename" part is where the process would fail.

- V
0 Kudos
LeoDonahue
Occasional Contributor III
That is what I thought.

So if there are some people trying to hack the sde geodatabase by replacing all occurrences of the database name with a new name (simply by doing a find/replace in the triggers,tables, etc), that will still not work?

I'm about to feel somewhat vindicated here, but will hold off on my joy a few more moments...
0 Kudos
VinceAngelo
Esri Esteemed Contributor
While it's possible, rewriting the majority of the triggers in a database is not
a supportable activity.  I certainly wouldn't attempt it, not when you can use
a named instance with the existing database name.

- V
0 Kudos
LeoDonahue
Occasional Contributor III
Well, they did it anyway. 

They didn't like the database name and wanted it named:  databasenamedev

so it is going to work for them... ok... joy has left.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Cheer up -- it will likely fail in some inexplicable way down the road (or maybe
sooner, it they didn't take XML update into account 😉

In my book, wanting to change the database name is equivalent to wanting
to start database setup all over again.  Doing anything else is asking for
system failure.

- V
0 Kudos
LeoDonahue
Occasional Contributor III
I offered to install another sde instance for them, with a dev database name.  They said they didn't need my help, so it's out of my hands.  I wonder if this application they are trying to replicate in a development environment uses app server connections... hmm..
0 Kudos
LeoDonahue
Occasional Contributor III
Hold on a second.

Even if the client makes a direct connection to this copy, without ArcSDE being installed, what is the point of the "service" property using:  sde:sqlserver:databasename

Doesn't that still require ArcSDE 10.0 to be installed in order to use that?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Both flavors of access to the geodatabase require the same things to establish
connection.  If the metadata in the SDE (or DBO) user tables no longer point
to tables, then there will be trouble, but no, ArcSDE (the software) isn't required
to be installed, because Direct Connect *is* an ArcSDE server.

- V
0 Kudos
LeoDonahue
Occasional Contributor III
Connecting to this "backup, rename and restore" copy of SDE, via direct connect and without installing SDE on this SQL Server, fails.
<insert>  I KNEW IT!!  I TOLD THEM IT WOULDN'T WORK!!   Muahhaaahaaaaa!   lol.  </insert>

Now that this is out of my system...

The error message I got in ArcCatalog making a direct connection to this "backup, rename, and restore" copy of SDE.

Failed to connect to the specified server.
This release of the GeoDatabase is either invalid or out of date.
DBMS table not found [Microsoft SQL Server Native Client 10.0: Invalid object name 'databasename.sde.GDB_Release'.][databasename.sde.GDB_Release]


Client and server are both at 10.0, the production geodatabase was not upgraded, I checked.

I can not say whether this is related to not having ArcSDE installed on this instance of SQL Server or whether the sde login needs to be resynced after the backup and restore. 

I can say that the people administering this SQL Server are pointing to ESRI as the problem because they cannot log into the renamed geodatabase using the logins/passwords that the original production sde geodatabase had and they think that ESRI security is causing the problem.  I don't even know how to respond to that.
0 Kudos