TM1 Forum

Hi,
This is on PA 2.0.3

We've been having major issues with the account we use to query SQL (via ODBC) getting locked in one of our overnight jobs, causing all kinds of downstream issues.

In the process of tinkering with this to put some protection in place we established that no matter what we put in as DatasourceUsername and DatasourcePassword a query always ran successfully. We established that the query is running with the account the TM1 service is running under rather than the credentials we supply. (These are both the same normally, as is common practice(?))

Once we restarted the service with the Local System account we couldn't get anything to work, even using the correct credentials on the face of the TI.

I'm assuming this is a bug in the release we are on but has anyone seen this before?

Happy Fridays!

At 1 of my previous clients the DSN we used was set to use windows authentication (somehow not quite sure how) so with that 1 we just provided the DSN name without user or password and it took it from the system account that was running the service. Sounds like the set up you have could be similar?

1. The service id used to start TM1 can be use for Windows Authentication to your ODBC data source. This is automatically done if you do not put a username and password in the TI Process and if your ODBC Data Source has Windows Authentication enabled for your TM1 service ID. BTW, by setting the service ID to Local System, you are basically turning this off

2. Regardless of what service id use use, you can manually input the ODBC Data Source user name and password in the TI Process. This only works if your ODBC Data Source has enabled standard user id/passwords for the user id you are using.

I've used both methods extensively on many version of TM1. My guess is that while the TM1 Service ID and ODBC user name are the same but the passwords are different... or the user id is simply blocked from too many failed attempts.