Each time when we save a TI processes, regardless of any changes in the TI process, it keeps changing a line of the .pro file that starts with 565. This line is automatically generated and updated by TI everytime a TI process changes.
Can I ask you why you would need that property? Or put differently, can't you ignore it?
Are you checking the timestamp of the *.PRO file maybe?
Best regards,
Wim Gielis
IBM Champion 2024-2025
Excel Most Valuable Professional, 2011-2014 https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
That's not the only line that can sometimes have random values that are nothing to do with what you have entered in the process.
Unfortunately the only guaranteed way to avoid false changes is to write a program to strip the process down to the bits of it that you use and store that in your SCM system. However getting the list of which line headings correspond to which features is not trivial. It would require hours of very careful experimentation to know that you had got the lot. I vaguely remember that the one you are looking at is a (loosely) encrypted version of the password for the ODBC connection - which you are probably not even using anyway.
The problem is that entries for features that you don't happen to be using (e.g. ODBC entries for a text source) are still filled with random junk, and get saved with new random junk every time you change anything.
What Duncan said. (And his memory is correct, 565 is the encrypted data source password for ODBC/ODBO, though it was unencrypted in versions prior to 8.3.)
Which leads me to my point; the headings can change from version to version. Not so much that a heading is used in something different in version y compared to version x, but rather that a heading may disappear, or a new heading may appear without any change to the actual TI code. I'd therefore be wary of relying on the .pro files alone for software control. I don't know what you're using or how but you'd probably need to just extract the code from the four tabs to be sure that nothing changes. (And even that wouldn't cover you against parameter or data source changes.)
Yes, this "feature" makes it very difficult to detect changes correctly for a revision control system.
I find it very annoying, but it's usually enough for me to just manually roll back the ones I know for sure haven't changed. This would be a lot more difficult in a large project with multiple team members, so it would be nice if it weren't the case.
However, I wouldn't look for the changes to come from IBM. Look for a way to deal with it within your particular revision control system, or by scripting something to avoid the conflict.
Take your TM1 experience to the next level - TM1Innovators.net
I have about 200 processes in a TM1 server and we have a number of TM1 servers instances and each server has about 80% of the processes shared between different instances. Moreover we are working in a team of TM1 developers.
In order to manage and control the changes to the processes and to other code objects and to synchronize the shared ones across different environments, we use a code revision control system (subversion) and file comparison tools (such as winmerge).
However, having TM1 process files automatically and randomly changing in each save makes it very difficult to track changes to the process files. A process file seems to have changed, although it is effectively the same except the line that starts with 565 code, which does not make any difference to the way the process works.
I think IBM should fix this issue to avoid process files keep changing in each and every time regardless of having any ODBC password in the TI process.
Kind regards
Last edited by mce on Sat Mar 08, 2014 11:01 am, edited 1 time in total.
