|
POST
|
Greetings all, Did anyone find out about this issue at UC?
... View more
07-22-2014
09:45 AM
|
0
|
0
|
2456
|
|
POST
|
Sure thing. The only time that I must stop services in our workflows are when those services have to persist a shema lock, as is the case with mobile and feature editing. But in those cases the mobile and feature services are being sourced directly to a version in our edit sde instances. I didn't realize you were still on IMS, but as far as schema changes go: they should be planned and infrequent and when they do occur you will need to overwrite your map services. Further, if you are that concerned about losing data, then perform some type backup prior to fdgb removal. As far as Tyson's comments are concerned, we have succefully employed full versioning and replication (we replicate via historical archiving) workflows since 2007. Don't get me wrong: over 95% of the data in our dynamic map services is sourced directly from our production sde,where data syncs occur weekly to production and data is never out of date- Thanks David
... View more
07-02-2014
10:24 AM
|
0
|
3
|
4591
|
|
POST
|
I would have to agree with Vince on this. I can tell you that when you set up your SDE repositories (at least in SQL) as either SDE or DBO (depending on your model) sde or dbo will own the system tables. For example, since we use direct-connect, DBO owns all the SDE system objects. But once you add a headless user, and assign object-ownership rights to that user through your rdbms, all user GIS data will then be owned by that user as you 1: connect to your user dbs as the headless owner, and 2: then load data (featurdatasets, featureclasses, tables). This way, all user-schema changes have to be performed as the data owner while administrative tasks are performed as SDE (or dbo) protecting integrity and performance- David
... View more
07-02-2014
08:10 AM
|
0
|
0
|
1254
|
|
POST
|
I'm sorry but this seems like a solution that is looking for a problem. Per best practices (and you can ask Mike Jensen at ESRI), in ANY rdbms, you should be creating and using a headless data owner in your rdbms, then assigning privileges appropriate to that owner. DBO or SDE should never own the data or schema, and unless each of your users is an sde administrator themselves capable of understanding and managing sde geodatabase objects, versioning, states, etc. they should never own data either. For example, on our production geodatabase, GIS owns all data. Users and AD groups are placed in view-only roles. Our production geodatabase is actually the child gdb of our 11 edit user database instances, to which we replicate data weekly. In each of our edit database instances, each utilizes a headless data owner and users are assigned to editor roles with view, create, update and delete privileges. Thanks David
... View more
07-01-2014
06:00 AM
|
0
|
0
|
1254
|
|
POST
|
Hi Matt- No, just the cache directory for the service. I delete the service, then delete that services' cache folders. You may or may not have to stop each ArcServer.exe process on each of your site machines (ie stopping the site) in order to delete the services' cache folders'. We found that we had to in order to remove the services' cache folders containing the corrupted bundles because windows would not let us completely delete the directories otherwise. Robinson at ESRI contacted me yesterday asking if I was seeing the same behavior (when running the ManageMapTiles Recreate or Delete Tiles) from both python and catalog to which I responded yes I am- David
... View more
07-01-2014
05:19 AM
|
0
|
1
|
2456
|