I've used the Access 2007 upsizing wizard to move my files to a SQL server. A problem I'm experiencing now is that when I try to link the tables in either Excel or Access, it requires me to create a DSN or a machine data source connection. In either case, when I do this, it makes the connection only useful on the current PC.
What I'm trying to do is create an access file and an excel file, both of which link to the newly upsized tables on the sql server, which I can distribute to users across the network (let's assume they all have sufficient user rights on the SQL server to read data).
Any suggestions?
Chuck
Use Doug Steele's code to convert your DSN's to DSN-less connect strings:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
Related
I am a beginner in Microsoft Access and one of my friend gave me a copy of his SQL Server file and something with .BAK extension which I believe is the database as it is almost 300MB.
When I try to run the SQL Server file I get cannot connect to backend database error. Searching on the internet I found that I can prevent this by holding shift while opening the database.
Even though this does open the Access file, where I can see all the table,queries, forms, reports and macros icons and names. I cannot open any of them. When I press on one of the table names for example I get
Connection Failed SQL server does not exist or access denied' error.
How do I view the tables?
Your MS Access file is linked to a SQL Server. You basically need to
Install SQL Server Express (it's free)
https://www.microsoft.com/en-au/sql-server/sql-server-editions-express
Restore the .BAK file into SQL Server Express How to import a bak file into SQL Server Express
Relink all of the MS Access linked tables to your installed SQL Server
How does one change the connection string of linked tables in MS Access
This may seem complicated but it is a great opportunity to learn about databases.
Seems your friend is not very helpful.
I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.
Ok, I am using an Access 2010 database linked to a SQL 2012 backend. All is well. I migrated using the Migration Wizard - this creates the link without using any pre-created ODBC\DSN file etc. This works great as I do not have to deploy any DSN file to users (it is used by 21 users) I have noticed that linked tables have the below in the Properties\Description:
ODBC;DRIVER=SQL Server;SERVER=XXX;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=XXX;Network=DBMSSOCN;TABLE=dbo.tblCountries
Now my problem is if I create a new table in the SQL backend, how do I link without using ODBC\DSN? How do I link so it behaves the same as when migrated?
I have tried creating a table then using the description from above and changing the table name to no avail. If I do link via ODBC to the SQL backend, link to the new table then change the ODBC to match that above, Access does not let you change the connection string?
So in summary, are you able to link to new tables in SQL server, after you have used the migration wizard to link?
THanks,
Michael
The DSN connection string is actually stored with the linked table. That's why your users can connect to the linked table without needing to set up a DSN connection.
I do very similar work on a daily basis with Microsoft Access connecting to a SQL database server. I have set up ODBC connections on my development machine, which allows me to easily list the tables available on the SQL server databases, and link to them in my Access applications. When linking to the table, I always save the connection string with the table link, so the end users never need the ODBC connection.
In a sense, you can think of your ODBC connection as a template for connecting to the database. As long as you always save the connection string with the linked table, your users won't need the DSN connection to access the database.
There are times when it is appropriate to use a DSN connection, but in my experience, I find it far more practical to just save the full connection string with the linked table and manage the links using the Linked Table Manager.
Hope that helps!
Adam
I have an SQL database with an MS Access front-end. The linked table I created is only available to me and no one else. I need the other users on the domain to be able to open this linked table. When they open the table, they get an error message that says the connection to the database failed.
What am I doing wrong to where other users (besides myself) can't open the linked MS Access linked table?
If you are connecting to the SQL database using an ODBC connection, the end users need to have that ODBC connection set up on the machine they are connecting from as well.
I have table in Microsoft SQL server; and I'm using SPSS 14.1.
Now I want to connect SQL table to SPSS, so I can use SQL table from SPSS directly.
In SPSS, SQL database -> Data source -> Add New database connection -> Then I have 3 data source options only: dBASE Files, Excel Files, and MS Access Database. Which one can connect to SQL server?
You should open the Microsoft ODBC Administrator from Start or the Control Panel. There you should activate the System SDN tab, click Add... and add a SQL Server data source.
A wizard will open, where you can enter the details. First the name of the connection, which will be used as a reference by SPSS. Then optionally a description, and the ip address or name of the server.
On the next page select the authentication method, and if needed, enter the user and password. From this point, the default settings will most likely be good. If you will have character coding problems or something like that, you may need to change these settings.
I also use ODBC connection to connect to the database from SPSS, and it works well.
I hope this will help.
You may need an ODBC driver from MS or use one from the Data Access Pack for SPSS, but you will need a driver specifically for SQL Server.