So I decided to go for a System DSN instead. The issue here is that I had to create a System DSN, which is actually odd because the SSIS job is scheduled to run with the account for which the User DSN exists, and it does work as long as I am logged into the server with that account.Īnyway I am way too tired to try to understand why the User DSN didn't work. Then you can connect to the database from external sources (Excel, programs, etc) in many ways, using the right connection strings. Creating a single Login directly inside the database's Security is not enough. The reason you need to do what I've mentioned above, is so you have a correct and valid Login to the database, which is important. Make sure you've given the new Login, all the right permissions to READ and/or WRITE to the database. Once that's done you'll notice the same login was created at the database's Security folder. Next go to Securables, and choose the correct database, along with the Schema, etc. Set up your LoginID and Passwords, and default the login to the database you're referring to. In there, expand it and right click to create a new Login. I would normally run SSMS and go down to the bottom of my server instance where it's showing the Security folder (as explained in the above link). In essence you need to consider the 'server credentials' as well as the 'database credentials'. There is an excellent article about it here. If you attempt to use data or other objects again that rely on the external data connections, Access tries again to reconnect to the external data source.Ĭreating SQL Server logins is a bit tricky and you need practice to understand what's going on. If the retry fails, you won't be able to work with objects that use the dropped external data sources but you can continue working with other areas of your database that aren't dependent upon the unreachable data sources. If the retry is successful, you can continue working with the data and database objects without having to close and re-open Access.

If Access loses the ODBC connection to an external data source you're trying to use, you'll see an error message describing the failure.Īccess now attempts to reconnect to the data source automatically when performing operations that require a connection to an external data source.

In this scenario, you'll now see the following experience: We've improved this experience so that now if Access loses the ODBC connection to an external data source, Access tries to reconnect to the data source automatically. Access doesn't attempt to re-establish the dropped connection even if the connection is valid again and there is nothing that users can do to make Access try and reconnect to the external data source.

When Access loses the ODBC connection to an external data source, users have to close and re-open their Access databases in order to continue working with objects that use data from those external data sources. Check What's new in Access 2016 - July 2016: I think the problem you're trying to solve has been solved for Access 2016, but nothing for Access 2013 (AFAIK). using it), but this is a quick and dirty option.

Your mileage may vary, there may be a simpler way (e.g. I found another string like this, which seems to match the released strings mariadb-connector-odbc-2.0.18-ga-debian-x86_64/lib/libmaodbc.so | grep strings mariadb-connector-odbc-3.0.9-ga-debian-x86_64/lib/libmaodbc.so | grep strings mariadb-connector-odbc-3.1.1-ga-rhel7-x86_64/lib/libmaodbc.so | grep ma. However, that doesn't seem to match the release version strings mariadb-connector-odbc-2.0.18-ga-debian-x86_64/lib/libmaodbc.so | grep -A10 ^_client_version Libmaodbc.so: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID=5a3305eade1036378d57e16dcb09e02d541cc6a9, with debug_info, not strippedĪ run of strings and grep commands gave me the version quite strings mariadb-connector-odbc-3.0.9-ga-debian-x86_64/lib/libmaodbc.so | grep -A10 ^_client_version

Hdbodbc driver not found