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. or2. 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\subdirectoryfor /f "skip=4 tokens=1,2*" %%a in ('net files') do if %%b == C:\this_server\...\a00000225.gdbtable net file %%a /closeYou 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.
Jamal,Try to delete the contents of File Geodatabase after stopping the services associated with ArcGIS Server in "Windows Services"The other option is to use Task Manager, and select the ArcSoc.exe under processes and End Process.Regards,
Jamal, as Nidhin suggested, you need to ensure no ArcGIS Server process is still using your file geodatabase. Your second screenshot in your last post here, clearly shows the ArcSOC.exe process, which is part of ArcGIS Server (see this Help page and specifically the topic "Processes started by the GIS server"), still keeping hold of your file geodatabase files.So whatever you did to stop the relevant ArcGIS Server processes, something / some process (the ArcSOC.exe) is clearly still running and needs to be stopped before you can delete the remaining file geodatabase files.
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.
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?
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.
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.
NoWere you the only one connected to it at the time, after stopping the web service?
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.
Many thanks Leo for the help,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?
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.
Unable to delete �??file geodatabase�?�,But originally, why do I need to create replica?Jamal
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
