Funny, Martin, I had the exact same thought this morning while getting ready for work, but couldn’t test it until I got to work. Even told my wife "just you wait, I’ll get in and someone will have already suggested this possible fix’.
Well, I did test it, and it failed. Tried escaping the backslash in the comparison, even escaped it in the ROOT_PATH definition in the Settings, No go.
So I took ROOT_PATH down to its bare bones and set Test Env to N and Prod Env to E. Then I tested for ‘#ROOT_PATH#’ = ‘N’ or ‘#ROOT_PATH#’ = ‘E’, which worked! So something about the backslash was causing issues in the string compare. I then had a Set Variable Value step after each test to set ROOT_PATH to the proper value (including escaped backslash). I even added back in the colon to make sure it was the backslash, and N: or E: worked as well.
Thanks to everyone who pitched in.
Considering that hharwood’s main issue is that the File location is variable, and, as TDP’s variables cannot be used everywhere in the script, he cannot use them to access the files.
I just proposed to him, that as the File he needs may come from 2 VARIABLE folders, he may want to consider using a THIRD “NON-VARIABLE” folder.
The “Copy File” activity will accept a TDP-Variable to “Copy From”, and from that moment he will only use the THIRD “NON-VARIABLE” folder. This way he’d be:
-
- Using TDP’s Variables where they can actually be used.
-
- Forgeting about having to create multiple Import Activities, because, he’ll only be using the THIRD “NON-VARIABLE” folder regardless of the environment he’s in.
All he has to do is make sure that the THIRD “NON-VARIABLE” folder exists in both environments.
No shared folder exists, so my solution currently has to work with two disparate file locations.
Made a new version of one my scripts, complete with If branching based on test vs prod. Ran fine in development, but when I tried to publish it, TDP threw an error on the E:\ paths I had defined for the production branches, as it could not connect to them from my notebook. So I’m afraid I’m where I least wanted to be: manually copying the script and import files to the server and then hand modifying them to run in that environment. Hopefully we’ll get permission to map to a common network share, and can go back to a single copy of each script/import that can be published to TIC.
For the IF activity usage, here might be a better solution:
- adding Run Program activity that executes cmd.exe /c "" dir file.txt and has both of the GenerateError settings disabled in the ActivityInfo tab
- Adding IF branches to check for the variable representing return code from the previous RunProgram activity (0 = success, anything else = error)
- based on the "determined environment" apply whatever logic is needed in the respective branches
But what i am not sure is what will you do in the IF branches in order to prevent maintaining 2 versions of the import script? Since obviosly importWizard doesn't handle variables well, you should perhaps use Copy file activity that copies the right files from right folders into "temp" so that ImportWizard can import those files from temp which is a static folder...
Martin
