In_Memory Connection Files on The Fly Python

391
2
12-30-2013 01:43 PM
Status: Open
Labels (1)
KenCarrier
Regular Contributor
I would like to purpose the ability to create connection files on the fly via Python.

This could be applied to ArcGIS Server, ODC, and SDE connections.(*.ags,*.odc,*.sde)

Currently in_memory acts like a temporary database but what would be nice is to be able to store Esri file formats in this location as well.

When scripting, a connection file must reside somewhere on disk and be accessible to the script. Through my proposal these connection files would no longer be needed and could be created on the fly within the script thereby making the script more portable and manageable over time. 

Things like mapped drives, network shares, and servers are not always available and sometimes when a script is scheduled to run one of these devices might not be online, which would cause a script to fail. If we were able to build a connection file on the fly and store it in a temporary workspace like "in_memory" it would make the script easier to move from one location to another not to mention making it more error proof.

If "in_memory" cannot be used would it be possible to create another temporary workspace for Esri file formats or simply connections? Maybe instead of calling it "in_memory" it could be called something like "cached_connections". Then when using the Esri tools if we specify "cached_connections" in placed of something like "Database Connections" the logic behind the tool would know we are expecting this to only exist temporarily.

Thank you for your consideration.
2 Comments
BruceHarold
Hi

A secure and portable way to do this would be to use tempfile.mkstemp to create a unique name for the connection file, then use that name in arcpy.CreateArcSDEConnectionFile_management.  You would need to delete the file after completing your process.

Regards
KenCarrier
@bruce_harold - while I agree there are a number of different ways to accomplish certain tasks, you are still talking about writing and reading from disk because a file is still part of the equation.  What I am purposing would aleviate reading and writing to disk and allowing it to be done in memory. This way no matter where the script is moved the connection to an enterprise database would continue to work. The issue some have raised with this method is having a username and password stored in the script. My theory on that is lock it down at the folder level so the script can only be accessed by a certain individual(s). Much in the same way if you store your connection files on disk, while the password is encrypted, if the connection file is exposed to others then your data is still accessible. So in short my theory while not as secure as encrpytion with a connection file, is still more portable in my opinion. Thank you for the response and suggestion.