Scheduler Tasks Failing

[mralbert]

Hi, Starting last week, a large percentage of our scheduler tasks started failing. We have identified that the only tasks failing are the ones reloading apps connected to databases. This is occurring on apps that have data connections via ODBC (i.e., DB2, Oracle, and SQL Server). Interestingly, we can manually reload the apps successfully from the Hub, but it fails when we try to reload from the QMC. Here is the error: Error: Connector connect error: SQL##f - SqlState: 28000, ErrorCode: 18456, ErrorMsg: [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Login failed for user 'SQL_XXX_XXX_QLIK'. Before my role as a Qlik Administrator, I was a SQL Server DBA, so this error is familiar. I checked with a colleague to verify the cause of the login failure and they told me the SQL error logs indicated a password mismatch which could be one of two things: 1) a blank password, 2) a wrong password. This is baffling to me as we use Mixed Mode Authentication on SQL Server and it was working previously through the Scheduler. We have been running a large environment for a couple of years. Our last upgrade was over 6 months ago. To my knowledge, there have been no major environment changes. Does anyone have any ideas? I am wondering if we have corruption within our Repository...

[Anil_Babu_Samineni]

1) If previous works and now it is not working is the weird behaviors

2) Can you check where are you trying this? I meant locally or server

3) If server, Could you please check If your account is part of that server service account

[mralbert]

Hi Anil, 1.) Previously, our reloads worked regardless of whether they were executed from the Hub or the QMC (Scheduler). Currently, our reloads still work from the Hub, but not from scheduled tasks in the QMC. So, it is indeed weird. 2.) We have a multi-node setup where each service basically has it's own server (due to large size). Our databases are all hosted on other servers. I am certain nothing has changed recently with our architecture. 3.) We are running under a Service Account (SVC_XXXXXXX). It has full permissions as an Administrator.