PaulNeubauer
Programmer
Hi all,
This is (unfortunately) NOT the usual problem ("Integrated Security" or "Windows Authentication") that generates that error message.
I have drawn the assignment of tracking down problems and inconsistencies between Access 2007 and earlier versions of Access for our institution. We have a (thankfully small) number of MS Access applications where Access is used as the front end and the tables reside on a SQL Server box. Our general policy here is to create a database on the SQL Server and a corresponding account to allow applications to get to their data. For example, we may have a database called "foo" and a corresponding account "acc_foo" for that database application. We are NOT using the users' normal domain accounts for these applications and NOT using "integrated security" aka "Windows Authentication" but "mixed-mode security" on the SQL Server (as is required). These applications have typically been in use for some time and they have been reasonably well-behaved.
Normally, when the user starts the application s/he is prompted with an login box that already shows the account, e.g., acc_foo and just has to fill in the password. This is, in fact, the behavior I have seen when I have installed the applications on a PC with Win XP and Office 2003, and even on a PC with Vista and Office 2003.
I have installed a couple of these applications on a new (Vista) PC with a fresh install of Office 2007 to test compatibility. With the applications installed on the new PC, I have had to re-link the tables, so I have gone through the procedure of setting up a new DSN and re-associating the tables through that. So I now have a new file called foo.dsn, which contains the lines (with items in <> substituted for real data):
So far, I have done some minimal testing and the database application seems to basically "work" but when I open the database, the first thing that I see is the dialog box informing me that:
Then, when I click the OK button, I get the usual login dialog box:
Following that, I can uncheck the "Use trusted connection" box, change the Login ID from "Paul" to "acc_foo" and the real password and I'm in. But I'm not at all happy about the prospect of forcing the departmental secretaries who normally use these applications to go through that sort of mess. The same applications immediately present the login box without the "use trusted connection" box checked when running under Access 2003, but initially fail the connection without giving the user an opportunity to enter the password under Access 2007. Furthermore, I have got this behavior from more than one database app now. Therefore, I suspect that this is evidence of a change in Access 2007. But I'm not sure what I can do about it.
Has anyone else seen anything like this? Does anyone have a suggestion for turning off the "Use trusted connection" box and making the connection use the UID from the dsn file? Any ideas at all?
Thanks,
Paul
This is (unfortunately) NOT the usual problem ("Integrated Security" or "Windows Authentication") that generates that error message.
I have drawn the assignment of tracking down problems and inconsistencies between Access 2007 and earlier versions of Access for our institution. We have a (thankfully small) number of MS Access applications where Access is used as the front end and the tables reside on a SQL Server box. Our general policy here is to create a database on the SQL Server and a corresponding account to allow applications to get to their data. For example, we may have a database called "foo" and a corresponding account "acc_foo" for that database application. We are NOT using the users' normal domain accounts for these applications and NOT using "integrated security" aka "Windows Authentication" but "mixed-mode security" on the SQL Server (as is required). These applications have typically been in use for some time and they have been reasonably well-behaved.
Normally, when the user starts the application s/he is prompted with an login box that already shows the account, e.g., acc_foo and just has to fill in the password. This is, in fact, the behavior I have seen when I have installed the applications on a PC with Win XP and Office 2003, and even on a PC with Vista and Office 2003.
I have installed a couple of these applications on a new (Vista) PC with a fresh install of Office 2007 to test compatibility. With the applications installed on the new PC, I have had to re-link the tables, so I have gone through the procedure of setting up a new DSN and re-associating the tables through that. So I now have a new file called foo.dsn, which contains the lines (with items in <> substituted for real data):
So far, I have done some minimal testing and the database application seems to basically "work" but when I open the database, the first thing that I see is the dialog box informing me that:
Then, when I click the OK button, I get the usual login dialog box:
Following that, I can uncheck the "Use trusted connection" box, change the Login ID from "Paul" to "acc_foo" and the real password and I'm in. But I'm not at all happy about the prospect of forcing the departmental secretaries who normally use these applications to go through that sort of mess. The same applications immediately present the login box without the "use trusted connection" box checked when running under Access 2003, but initially fail the connection without giving the user an opportunity to enter the password under Access 2007. Furthermore, I have got this behavior from more than one database app now. Therefore, I suspect that this is evidence of a change in Access 2007. But I'm not sure what I can do about it.
Has anyone else seen anything like this? Does anyone have a suggestion for turning off the "Use trusted connection" box and making the connection use the UID from the dsn file? Any ideas at all?
Thanks,
Paul
