I have a geoprocessing tool written in python.

It will be deployed on ArcGIS for Server 10.1 as a GeoProcessing Service and it's processing workflow includes some manipulations with data in SDE geodatabase.

Right now I've decided to save .sde file of connection (with login and password saved in it) and deploy it together with my script to ArcGIS for Server.

Another similar option is to deploy a .lyr file. In any of these cases deployment on another server requires additionally editing these files in ArcGIS for Desktop.

Can you advice any other methods for sharing data access to SDE GDB without exposing sensitive information (password)?

1 Answer 1


All the password information is stored Server side, so its just a matter if people can get to your Server or not. I'd say there are 3 ways you can connect/use SDE.

1) A GP Service which uses CreateArcSDEConnection tool. You can build up a connection to SDE at Service execution time. Somewhere inside the script you'll have in plain text the username/password. This way would be least secure. It would also be the worst in terms of performance.

2) A .sde connection file saved with your project. Your tool(s) use featureclasses from SDE via a path something like c:\myData\project1\connection to mySDE.sde\sde.features.points The connection file saves the credentials using either DB or OS authentication. If DB, then a username/password are saved inside the .SDE file. If OS, then whatever account running AGS needs access to your database. I'd say this way is "more secure" than the previous example. You can decide what way is more secure in terms of authentication.

3) Using layers from the map as input to your GP Service. The credentials are saved as part of the layer. (layers are created and persist when you publish). There isn't an actual .SDE connection file in this example, so you could argue its even "more secure" than the previous. This is the "best" way for performance reasons.

Really your Server is only as secure as you make it. The only real way someone can get this sort of information is to actually get onto your server or pull the pieces back to their machine which make up the service (and the arcgisinput directories are not web exposed unless you've made them). Even if they can get onto your server, passwords that are saved inside the .SDE connection file are encrypted, so they cant "see" them (same with layers). My point is, unless you've written the SDE connection password somewhere in your script in plain text, I couldnt envision a way someone would ever be able to get it.

  • One way I have improved the performance of method 1 is to store the created connection file in the temp folder using a complex naming format. Then, before creating the file, I check for its presence in the temp directories. You can also used compiled python (.pyc) to run the service and even use password encryption with an encrypted config file. This will make it easier to change your password without building and placing new connection files; and hence make it easier to share the tool. Dec 4, 2012 at 14:19
  • Maybe I should have clarified "worst performance". I say this because A) its the overhead of running a tool to do something, so thats like what, 1 second? and B) Using something from the connection file means you're accessing the featureclass. Layers are always faster than featureclasses (layers explained in point 3 above)
    – KHibma
    Dec 4, 2012 at 18:12
  • I also have read somewhere that layers are faster, but do you have any description why are they faster? Just curious... Dec 4, 2012 at 22:34
  • 1
    Because featureclasses have to be opened at execution time. If they are "layers", the service has them open and ready. For example, we dropped 25% (~0.5 seconds) of the processing time in the Viewshed SampleServer service by using the raster input as a layer vs raster "on disk". If you haven't seen this topic, give a quick read (note layers are 1st on the list) : resources.arcgis.com/en/help/main/10.1/#/…
    – KHibma
    Dec 4, 2012 at 23:20
  • Thanks! I definitely should try to use layers next time. Dec 5, 2012 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.