04-07-2014 04:16 AM
I'm currently building a SAS Enterprise Guide project with a collegue. We will so share multiple versioning of this project between each other.
How can I avoid to redefine each time the path towards my databases? I mean: what is the best way?
I imagined to define a libname statement (with program box or libname box directly) or to choose the repertory via a prompt. But I cannot make a link between that and the "import data" box...
Thanks for your help!
04-07-2014 05:28 AM
Do you need to adapt the projects and code also (to changing DB structures)?
You could extract a date or version number from the projectname (_CLIENTPROJECTNAME).
Anyway, once you have a version number either from this or a prompt, the easiest thing to do is to assign the wanted (dynamic) path to a static library definition and use that all across the code.
04-07-2014 05:53 AM
Thanks for your fast answer. The input database will not change between me and my collegue. The only thing that will change between the different versions is the structure of the process flow.
We would like to avoid updating input paths each time we share a new version to the other (I only use "Import Data" boxes to import my csv files)...With the "import data" box, I cannot make a "dynamic link" to a particular repertory (or perhaps there's a way to do this but I don't know it).
I don't understand how to use a library definition since I used an infile statement in a data step to import my csv files. Could you elaborate on this a little bit more?
Thanks again for your help!
04-07-2014 06:25 AM
Look up the filename and libname statements in the SAS documentation, so you know what they do;
If you quote the physical file/directory names in double quotes, you can use macro variables to form part or all of the physical path names. The logical library of file name can then stay the same throughout the code.
04-07-2014 09:12 AM
For just one or two people cooperating sitting aside do not make too much troubles,
- you can define filenames libnames all of them in code that is started in a EGP flow named "autoexec"
- you can have this definitions (code) moved into an autoexec-usermods approach of your appserver by your platform admin.
For bigger projects (many developers).
Versioning of en EGP project file is impossible is it will get locked by one the first updater. Others leaving to have just read access.
In the basics an EGP file is a zipped containing all sources relations links etc. An IDE integrated Development Environment is not something suited for versioning.
What you can do is:
- use DI for building the programs. This tool is designed for ETL and an developpers
It supports check-in checkout at the development stage with also some support for SVN.
- You are still needing an approach for release management. Versioning and releases are not the same however often being confused.
The question: What is you Test Accepance and Production environment approach?
- You can develop Stored processes with Eguide and put those in release-management
- You can edit code with Eguide and use the (relative) links, not storing the code into a EGP project.
The relative links setting only works with Windows based approached not with Unix (Linux).
- Many links in the EGP project can get personalized not able to run by others, try to avoid that.
- scheduling/workflows should be solved by schedule tools (LSF) not being kept focussed as a EGP flown