Upsize = good on server, but client won't load tables

[gomikem]

I ran the upsizing wizard from the server and everything turned out well using the FE and BE on the server. I tried to pull the FE(.mdb) off of the server and use it from a client machine and when I open any table, I get the error attached to this post.

I have created and tested an ODBC connection and it works fine. When I get this error, I do the following:

-click OK
-uncheck "Use Trusted Connection"
-enter the username and password that I created for the sql user with access to that database.

*If there are a lot of records, it continues to prompt me with this error until the table completely populates.

How can I avoid this error? I looked at the properties for the linked table and see in the description where I would enter the uid and password, but I can't edit this line.

PLEASE HELP! Thanks!!

 

[MSAccessRookie]

I ran the upsizing wizard from the server and everything turned out well using the FE and BE on the server. I tried to pull the FE(.mdb) off of the server and use it from a client machine and when I open any table, I get the error attached to this post.

I have created and tested an ODBC connection and it works fine. When I get this error, I do the following:

-click OK
-uncheck "Use Trusted Connection"
-enter the username and password that I created for the sql user with access to that database.

*If there are a lot of records, it continues to prompt me with this error until the table completely populates.

How can I avoid this error? I looked at the properties for the linked table and see in the description where I would enter the uid and password, but I can't edit this line.

PLEASE HELP! Thanks!!

Are you using ODBC Drivers in the Linked tables and views?

We had the same problem. When We created the ODBC Drivers, we defined them as using a Trusted Connection. The Network Admin and the SQL Server Admin did not allow that status.

We wound up going to each user's workstation and recreating the ODBC Drivers with an individual UserName and Password for each user. The SQL Server Admin was not happy that he had to create UserNames and Passwords, but since it was his rules that created the situation, he created as many as we needed.

If you are not using ODBC Drivers, check to see if your situation is similar to ours.