Linking Microsoft Access to Azure
Hi Andrew,
I was able to create and use link tables using Access 2007, it is somewhat painful but once you get the trick it is pretty straight forward.
I tried to directly connect to SQL Azure from Access to create the Link tables and I encounter the same problem as you “master..sysdatabases” so in order to workaround it this is what I did:
I copied my schema (no data) to my local Sql Express database (same database name as the one in SQL Azure).
I created a User DSN “ODBC Data Source” pointing to my local Express database. (make sure to un-check “Perform translation for character data”)
I went to the same Access 2007 wizard to link tables, and I used the newly created DSN.
This time it works since I am connected to the local SQL Express.
I told Access to create link table for all my tables.
I saved and closed the Access Database.
I went back to the User DSN “ODBC Data Source” and this time I update the server name and credentials to point to my SQL Azure database.
I check that the user name and password is correct and “Test the connection”.
I went back to Access 2007 and I opened my database file and the previously linked tables are there and now they are getting the data from SQL Azure J
I created some queries and reports to check that I can reference them on Access and so far I have no problems.
Please let me know how it goes and thank you for using SQL Azure,
Alejandro Hernandez.
Thank you Alejandro for all your help offline in following this up.
For anyone following this thread, the problem is that Access attempts to use a 3-part column name syntax (which is not supported on SQL Azure) when looking for a primary key on the tables during the process of linking the tables. So unless you remove all the primary keys from the tables the work around will not work.
So until this possibly changes at some future date, you are probably best to stick with using pass-through queries when connecting Access to SQL Azure, and not to try using linked tables.
Hi Andrew,
I was able to create and use link tables using Access 2007, it is somewhat painful but once you get the trick it is pretty straight forward.
I tried to directly connect to SQL Azure from Access to create the Link tables and I encounter the same problem as you “master..sysdatabases” so in order to workaround it this is what I did:
I copied my schema (no data) to my local Sql Express database (same database name as the one in SQL Azure).
I created a User DSN “ODBC Data Source” pointing to my local Express database. (make sure to un-check “Perform translation for character data”)
I went to the same Access 2007 wizard to link tables, and I used the newly created DSN.
This time it works since I am connected to the local SQL Express.
I told Access to create link table for all my tables.
I saved and closed the Access Database.
I went back to the User DSN “ODBC Data Source” and this time I update the server name and credentials to point to my SQL Azure database.
I check that the user name and password is correct and “Test the connection”.
I went back to Access 2007 and I opened my database file and the previously linked tables are there and now they are getting the data from SQL Azure J
I created some queries and reports to check that I can reference them on Access and so far I have no problems.
Please let me know how it goes and thank you for using SQL Azure,
Alejandro Hernandez.
We support 2 part column names but I believe not 3 for example: in database TestDb table Foo, columns x & y
create table dbo.foo (x int, y int)
go
select x , y from dbo.Foo -- this is good.
go
select t.x, t.y from dbo.Foo t -- this is good.
go
select Foo.x, Foo.y from dbo.Foo -- this is good.
go
select dbo.Foo.x, dbo.Foo.y from dbo.Foo -- this is NOT good.
I am not getting that error. Can you let me know to what step are you referring in this section?
but when I try to open the linked table in the very last step I get the message
Thank you,
Alejandro Hernandez.
Hi Andrew,
I tried to find out what could be the cause and I noticed something, by any chance the local server that you have is SQL Server 2005 or lower? I am asking because when Access 2007 is connecting to SQL Server 2005 it is requesting for this query.
SELECT "dbo"."Test"."AnId","dbo"."Test"."ADescription" FROM "dbo"."Test"
If you notice it is the old t-sql syntax, so I am guessing that it is doing it because the local machine was SQL Server 2005, can you confirm? if that is the case would you mind trying the same exercise but with SQL Server 2008?
Thank you in advance,
Alejandro Hernandez.
Thank you Alejandro for all your help offline in following this up.
For anyone following this thread, the problem is that Access attempts to use a 3-part column name syntax (which is not supported on SQL Azure) when looking for a primary key on the tables during the process of linking the tables. So unless you remove all the primary keys from the tables the work around will not work.
So until this possibly changes at some future date, you are probably best to stick with using pass-through queries when connecting Access to SQL Azure, and not to try using linked tables.
From the Netherlands: I see indeed a great potential for my business as an Access-developer. I'm also eagerly watching any progress on this linked tables issue ! Maybe a solution in this matter would be e small step for you guys, but to us as developers a giant leap forwards in our business ! So please respond to our request .
Hi Andrew and all others that have been following this thread.
I had a chat with the SQL Azure dev team and we were able to enable the 3 part name column reference to unblock this scenario, I have just verified that I can have linked tables (with identity columns) using Access 2007 and SQL Azure. I can add, update and delete rows using the Access UI and I can build reports from the linked tables.
We still need to use the workaround of using an in-premises SQL Server in order to do the "initial linking" and then later on update the User DSN to point to SQL Azure. (details on the beginning of the thread ).
I appreciate all of you for be interested on SQL Azure, as usual, suggestions and comments are welcome.
Thank you again,
Alejandro Hernandez
I'm not sure what is meant by DSN-less connections. Is that with respect to MS Access using a DSN-less connection? Or other programs? Or from code/scripts? I'm not too familiar with MS Access connectivity to SQL Server, but you can use DSN-less connections to SQL Azure in code/scripts whether it be via OLE DB or DSN-less ODBC.I am curious if anyone has been able to create a DSN-less connection to Sql Azure... I have multiple databases that use to such a DSN-less connection to traditional sql server architecture but in experimenting today I have been unsuccessful using the DSN-less connection with Azure. It would seem that it should be possible as it is just mimicking the same connection information contained within the DSN...
Hi Alejandro,
As SQL Azure has only recently been made available in Australia, I've just tried your procedure for linking an Access 2007 database to a database on SQL Azure, but it's just not working properly. Interestingly, when I create the DSN, the message I get is as follows:
Attempting connection
Connection established
Verifying option settings
䑇䙅[Microsoft][SQL Server Native Client 10.0][SQL Server]Reference to database and/or server name in 'master.dbo.syscharsets' is not supported in this version of SQL Server.
If I don't save the password with the links, it'll connect, but of course I then have to enter the password every time I want to read a different table. If I try to save the password when I link the tables, I get an "ODBC - connection to 'SQLAzure' failed" error. I tried relinking (through the UI and in code), but that fails every time.
What now?
Graham, I can't speak for anyone else and don't pretend to however if you follow the steps listed above EXACTLY, it DOES work. I have a local copy of the sql server 2008 database that mirrors the one up on Azure. The mixed mode password/logon is EXACTLY the same as up on Azure. You then link the tables in Access, shut down Access, change the server name inside the DSN and it works. For me, it's taken a few times and it's a bit buggy getting the links to update when you change the server but once it's done, Azure works really, really well. I'm currently running test and am close to releasing a commercial app based on Azure with an Access front end. I use the setup program to create the DSN reg keys on the target computer. I've yet to get a DSN-less connection to work but the DSN itself will suffice for now...
If you set it up right, you do NOT have to enter the password to read each table. Your table links are not right. When this happens to me, I have dropped the tables, and relinked. Again, it make take a few time but once done correctly, you only have enter the password once upon logging into Azure.
Inside Access you need to have the table links display "ODBC;DSN=(Dsn Name);App=2007 Microsoft Office System;DATABASE =(your database);Auto Translate = No;QuoteId=No;;TableID=(Your Table Name)
If you don't see the AutoTranslate or QuoteID you've got the wrong settings. It won't work.
Not claiming to be an expert, just relaying what i have found...
Marty
Thanks Marty.
As I said in my first post, I CAN get it to connect if I DON'T save the password while linking, but doing so forces me to enter the password the frst time I open up an Azure table in each session. Notwithstanding, I still get the same (following) message when testing the DSN.
Hi Graham, It is interesting that you have to enter the password every time you open a table, if the password is saved on the DSN file, that should be enough.
I believe the reason why you are getting the "master.dbo.syscharsets" error is because there is a setting that is check (by default) and you need to un-check it. Such setting is “Perform translation for character data” and can be un-check while creating the DSN connection.
Thank you for your questions and I hope this can be of help.
Alejandro Hernandez.
Hi Alejandro,
Thanks for your response, however, that's not it. 'Perform translation for character data' is unchecked. I read your procedure and followed it precisely.
OK, I found the answer.
I spoke with Dave Robinson (Senior PM for SQL Azure) and Russell Sinclair (Senior PM on the Access team), who both said Access 2010 is the only version of Access that is supported against SQL Azure. They also indicated that the R2 version of the ODBC driver should be used. They said ODBC v10 and previous versions of Access might work, but they're not suported.
I haven't tried it yet, but I'm pretty confident. I will post back here after I do try it.
Here is the final answer.
If I use Access 2010 RC and the R2 version of the ODBC driver (V10.5x), I can link from Access to SQL Azure directly using a DSN that already points to SQL Azure. Opening a table in Access does not require a password. What this means is that Alejandro's procedure is not necessary in this case.
If, however, I use Alejandro's procedure using exactly the same configuration as above, I need to enter a password once per session to see the data.
Therefore, if you want to reliably make this work, use Access 2010 (RC or later), ODBC v10.5x, and link the tables using a DSN that points to SQL Azure.
There are a few more things to keep in mind, but I'll be publishing a white paper on the subject soon.
So much for the Final Solution. Standby everyone (at least anyone who's watching this thread). I've just discovered an anomaly. I'm in discussion with Russell and Dave to try and figure it out.
Well it was just an anomaly. It works just fine now.
>There are a few more things to keep in mind, but I'll be publishing a white paper on the subject soon
Graham. Just wondering if you 've created that white paper yet and where it might be found? If not, whien is it expected?
I recently wrote these papers that you may find helpful:
We've been working with Microsoft Azure, SQL Azure and linking it with Access and Excel. Exciting stuff.
Migrating and linking Access 2010 tables to SQL Azure worked well for me.
See my Migrating a Moderate-Size Access 2010 Database to SQL Azure with the SQL Server Migration Assistant post of 9/7/2010.
I think allot of people are following this thread that use ACCESS and want the same solution.
Steve
|

