January 19, 2017 at 9:57 am
Here is the Error:
There was an error trying to establish an open database connectivity (odbc) connection with the database server. sqlstate = IM003 message = specified driver could not be loaded due to system error 5: Access is denied. tdata32.ddl.
This pops up overnight after several jobs use it daily every day.
It eludes to the file and or paths are not allowing the user of the program to access the file, so error, not loading the ODBC and this fail.
I've checked the security on the paths and file in question from the error and system, users, admin, etc all have proper level access to the file, so the error strikes me as erroneous.
Retired running he job in case the source system had issue, still same issue.
Checked the 32/64 bit setting on that jobs connection, and its 32 bit as it should be for this small data move via ODBC.
Nothing has changed around this job, or settings for any job or on the server, so this is quite odd.
Does anyone have this experience what was tried and successful?
Thanks
JPQ
<
January 19, 2017 at 12:46 pm
quinn.jay - Thursday, January 19, 2017 9:57 AMHere is the Error:There was an error trying to establish an open database connectivity (odbc) connection with the database server. sqlstate = IM003 message = specified driver could not be loaded due to system error 5: Access is denied. tdata32.ddl.
This pops up overnight after several jobs use it daily every day.
It eludes to the file and or paths are not allowing the user of the program to access the file, so error, not loading the ODBC and this fail.
I've checked the security on the paths and file in question from the error and system, users, admin, etc all have proper level access to the file, so the error strikes me as erroneous.
Retired running he job in case the source system had issue, still same issue.
Checked the 32/64 bit setting on that jobs connection, and its 32 bit as it should be for this small data move via ODBC.
Nothing has changed around this job, or settings for any job or on the server, so this is quite odd.Does anyone have this experience what was tried and successful?
Thanks
JPQ
<
Short story to this, a reboot fixed it. I tried the usual line up of 'check and see's', but the main issue was being told incorrectly that the user account which is part of the admin group did not have access to the odbc file, yet it did when you looked at the folder path and file settings. So a reboot fixed it, and we think that overnight systems upgrades and pushes, fixes and other sneaky backend pushes they do blindly over the network, dorfed up these settings, and a restart at the OS level was required. Now up, now processing.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply