Unable to delete ???file geodatabase???,

1232
19
Jump to solution
09-29-2013 10:55 AM
Highlighted
by Anonymous User
Not applicable
Original User: Jamal432@gmail.com

Unable to delete ???file geodatabase???,

I wanted to delete the file geodatabase but sounds not to work and got the message below knowing that this file goedatabase is a replica from the enterprise geodatabase ???N??? and from which the data is published by the ArcGIS server.

[ATTACH=CONFIG]27856[/ATTACH], [ATTACH=CONFIG]27857[/ATTACH]

What might be the issue then? why it is impossible to delete this file geodatabase?

To give a context for this problem, I???m frequently used to delete this file geodatabase (which is a replica from the enterprise geodatabase ???N???) due to the fact that some changes on the enterprise goedatabase are not reflected to the replica when synchronize (then the easiest way is to delete the old replica and to create a new one) such as :

1. If feature class added to the enterprise geodatabase then it is not added to the replica when synchronize

2. If a field is added to a feature class in the  enterprise geodatabase then this field is not added to its feature class in the replica

But originally, why do I need to create replica?

I publish the data from the replica (file geodatabase) but not from the enterprise geodatabase to gain some performance. If the data is published directly from the enterprise geodatabase then accessing the published data (services) gets quite slow.


Thank you

Best

Jamal
Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
MVP Regular Contributor
I made this suggestion in a different-but-related post from earlier this month, but it may help if there happens to be a process lock on one or more of the files within your file geodatabase.

If you are still having issues with deleting a geodatabase on the file system despite the fact that the .lock files no longer exist, it's possible there is still a process lock on one or more of the files within it. That being said, if you're using Windows Server 2008 / Windows 7 or later you can try one of the following methods:

1. From the Start menu, type FSMGMT.MSC, then multi-select the files you want from the GUI, then right click them and chose "Close". That method should force close the files that are technically still open due to a process lock.

or

2. From a batch file, run the following (example is for a file geodatabase) to close a file named a00000225.gdbtable:

cd C:\this_server\directory\subdirectory
for /f "skip=4 tokens=1,2*" %%a in ('net files') do if %%b == C:\this_server\...\a00000225.gdbtable net file %%a /close


You can modify the command above to loop through all of the files in the file geodatabase to close them all rather than specify them individually, which would be tedious since there are so many.

From the command prompt, type NET FILES to see what the underlined text above should contain.

Remember that double percent characters are required for batch files (in other words, %% rather than %) but single percent characters are used when running the command outside of a batch script.

View solution in original post

Reply
0 Kudos
19 Replies
Highlighted
Regular Contributor
Unable to delete �??file geodatabase�?�,

But originally, why do I need to create replica?

Jamal


From the ESRI online help: "Geodatabase replication is built on top of the versioning environment"

Normally, you create a replica to distribute changes in a versioned featureclass from one geodatabase to another.  Is the data in your primary File Geodatabases versioned? 

If you are going to delete your FGDB that is a replica, you should probably delete the replica that points to that FGDB first.
Reply
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: Jamal432@gmail.com

From the ESRI online help: "Geodatabase replication is built on top of the versioning environment"

Normally, you create a replica to distribute changes in a versioned featureclass from one geodatabase to another.  Is the data in your primary File Geodatabases versioned? 

If you are going to delete your FGDB that is a replica, you should probably delete the replica that points to that FGDB first.


Many thanks Leo for the help,

Sure I did! But with no luck.

1. I deleted the replica from the two sides (parent and child)
2. I stopped the services in which features classes of the file geodatabase are participating
3. I stopped the SQL server

[ATTACH=CONFIG]27895[/ATTACH], [ATTACH=CONFIG]27896[/ATTACH], [ATTACH=CONFIG]27897[/ATTACH]


Nevertheless, I couldn�??t delete it. I restarted the machine, then I could delete it

Do I need to restart the machine to be able to delete a file geodatabase?

What else I need to delete/stop to be able to delete the file geodatabase without the need to restart the machine?
Reply
0 Kudos
Highlighted
Regular Contributor
Many thanks Leo for the help,

Do I need to restart the machine to be able to delete a file geodatabase?

No

What else I need to delete/stop to be able to delete the file geodatabase without the need to restart the machine?
Were you the only one connected to it at the time, after stopping the web service?
Reply
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: ZachLiu

I remember it happened to me at one time. I just deleted the tables from the database, not within arcCatalog, and then you can delete the geodatabase.
Reply
0 Kudos
Highlighted
MVP Esteemed Contributor
1. If feature class added to the enterprise geodatabase then it is not added to the replica when synchronize


That is correct: there is a way to add other features to an exisiting replica, but the method escpes me.  Personally, I create individual replicas for each feature class I replicate.  It keeps things separate if the process goes south.

2. If a field is added to a feature class in the enterprise geodatabase then this field is not added to its feature class in the replica


Correct again:  That's actually a pretty cool feature of replication.  The parent/child feature class can have different attributes and only share a set of core attributes.  I manage an enterprise database of streets: each of the clients (various cities) have thier own specific needs and uses for the data. I use it for 9-1-1 dispatch.  So I don't care what type of paint a city uses to to stripe the roads, or when that paint was applied.  On the other hand, they have no need for for dispatch zones etc that I use.  But, we all need address ranges, names, prefixes suffixes, typest etc.

But originally, why do I need to create replica?

Beats me.  What are you trying to accomplish?  I like to use one way replication for what you mention below.  I only edit the parent/SDE feature class and then replicatate to a FGDB which is tapped for publishing.

I publish the data from the replica (file geodatabase) but not from the enterprise geodatabase to gain some performance. If the data is published directly from the enterprise geodatabase then accessing the published data (services) gets quite slow.


I suggest you DELETE the published service and then try to delete the FGDB associated with it.
Reply
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: Jamal432@gmail.com

No

Were you the only one connected to it at the time, after stopping the web service?


Many thanks Leo.

Let�??s assume that others were using services (that are reading the data from the replica/file geodatabase) at the time when I stopped them. Don�??t we have then a robust way to disconnect whatever related to this replica (file geodatabase) to be able to delete it?

All what I want is to delete the replica.
Reply
0 Kudos
Highlighted
Honored Contributor
I remember it happened to me at one time. I just deleted the tables from the database, not within arcCatalog, and then you can delete the geodatabase.


Many thanks Zach,

Could you please elaborate a bit more? Which tables I need to delete to be able to delete the replica (file geodatabase)?

[ATTACH=CONFIG]27939[/ATTACH], [ATTACH=CONFIG]27940[/ATTACH]
Reply
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: Jamal432@gmail.com

That is correct: there is a way to add other features to an exisiting replica, but the method escpes me.  Personally, I create individual replicas for each feature class I replicate.  It keeps things separate if the process goes south.



Correct again:  That's actually a pretty cool feature of replication.  The parent/child feature class can have different attributes and only share a set of core attributes.  I manage an enterprise database of streets: each of the clients (various cities) have thier own specific needs and uses for the data. I use it for 9-1-1 dispatch.  So I don't care what type of paint a city uses to to stripe the roads, or when that paint was applied.  On the other hand, they have no need for for dispatch zones etc that I use.  But, we all need address ranges, names, prefixes suffixes, typest etc.


Beats me.  What are you trying to accomplish?  I like to use one way replication for what you mention below.  I only edit the parent/SDE feature class and then replicatate to a FGDB which is tapped for publishing.



I suggest you DELETE the published service and then try to delete the FGDB associated with it.





Many thanks Joe for the answer,

1. There might be some advantages for the current behavior of the �??synchronize changes�?� between the source and destination but what I wanted in my case is to get all the changes occurring on the source (enterprise geodatabase) updated in the destination (file geodatabase) such as adding layers/ adding fileds/editing features/editing records/etc.

2. Till now there is no geoprocessing tool by which one can create replica for the data that contains tables (not feature classes)

3. Sure, we gain some performance when the data is published from the file geodatabase but not from the enterprise geodatabase, and this is why I use the replication in my case

4. But is there a way to detect the services the replica is participating in? do I need then to delete all the services that might be sourced to that replica just to delete the replica?
Reply
0 Kudos
Highlighted
by Anonymous User
Not applicable
Original User: ldonahue

Many thanks Leo.

Let�??s assume that others were using services (that are reading the data from the replica/file geodatabase) at the time when I stopped them. Don�??t we have then a robust way to disconnect whatever related to this replica (file geodatabase) to be able to delete it?

I was referring to anyone else directly connected to your file geodatabase, not through the web services.  If these file geodatabases are only accessed by the web service, then stopping the web service should let you delete the file geodatabase.

I believe Zach was suggesting to delete the contents of the file geodatabase, then delete the empty geodatabase container.
Reply
0 Kudos