Feature classes locked by ArcGIS server services

[JacksonTrappett]

I have several models that we use to update our datasets on a weekly or monthly basis due to changes in parcels and new annexations, etc.  The final output of these models overwrites production feature classes in our SDE geodatabase.  These same feature classes are used by our ArcGIS Server services for our web maps.  Of course every time we run the models I first have to stop the services so that the SDE datasets are not locked while they run/overwrite.

What I'm looking for is one of two things:
A. A way in model builder to stop and then restart the services only during the part of the model that is overwriting the feature class.  Can services be stopped and started in Model builder?  I haven't seen a way yet.  This option would allow me to run our large models (some of them take 30 to 45 minutes to run) without having to have the services stopped for the entire time, which I don???t like to do because it makes them unavailable to customers for the duration.

B. A better publishing model for ArcGIS Server that doesn't lock the datasets.  The only one I've been able to come up with so far would be to have two copies of the same SDE database.  One of them would be the one we update with our models and edit, and the other would be the one the ArcGIS server services are hooked into.  The two would be linked by one way replication, which can synchronize the changes without having to stop the services.  This seems like the best option to me but it requires quite a bit of work to create and maintain another SDE geodatabase.

Anyone have ideas for me on either A or B or both?  If A is possible I will probably just go with it since it is much easier to set up and maintain.

[KevinHibma]

Jackson,

You'll probably address this issue more on the Server side than you will with your Models.

Have a look at this help topic: http://help.arcgis.com/en/arcgisserver/10.0/help/arcgis_server_dotnet_help/index.html#//0093000000mr...
and search for: <SchemaLockingEnabled>
(this is a 10 topic but this specific point should be the same for 9.3.1).

As stated, use caution when using this tag. Though it sounds like you're already aware of the risks and what you need to do.

Hope this helps.

[JacksonTrappett]

Kevin, thank you for the reply.

I took a look at the <SchemaLockingEnabled> property of the service configuration and it seems like a good solution but I finally settled on using the AGSSOM tool inside a script in my model to stop and start the service  while the overwrite is taking place (as suggested by Andrew in the ArcGIS Server General forum.)

Here's a link to the AGSSOM tool for anyone interested in this functionality:
http://resources.esri.com/arcgisserver/adf/dotnet/index.cfm?fa=codeGalleryDetails&scriptID=16293

[GaryBraun]

I'm having virtually identical problem as the one posted by Jackson, it's a major P.I.T.A. to refresh data in SDE once it' s being consumed by a web service so I'm looking forward to trying out the <SchemaLockingEnabled> in 10.

I do have one follow up question along the same lines though; why would I have schema locks on an feature class that isn't being used by any of my web services?  At least it shouldn't be used by the web services because it isn't referenced in any of the MXD files they are using, yet I can't delete the feature class unless I shut down all of my ArcGIS services first.  What's up with that?

[MeleKoneya]

Like others in this thread,    we have been having some issues updating our SDE feature classes when they are used by ArcGIS Server Map Service.   I just tried adding the schemalockenabled tag set to false on a map service on ArcGIS Server 9.3.1 SP1 and was not able to update the feature class as it returned a lock on the feature class.      We have been using the 'sledge hammer' approach of stopping all ArcGIS Map Services while loading data, but it would be nice to not have to stop these services.

I am wrong in believing that this functionality was added in SP1?

We also break connections to our ArcSDE databases using SDEMON -o kill, but this does not work against the ArcGIS Map Services so we have to stop them.

I am curious as to how others are dealing with these locking issues so let me know if anyone in this thread has made some progress in dealing with this.

Thanks,

Mele

[JasonWise]

I think you can avoid all these issues by deleting and appending features instead of overwriting a whole feature class.

If you run a tool that replaces a feature class, then you're actually deleting a feature class and creating a new one.  In other words, you're changing the database schema, even though the schema ends up looking just like what you started with (same feature class and fields).

An alternative is to keep the existing feature class, delete the features from it, and append new features into it.  This way, you don't need a schema lock, even though the end result is the same as the other method.

[RobertHu]

Hi Jason,

Thanks for your info.

I'm currently using sde commands in shell script to update those locked FCs,
sdetable -o truncate ...
sdeexport -o create ... | sdeimport -o append ...

Our data maintenance people don't have access to the sde commands. I've been looking for a way so that they can do the same thing in ArcCatalog, but never realized the Delete feature and Append tools can do it.

Thanks again!

[MeleKoneya]

Thanks Jason.

I have rewritten my import code to Delete and then Append.   By doing so it alleviates the Locking issues both with ArcGIS Server and ArcMap Desktop clients accessing the data.    Great suggestion.

[BartPouteau]

I think you can avoid all these issues by deleting and appending features instead of overwriting a whole feature class.

If you run a tool that replaces a feature class, then you're actually deleting a feature class and creating a new one.  In other words, you're changing the database schema, even though the schema ends up looking just like what you started with (same feature class and fields).

An alternative is to keep the existing feature class, delete the features from it, and append new features into it.  This way, you don't need a schema lock, even though the end result is the same as the other method.

I'm having similar problems and was considering this approach.  My concern is that since our data is versioned, repeatedly deleating records only to repopulate them along with a few changes is going to have a significant impact on the size of our delta tables.  Can anyone using this method with versioned data comment on how significant the impact actually is?

Thanks.

Bart

[RandyKreuziger]

Bart,
  You don't have to version the feature classes that have there records deleted and appended.  There is no reason to that I can think off.