Cannot Connect Access DB to ODBC DSN Using MySQL Connector/ODBC - ms-access

Question

I am trying to connect MS Access to a MySQL database backend - using the windows "Set up data sources (ODBC)" command allows me to connect to my database fine, but will not save the DSN file for some reason.
I've tried to get around it by manually creating a DSN file which looks like (with the actual data instead of the ***):
[ODBC]
DRIVER=MySQL ODBC 5.1 Driver
USER=****
PASSWORD=****
SERVER=**.***.**.**
DATABASE=cl39-beech
However Access throws up the message
ODBC--call failed.
[microsoft][odbc driver manager] data source name not found and no default driver specified.
Any thoughts on how to get around the problem(s)? I'm not too worried about the first one if I can manually create the DSN file, but need to work out where the second is going wrong!

Answer 1

Simply create the working link from Access like you did in your first step. When the ODBC manager from Access launches then simply create a file data source.
Check that the linked table works by opening the linked table in Access to ensure the connection works and you see data.
Now, simply grab/pull out the connection string saved for that table like this in the debug window (hit ctrl+g to launch VBA IDE and jump to command line).
? currentdb.TableDefs("dbo_customers2").Connect
The debug window will then out put the correct connection string. (so in above, replace what I have with the name of the WORKING linked table).
It is the above connection string result that you can use to re-link a table.
A suggested code example for the above string to re-link tables can be found here.
So don’t bother with trying to use a DSN, as there is often a zillion issues such as where you have to place the file to work etc. The above approach means no DSN is required.
edit:
Edit:
In most cases, you likely don’t need any code. Remember, once you linked the Access tables, then the DSN is in general NOT required. Access linked tables “remember” their settings.
So you really only need such code if you not going to “manually” use the ODBC manager from access to link the tables.
Thus, the code ONLY need to run “one time”. So you on your development machine simply place the code in a standard code module and while in the VBA editor hit F5. As noted, if you ALREADY linked the tables, then you don’t need the DSN anymore anyway (it is only used “during” the re-link process and the settings in that DSN are transferred to each linked tables.
So you don’t need to run the code in some form – it is a “one time” thing you do much like designing a form. You don’t re-design forms on application startup, nor do you need to run some re-link code ONCE the tables have been linked.
In most cases such re-link code is ONLY required if you going to CHANGE the back end database (say from developer back end to the actual production back end database). And thus I suppose you could make a form with a button on it to re-link, but as a general rule you don’t need that code to run each time the application runs.
Once tables are linked then your forms and reports etc. should work as if such tables were regular “local” access tables. So this re-link code is really a “substitute” for you doing the manual linking to the SQL server tables. However ONCE you done a “manual” link, then the original DSN is not required. The re-link code thus in “most” cases is to allow you to re-link the front end database to a back end database of your choice, or in those cases in which you are supporting a client “far away”.
If you are developing “off site” then your linked tables are to your local copy of MySQL. When you send a updated “next great” version of your application to the customer site, then your table links are wrong, and on startup you need to run that re-link code to correctly link the tables to their back end. A “great” way to do this is to ALWAYS have a text file in the same directory as the application. Your application on startup can read that text file, and if the connection string is DIFFERENT then the existing connection, then you call + run your re-link code with this new connection string. Thus you don’t have to be on the customer’s site to roll out updated software. Next time the application runs, the connection strings will match and thus a re-link will NOT be required on startup. So re-linking is a “one time” type of deal here.
There are a BILLION different use cases here. What works for me may well not work for you. It not clear if you are working “on site” (so re-linking of tables is likely NOT required), or you developing off site with your own copy of MySql running (and thus you linked tables point to the wrong server). Or you are developing on site, but DURING development, your front end tables are linked to a “test” copy of the database as to not accidently “mess” with the production data.
So the code belong in a standard (non class) code module. As to when you need to run such code will depending on the billion different possibility’s (so it kind of like asking me to tell you where your shoes are in the morning – I have no idea and never could have an idea). But I can tell you that you should put shoes on when you go outside!
So if your linked tables are now working, then your application should be compiled to a accDE, and then that accDE should be distributed to each computer that requires this application. If they are on the same network etc., then no code or re-linking of the tables is required. On the other hand, if you are developing off site, or the application has to be distributed to several different companies then likely EACH company will have a different server location as to where MySQL is running and thus you need to re-link in each of those cases.
So it is possible that you may well not need ANY re-linking code. If you are “on-site”, then once you linked those tables, then your application should run on ANY computer without needing any re-linking code or having to run this re-link code.
So once tables are “linked”, access remembers that setting and it is permanent.