This wiki post outlines both a problem and a solution. I wanted to post this for others that may be having similar problems, as I couldn't find anything specifically to solve this problem elsewhere.
We recently upgraded our SQL Server 2000 database to SQL Server 2005. One of the databases on the server is a back-end to a MS Access database. The MS Access database uses pass-through queries, via DSN-less ODBC to connect to SQL Server.
An example of the DSN-less connection string is shown below:
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
After the upgrade, we found that users were unable to run the pass-through queries, and were getting the following error displayed :
ODBC -- connection to 'SQL Server
' failed
This initially appeared to be a permission issue, as elevating the priveledges of the SQL server logins to sysadmin server role alleviated the problem (but obviously this isn't a great solution).
After taking the logins back out of the sysadmin role we found that when connecting to SQL Server via Management Studio, the login could execute the stored procedures. The very same login could not from within MS Access. This pointed to something MS Access was doing while trying to execute the stored procedures - rather than a permission issue.
We ran a trace on the server using Profiler, and this showed up MS Access trying to execute the following command prior to stored proc execution:
DBCC TRACEON(208)
It appeared to fail at this command, prior to stored procedure execution. Research on the web showed that DBCC TRACEON(208) is equivalent to using 'SET QUOTED IDENTIFIERS ON' command, and that in SQL 2005 priveledges to run this DBCC command had been revoked.
After further research, we found references to MS Query having a similar problem, and that the APP component of the connection string should be changed from 'MS Query' to something else.
On a hunch, we changed our APP component of the ODBC connection string, and MS Access no longer tried executing DBCC TRACEON(208) prior to stored procedure execution.
After further testing, we tracked the problem down to the 'copyright' symbol included in the APP component :
APP=Microsoft® Access (Pass Through Query)
By removing the copyright symbol, all was well with the connection and the application worked as it had previously done on SQL 2000.
Hope this helps out anyone else having a similar problem.
Isn't that the registered trademark symbol?
I believe you hit on one of sql server 2005's defences against odbc based attacks. Since there isn't anything on the internet about it, it is likely something MS handled internally.
Related
I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok
We recently moved a database from MS SQL Server 2000 to MS SQL Server 2008. Everything works as expected with our main .NET client application but we are having problems with a MS Access 2003 application which connects via ODBC. A System DSN is used to make the connection.
When the database was running on SQL Server 2000 the Access application would request a user name and password once when the program was first started. Now, with the database running on SQL Server 2008 a user name and password dialog is requested every time a different table is accessed I believe.
This behavior occurs when using either the user account we have used for years and it also occurs if I use the database system admin account ( I know this is bad practice, it was just a test. )
What do I need to reconfigure to return to the previous, desirable behavior where the user is only authenticated a single time?
You could look at using a "DSN-Less" connection to MS SQL, microsoft provide instructions here: http://support.microsoft.com/kb/892490
The relevant connection string can be found here: http://www.connectionstrings.com/sql-server-2008#p3
All this aside, JMK's question is important, the method above is for if you are having linked tables to the server present in your Access database, however when working with dedicated database server's I always advise using "ADO" connections rather than "DAO" as this will avail better performance (especially if you are running queries)
If it is just queries you need to run then consider either the ADO method or take a look at the "Pass through" queries option, this like ADO will have the server doing the work rather than the local machine and the performance will be greatly improved.
Before dropping a database on an Azure Sql Server I have to check if another user is connected to that db.
Using the stored procedure sp_who2 fails with:
"Could not find stored procedure 'sp_who2'."
Trying to get informations from sys.sysprocesses also fails with message:
"Reference to database and/or server name in 'master.dbo.sysprocesses' is not supported in this version of SQL Server."
How do I get the info I need?
Quick googling found that this approach works quite well in SQL Azure. However it works only in the contexts of a concrete database! Remember that in SQL Azure you can only work with single DB at a time. If you need data from more than one DB you have execute the statement for each DB separately.
Side note, I could not get sp_who working in SQL Azure.
EDIT
The following is screenshot provided for evidence:
I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?
I have been trying to debug SQL Server 2005 stored procedures, in Visual Studio Team System 2008.
I connected to the database server and did a right-click "Execute", on the stored procedure. I even tried "Step Into Stored Procedure", with no luck.
(source: googlepages.com)
The IDE shows it is running, but I can not seem to break or step into the stored procedure.
(source: googlepages.com)
I have checked the event viewer and there are no logs. There are no output or messages showing where the problem is.
Visual studio contains the following components :-
(source: googlepages.com)
Loads of forums mention debugging issues, but no simple solution were found.
Am I missing something ? Or does anyone know of a more concise site, that walks through successfull stored procedure debugging ?
Check this, specially the remote debugging part: http://www.dbazine.com/sql/sql-articles/cook1
For other general information on debugging sql check http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx
Remember that you also have to have admin privileges on the sql server box that you're debugging on. In the past, I've had to use the RunAs option in the explorer context menu to start Visual Studio. I use the same credentials as the admin user on the sql server box.
Have you enabled SQL Server debugging in the project?
Project | Properties | Debug tab.
EDIT: Can also enable "Allow SQL/CLR Debugging" on a data connection in the server explorer.
One issue to investigate is that any SQL Server user account involved in SQL debugging must have "execute" rights on an extended stored procedure called sp_sdidebug, a right that only the system administrator account (sa) has by default.
To check this, use the account to log into SQL Server and then type the following SQL
command using SQL Server Management Studio:
EXEC master..sp_sdidebug
You’ll see either a result stating that the command completed successfully or an execute permission error. If you see the latter result, you should also check
that the account has permission to the master database itself. It’s not unknown
for a DBA to give permission to the stored procedure, but not to the master database.
The quickest way to grant execution rights for a SQL Server account to sp_sdidebug is to enter the following SQL:
GRANT EXECUTE ON master..sp_sdidebug TO SpecificAccountName
There's another issue, but it won't affect you as you're using Server Explorer. If you're debugging from a client application, you also have to execute the following command:
EXEC master..sp_sdidebug 'legacy_on'
Note that remote SQL Server debugging is done using the DCOM, and this can be tricky to configure properly. First, you need to install the full remote debugging components on the remote database server. You may also need to repeat this process every time the SQL Server is upgraded with a service pack or a patch.
Have you tried debugging locally on the server via Citrix or RDP?
Hope this helps,
Bill
its the windows firewall. disable it and try it shall work