TM1 Forum

Hello All,

This might sound a bit weird. But is there a way for us to disable the 'Preview' being shown automatically while opening a TI process using ODBC?

Reason? Long story short, we want to avoid database account lockups. So, we don't want TM1 to try to connect to a ODBC as soon as we open the process. Users can use Preview button if they need.

Please let me know if there is a way. Probably some setting in some config file etc?

What about the "Use Unicode" setting in your TI process ?
Is it enabled or disabled ? Also
http://www.tm1forum.com/viewtopic.php?f=3&t=1668&p=8758

This might give you a pointers .

Karthik1710 wrote:Hello All,

This might sound a bit weird. But is there a way for us to disable the 'Preview' being shown automatically while opening a TI process using ODBC?

If the problem you want to avoid is hanging of the user session every time the TI process is opened for editing due to a heavy query then the standard way to deal with this is to introduce a WHERE in the SQL statement with a parameter value that will quickly return a small dataset. Or you can simply use a generic default query in the data source tab with the column variables that you need and set the actual SQL statement that you want at runtime by manipulating the DatasourceQuery variable on the prolog tab.

Modify the query in such a way that there is a 'WHERE 1 = ?pRun?'.
Store the process with parameter pRun with 0 as default value. Upon executing the process set the pRun to 1 in order to correctly execute the query.

nick_leeson wrote:What about the "Use Unicode" setting in your TI process ?
Is it enabled or disabled ? Also
http://www.tm1forum.com/viewtopic.php?f=3&t=1668&p=8758

This might give you a pointers .

Thank you, we do have some of those suggestions already implemented. I think its time I explain this a little more..

Basically most of our DBs have Compliance and Security guidelines to keep changing their passwords frequently. Especially the ones in the Dev environment. So, whenever DBAs change the passwords we were forced to open each TI process and update the password. As this was a pain, we made it a standard across models to store the DSN info like Data source name, Userid, Password etc in a cube and reference those from Prolog of TI.

However, for most of the processes even today the DS names and Usernames stored in TI are accurate. But, the passwords have got changed. So, 3 separate users trying to open processes using same DS results in an account lockout at DB level. My initial idea was to just update the userids with dummy names but I am talking about 200+ processes, so opening each one of them and updating usernames doesn't sound like an efficient option. Which is why I asked about disabling the preview option altogether.

Hope someone has an answer or some kind of work around.

Don't know you have to open all these TI's. You only have to open a TI (and thus get the preview screen) whenever you need to CHANGE the process and if you are changing the process you probably want to get the preview to make sure all your variables are accounted for properly. If you do not intend to change the columns in the source then why not set the Data Source to be a flat file and then dynamically change it to ODBC in the Prolog. This way you will only access the DB when the process is run, not edited.

tomok wrote:Don't know you have to open all these TI's. You only have to open a TI (and thus get the preview screen) whenever you need to CHANGE the process and if you are changing the process you probably want to get the preview to make sure all your variables are accounted for properly. If you do not intend to change the columns in the source then why not set the Data Source to be a flat file and then dynamically change it to ODBC in the Prolog. This way you will only access the DB when the process is run, not edited.

Thanks Tomok. But, changing the Data source to Text file from ODBC is same as updating a dummy userid in the process. And that is not my problem. As I explained above, the issue is the number. I do not want to waste time by sitting and opening all 200+ processes and change data source to Text from ODBC or update a dummy user id. You can imagine how many weeks it might take for me to do that.

Maybe a DOS script to change .pro? You'd need to test very carefully as I believe there are some checksums that can be messed up.

The key thing with manually editing .pro files (apart from don't) is to ensure that the line count for each code section is correctly shown in the header row for that section. Each code section is identified by a header row with two numbers, the first identifying which section it is and the second being the line count. If you add a line in the section without updating this second number then the bottom of the section won't get read by TM1. Conversely if you delete lines without updating the line count TM1 will read rubbish from beyond the end and who knows what will happen.