jim wood wrote:Alan Kirk wrote:jim wood wrote:That will work for the server address and it will also work for client if they (including myself there is development team of at least 6 guys, most part time.) are able to develop all processes on a remote desktop to the development server. That I'm not sure they have (the permissions) but I'll check. Even then there is the MS remote desktop connection limit so I'm not 100% certain how practical that will be, but something worth considering.
Jim, you don't
need to be doing everything on the server side.
Data Source Name is in fact where the TI process will look for the data source while you're editing it. (When it runs it uses Data Source Name On Server unless you override it, which is what you're doing.) Consequently each of your team can just as easily create Tomok's suggested folder of C:\ImbeingabuttheadITdept
on your local machine and put DataFile.txt inside it. You'll still be able to edit the process using that as your data source. You may get a warning about the possibility that the data source is not available on the server, but who the h3ll cares; as noted above you're overriding the path in the Prolog anyway so neither the value in Data Source Name nor the one in Data Source Name On Server will ever be used when the TI process is run. In fact this is essentially what Michel was getting at.
I understand all that. The problem is that their local c: drives are locked down. They can't use them.
Jim, we have been through this
before. Locking down My Documents on the C:\ drive does not,
does not= "Locking Down The C:\ drive". If it did, applications would cease to function. They would become immobile. They would not work. No IT department, no matter how anal, can lock down the %APPDATA% path without rendering all functionality of the applications on the system null and void. There is always some path on the C:\drive that can be used, including an All Users one.
jim wood wrote:The only way around it I can see is if they create a standard drive letter for teh team with a shared they use for creating the files. That however comes with the danger of being overwritten by a global drive letter in the future. They could ask for a set drive but knowing the way things go they would be told to add a share to their server, but we've already been told by the server team that they can't do that either! It's all fun and games I tell you.
The best solutino for me is if there were some function (or way) of extracting teh variables from the set server data. Do you think I should add that to the development request list???
Why does this triviality need to be so complex?
There are only two times when the path to the data source matters. One is at design time, one is at run time. In between, whatever the .pro specifies as the path is entirely immaterial.
At design time you can set the local path to wherever a copy of the sample data file is. This does not now and never needs to in the future correspond with where the actual runtime file will be. It doesn't even need to correspond to where the initial development was done, nor does it even need to be the same for each developer. You can set it to that path when you need to edit the thing (and really, how often and how regularly are you needing to edit it anyway?), refresh the data source and bingo, you have all of your variables to work with. You have 6 developers? So what? You can have each of them use a different path if you need to or alternatively point it to a network share as you mentioned. That letter changes in the future? Who cares? Use a UNC reference instead. The UNC reference changes? Doesn't matter; see the earlier points about "It doesn't even need to... etc" above, But the point is that as long as you are pointing it to
some path, whether it's the same one that you initially developed on or not,
any path which has a sample file in it then you'll be able to do whatever you need to when editing it, though personally I tend to regard development as a one shot deal aside from minor bug fixes or external system changes.
The other is at run time and if you're overriding the path to the data source, as you've indicated that you will be, by reading it from a cube in the relevant environment it matters not one iota what the original path specified in the .pro file is, or whether it even exists in that environment.
Jim Wood wrote:As for making the field blank before promotion, as stated they want it all, they want promotion automatically without any manual input. I know, I know....
But
that's the whole point of being able to change the variables. It means that you can copy a process to another environment and it will still work because the default values are no longer connected to the runtime values and vice versa. It's not a bug, it's not a feature, it's just the way the sodding thing was designed to work in the first place and
that is what your august clients need to be made to understand.
(And incidentally, given their security-mindedness
surely they would see the virtue in having the .pro file's data path pointing to a development environment only since, after all, that
is the only place that it should be edited, n'est-ce pas?)
That Dilbert cartoon summed it up perfectly, security is fine but if it stops you from doing the job in any manner then it's useless to anyone.
) some suitable paths.