TM1 Forum

Is it possible to pick up the server data directory location in a TI? I know you can use the GetProcessErrorFileDirectory command but this doesn't work if you have changed tm1s.cfg to have a different log directory (which we have).

Thanks!

PlanningDev wrote:Is it possible to pick up the server data directory location in a TI? I know you can use the GetProcessErrorFileDirectory command but this doesn't work if you have changed tm1s.cfg to have a different log directory (which we have).

I think that's an oversight in TI (you have, for instance, OptGet in Excel to get it, and IIRC there's a corresponding API function) but to be fair it's most likely because in the majority of cases there would be no reason to access the data directory in a TI (unlike in Excel). I can guess why you might want to, but it's probably not something that IBM support would encourage. Probably the easiest way to do it would be to have it stored in a control cube somewhere.

(Another way would be to have the TI parse the tm1server.log file (for those on a version where it's no longer locked) to find the relevant Info row, but that would be somewhat like using a sledgehammer to crack a peanut.)

Or parse the tm1s.cfg file.

Paul Segal wrote:Or parse the tm1s.cfg file.

The only problem with that is that you'd need to know which folder it's in before you could do that. The most common locations are either in the data directory (the very value that you're trying to get) or one level above that (which there is also no function to return). Some people may keep it in the logging directory (the one that you can get from a TI function, which is why I mentioned the tm1server.log file) but I doubt that it's common practice.

Good point.

Keep the data directory in a control cube somewhere?

Paul Segal wrote:Good point.

Keep the data directory in a control cube somewhere?

In the first reply Alan Kirk wrote: Probably the easiest way to do it would be to have it stored in a control cube somewhere.

I'm guessing that today is one of those days...

I'm going to stop now...

Paul Segal wrote:I'm going to stop now...

A large hot chocolate, and a warm bath followed by 6 hours sleep (an extended period for me) is my usual remedy.

Alan Kirk wrote:Another way would be to have the TI parse the tm1server.log file (for those on a version where it's no longer locked) to find the relevant Info row, but that would be somewhat like using a sledgehammer to crack a peanut.

A sledgehammer to crack a peanut it might be, but it is what I'd do as I think this is the only 100% reliable way to get the data directory (assuming 1/ that you don't know the configuration directory which seems reasonable if you don't know the data directory and 2/ that there is only a single data directory specified which will hold true 99.x% of the time.)
If either ASCIIOutput, ExecuteCommand or a text file data source don't have a location specified then the default location is the data directory so in theory you could ASCIIOutput to a bat file, then run the bat and the script could write the directory path to a 2nd file and you could then use that file as data file to read in the directory. But if you ask me this is actually an even bigger sledgehammer than reading the tm1server.log file AND it isn't 100% reliable since if the current directory has been changed in cmd prompt or a batch script for the ID under which the TM1 service is running then it isn't guaranteed that the data directory will be the default path if none is given.

Thanks for the replies.

The actual goal of this was to create a generic process to backup my data directory. If I knew the data directory and server name I could essentially ask for a parameter of target folder and create a sub folder of server name and zip up the data directory and place it in there.

Its not a huge deal as I could simply add two parameters for data directory location and backup folder name but it would have been nice to grab it automatically.

Thanks for the help

I'm with Paul on the parsing the cfg file route.

Even if you don't know the absolute path to the DataBaseDirectory, you should have a consistent relative path from there to the directory that contains the cfg file. If you don't, you should do.

When you create your process, point the DSN (for Client) to any tm1s.cfg file (using '=' as the delimiter will get you variables representing Parameter Name and Parameter Value). For the DSN on Server use a relative path e.g. ..\Config\TM1S.CFG

If you move the process from one server to another, then the path to the DSN (for Client) may become invalid, but as long as you Keep All Variables whenever you are asked, then the process will still work.

Andy Key wrote:I'm with Paul on the parsing the cfg file route.

Even if you don't know the absolute path to the DataBaseDirectory, you should have a consistent relative path from there to the directory that contains the cfg file. If you don't, you should do.

When you create your process, point the DSN (for Client) to any tm1s.cfg file (using '=' as the delimiter will get you variables representing Parameter Name and Parameter Value). For the DSN on Server use a relative path e.g. ..\Config\TM1S.CFG

If you move the process from one server to another, then the path to the DSN (for Client) may become invalid, but as long as you Keep All Variables whenever you are asked, then the process will still work.

You have more faith that the TI data source will always default to the database directory than I do, but I grant you that lack of faith is based on experience in some old versions quite some time back and it may be more predictable in newer ones. It's a good tip, though.

I'm in favour of having a consistent folder structure for all environments - tm1s.cfg in the main folder and Data and Logging subdirectories sitting under that main folder too. Or any other way that is consistent. Since you can easily get the Logging directory path using GetProcessErrorFileDirectory, it is easy to construct a formula that will return the Data directory, no matter what the environment. Something along these lines:

Alan Kirk wrote:

PlanningDev wrote:Is it possible to pick up the server data directory location in a TI? I know you can use the GetProcessErrorFileDirectory command but this doesn't work if you have changed tm1s.cfg to have a different log directory (which we have).

I think that's an oversight in TI (you have, for instance, OptGet in Excel to get it, and IIRC there's a corresponding API function)

Hello Alan

Small remark: Application.Run("OptGet", "DataBaseDirectory") in VBA will only point to the local server data dir location.
It will not work for TM1 models run as a service or as an application.

Wim Gielis wrote:

Alan Kirk wrote:

PlanningDev wrote:Is it possible to pick up the server data directory location in a TI? I know you can use the GetProcessErrorFileDirectory command but this doesn't work if you have changed tm1s.cfg to have a different log directory (which we have).

I think that's an oversight in TI (you have, for instance, OptGet in Excel to get it, and IIRC there's a corresponding API function)

Hello Alan

Small remark: Application.Run("OptGet", "DataBaseDirectory") in VBA will only point to the local server data dir location.
It will not work for TM1 models run as a service or as an application.

I may have been speaking too much from my own experience there. We have the folders containing the server data directories mapped as network shares, though obviously they're shares to which only the Admins have access. The same shares exist on the server, essentially as an alias to the server's local path. So in our environment U:\Server\Etc is valid as both the server and the "local" path, and points to the same place. But yes, OptGet can only be used in this way if the server is configured to allow such access.

qml wrote: ↑Fri Apr 12, 2013 10:37 am I'm in favour of having a consistent folder structure for all environments - tm1s.cfg in the main folder and Data and Logging subdirectories sitting under that main folder too. Or any other way that is consistent. Since you can easily get the Logging directory path using GetProcessErrorFileDirectory, it is easy to construct a formula that will return the Data directory, no matter what the environment. Something along these lines:

Code: Select all

sLogDirName = 'Logging\';
sDataDirName = 'Data\';
sLogDirPath = GetProcessErrorFileDirectory;
sDataDirPath = DELET (sLogDirPath, SCAN (sLogDirName, sLogDirPath), LONG (sLogDirName)) | sDataDirName;

old thread but deserves to be brought back into the limelight; this solution is perfect. all our models follow a strict folder design and this is an ideal way to grab the data directory. why do we need it? to parse .pro files in order to extrapolate information such as the source type / file paths etc because IBM never added that as an in-built function, even though you can set them...

You can also use relative file paths where the data directory will simply always be "."

This is however not 100% foolproof if cd is ever done in the cmd prompt by the system user that the TM1 service is running under.

Hi,

On a related note: does anyone use multiple data directories for 1 model ? We can specify multiple folders in the crg file but I have never been a fan of it.

I use multiple data folders. The functionality is so so with certain rules. But I use it track object creation. Using several. Folders I can see when weird junk gets created, and what's a part of my tried ans tested model.

Wim Gielis wrote: ↑Wed Feb 27, 2019 6:19 pm On a related note: does anyone use multiple data directories for 1 model ? We can specify multiple folders in the crg file but I have never been a fan of it.

I don't often use it but I actually think it's a good idea for things like frameworks or modules that are common to multiple TM1 models. It makes migrating and upgrading such components much easier and you have good oversight of the contents. However, it's a pain that you can't choose where new objects are located. Any new object will be created in the first listed data directory.

Some people get quite creative with multiple data directories. I saw one site where all processes over multiple production models were in a common folder "to ensure they are the same in each model".