Specs:
Sql Server 2008
Server 2008 R2 64bit
MS Access database
What works:
I have configured a Linked server connection to the Access database by installing office access data components and creating a system DSN and whatnot.
which resides in a directory on the same server.
I have succeeded in quering data through openquery.
SELECT * FROM OPENQUERY(LINKEDHELL, 'SELECT * FROM [D:\path\mordor.mdb].Orcs')
I can insert/update/delete through openquery (from inside the Sql Management Studio)
What does not work:
I have created a database which exposes a view that wraps the openquery expression. This allows my applications to remain oblivious to the fact thats its quering through an linked server connection and allows me to use an ORM. Case in point: Entity Framework.
However whilst retrieving data works, updating/inserting/delete wont.
I have spend quite some time making sure that the MSDTC is configured correctly however no dice.
What i tried
MSDTC
Enabled Network DTC Access
Allow Inbound/outbound
Configured Firewall
Enabled XA Transactions
Gave account under which DTC works access to the .mdb
Restarted Sql Server after making these settings
Other
Configured linked server security: Created mapping between sql user and local admin account, so that when i login with that sql user, it uses the local administrators account to connect to the access database.
Enable Promotion of Distributed Transactions for RPC : False
The error im getting:
OLE DB provider "MSDASQL" for linked server "LINKEDHELL" returned message "[Microsoft][ODBC Microsoft Access Driver]Invalid attribute/option identifier ".
Msg 7391, Level 16, State 2, Line 4
The operation could not be performed because OLE DB provider "MSDASQL" for linked server "LINKEDHELL" was unable to begin a distributed transaction.
I can simply recreate this by doing this from the Sql Management Studio
begin distributed transaction
//anything that queries the linked server
commit transaction
So what have I missed?
I have read that distributed transactions are supported by the ODBC driver, but im unsure if the ACCESS database does. So if someone could at the very least confirm that. That would help.
Access doesn't have transactions, because Access is not a database
engine. Jet/ACE (Access's default db engine) has supported
commit/rollback as long as I've used it (since Jet 2.x, e.g., 1996).
It has never supported transaction logging and probably never will (I
recognize that's not what you're asking about but many of those coming
to Jet/ACE from server database backgrounds are rather foggy on the
meaning of the term "transactions" and have a hard time grasping that
Jet/ACE supports one and not the other). – David-W-Fenton Jan 16 '10
at 23:12
-- Do we have transactions in MS-Access?
David W Fenton, MVP, RIP
Related
I am going around in crop circles, trying to set up a linked server (from SQL Server 2016 to MySQL).
Here is the basic procedure that I used: Create a Linked Server to MySQL from SQL Server. Upon clicking OK to create the new linked server, I received the following SSMS 2016 spasm, Error #7303:
The linked server has been created but failed a connection test. Do you want to keep the linked server?
Additional information:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "MYSQL".
OLE DB provider "MSDASQL" for linked server "MYSQL" returned message "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". (Microsoft SQL Server, Error: 7303)
I tried variations that included a Provider String and Catalog (same error):
I have tried the latest MySQL ODBC ANSI/Unicode drivers (5.03.07.00), set up via System DSNs in both the 32- and 64-bit versions of the ODBC Data Source Administrator.
Now, I suspect that something screwy is going on with MS SQL Server and/or its OLE-DB Provider (MSDASQL), because:
All tests of the System DSNs within the ODBC Data Source
Administrator are successful.
Crippled Access 2016 is able to link (via the aforementioned Unicode System
DSN) to MySQL just fine, with minimal effort, listing all databases
and tables.
What is the magic that SQL Server 2016 needs to make the linked-server dialog not result in the above error?
Two things --
Product Name should be MSDASQL.
Leave Provider String and Catalog blank (these are typically taken care of by your DSN definition).
That should do it...
I'm currently trying something I've never done before - I'm trying to access MySQL data in an SQL Server environment. Where I am, we have two servers (the MySQL and MSSQL servers), and each stores different types of data. Recently I've found a need to write queries that include data for both servers. One of the ways I read to do this is adding a "Linked Server" in SQL Server. But try as I might I cannot seem to get a Linked Server added.
I am working on a Windows 7 system, our SQL Server instance is 2005, and the MySQL version is 5.5.31.
What I've done so far is this:
Downloaded and installed the MySQL ODBC drivers
Created a System DSN using that driver for the MySQL database, called "Production". (I also tested the connection from the Data Sources application and it connects just fine).
Checked for the Provider in SQL Server (MSDASQL) to configure options such as "allow nested queries" and "allow 'LIKE' operator"
right click on Linked Servers in Server Objects in SQL Server > "New Linked Server"
From here, I fill out the linked server info like this:
Checked "Other data source" (not SQL Server)
Chose Provider "Microsoft OLE DB Provider for ODBC Drivers"
Product Name: "Production"
Data Source: (the name of the System DSN) Production
Then in the security tab, I chose the "Connections will be made using this security context" and provided my username and login for the MySQL server.
Then this is where I run into an error every time. I always get the following error message:
The linked server has been created but failed a connection test. Do you want to keep the linked server?
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.Express.ConnectionInfo)
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "FLUX".
OLE DB provider "MSDASQL" for linked server "FLUX" returned message "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". (Microsoft SQL Server, Error: 7303)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.5000&EvtSrc=MSSQLServer&EvtID=7303&LinkId=20476
If you click that link for help, by the way, nothing shows up.
I saw other people suggested trying an older MySQL ODBC driver, adding a System Data Source for the 32bit driver as well as the 64bit driver, and restarting my machine (not the DB server) -- none of these fixed my error.
What I do not understand is why my System DSN seems to work and connect fine, but SQL Server cannot see the Data Source. Does anyone see what I'm missing, or what I might be configuring incorrectly?
EDIT
Clarified that I restarted my local machine, but not the DB server since trying to add the Linked Server.
From everything you've said, you probably have a mismatch between bitnesses of SQL Server 2005 components and the installed ODBC Driver for MySQL.
System DSNs are definitely the way to go.
You probably will need to install both the 32-bit and 64-bit ODBC driver, and configure an identical (same name and everything!) System DSN with each.
I would say you may also want/need to install this patch it was useful for getting XP and 2003 to work properly for ODBC type connections for me.
http://www.microsoft.com/downloads/details.aspx?FamilyID=000364db-5e8b-44a8-b9be-ca44d18b059b&displaylang=en
Is your Database server on the same machine on which you have Sql Server Management Studio Installed? If the SQL Server is on a remote machine then you need to install the ODBC driver on remote Machine and create the DSN there as per link
I was having the same issue but the above link solved my problem.
I have a table say Table1 on SQL Server 2014 and MySQL both.
Table1
ID INT,Code VARCHAR(100)
I created a linked server MyLinkedServer in SQL Server using "Microsoft OLEDB Provider for ODBC".
**Linked Server **
EXEC master.dbo.sp_addlinkedserver #server = N'MyLinkedServer', #srvproduct=N'MyLinkedServer', #provider=N'MSDASQL', #datasrc=N'MyLinkedServer'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'MyLinkedServer',#useself=N'False',#locallogin=NULL,#rmtuser=N'username',#rmtpassword='########'
Linked Server Settings
EXEC master.dbo.sp_serveroption #server=N'MyLinkedServer', #optname=N'data access', #optvalue=N'true'
EXEC master.dbo.sp_serveroption #server=N'MyLinkedServer', #optname=N'use remote collation', #optvalue=N'true'
EXEC master.dbo.sp_serveroption #server=N'MyLinkedServer', #optname=N'remote proc transaction promotion', #optvalue=N'true'
The linked server is created successfully and I am able to query Mysql Table in SQL Server.
Query
When I run
INSERT INTO MyLinkedServer...Table1(ID,Code) SELECT 1,'Code1'
The record is inserted. However when I start a transaction and run the INSERT, I get an error:
BEGIN TRAN
INSERT INTO MyLinkedServer...Table1(ID,Code) SELECT 1,'Code1'
COMMIT
Error:
OLE DB provider "MSDASQL" for linked server "MyLinkedServer" returned message "[MySQL][ODBC 5.3(a) Driver]Optional feature not supported".
Msg 7391, Level 16, State 2, Line 8
The operation could not be performed because OLE DB provider "MSDASQL" for linked server "MyLinkedServer" was unable to begin a distributed transaction.
What I have tried so far.
Enable XA Transactions in MSDTC
Enabled following setting in Linked Server Provider
Nested queries
Level zero only
Allow inprocess
Supports ‘Like’ Operator
I checked the following links and their suggestions however the error persists:
Distributed transactions between MySQL and MSSQL
SQL-Server and MySQL interoperability?
SQL Server and MySQL Syncing
EDIT
Additional Details:
MySQL is using InnoDB storage engine on Ubuntu machine.
I have already configured the ODBC connector and used it to configure a ODBC System Data Source which is used in the Linked Server
Theoretically this should work.
I would suggest different steps to sort this out:
Have you checked you MySql storage engine yet? It looks only InnoDB storage engine support distribute transaction per MySql document: https://dev.mysql.com/doc/refman/5.7/en/xa.html
See if you can switch to use MySQL Connectors setup connection to connect to MySql in SQL Server instead of OLEDB provider, which state by MySql document above that support distribute transaction.
If still not working, it might be the MSDTC service itself has some problem, see if you can isolate that like get a SQL Server instance running on the MySql server box(if you are using Windows MySql), or try install Windows MySql on the Sql Server box to get distribute transaction working between two MySql. Which would be able to point you to the actual problem.
EDIT:
Unfortunately it looks that you proved this not working, I've a closer look at the MySql document and sorry it looks that I wasn't reading it thoroughly, it says:
Currently, among the MySQL Connectors, MySQL Connector/J 5.0.0 and higher supports XA directly
And by some other Googling I found this: https://bugs.mysql.com/bug.php?id=37283, people report this bug many years ago and they marked this as a won't fix.
Some one suggested something here: https://social.msdn.microsoft.com/Forums/en-US/fc07937d-8b42-43da-8c75-3a4966ab95f9/xa-msdtc?forum=windowstransactionsprogramming, which is to implement your own XA-Compliant Resource Managers to be used by your application (https://msdn.microsoft.com/en-us/library/ms684317.aspx)
As on SQL 2014, you could have configured the linked server not to enlist in a distributed transaction. Although you could try adding "Enlist=false" in the #provstr argument to sp_addlinkedserver
I am unable to kill some SQL Server agent jobs. The task state continues to be running and the command stays in KILLED/ROLLBACK. The job executes queries against OSI's PI system via OLEDB linked server and Oracle. The only way I have found so far to kill these jobs is by restarting SQL server (not a preferred method).
I found following article
https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers
Apparently several people have this issue using openquery through a linked server that is not SQL Server. I'm reposting the work-around that BReuter posted on above article:
posted by BReuter on 1/30/2007 at 2:21 PM
*I have experianced the exact behavior and have found a combination of software which stablized our environment.
There were three key ingredients I found:
1) Make sure you do not have ANY linked servers using Microsoft OLEDB Provider for Oracle, instead use Oracle Provider for Oracle(version 9.2.0.4 is what I have in production).
2) Do not allow the linked server to run "in process". This took some research, but it is possible to run the linked server out of the SQL memory space by following the directions below.
3) I'm running SQL 2005 SP1 on W2K3, but I believe the OLEDB Provider is the key and not the OS or DB version.
The default security settings are too tight to run the Oracle OLEDB provider (OraOLEDB) out-of-process. Further, the default settings for MS DTC do not allow network communication.
Control Panel-> Administrative Tools-> Component Services
Drill to Component Services-> Computers
a. Right-click My Computer-> Properties
MSDTC tab -> Security Configuration button (screenshot below)
a. Network DTC Access – checked.
b. Allow Inbound / Outbound – checked.
c. No Authentication Required – This simulates the windows 2000 security settings.
d. Enable XA transactions – the type of transaction implemented by OraOLEDB provider.
Drill to Component Services-> Computers-> My Computer-> DCOM Config
a. Right-click MSDAINITALIZE-> Properties
Security tab (screenshot below)
a. Access Permissions -> Customize.
b. Press “Access Permissions” Edit button.
c. Give the SQL Server Service account “Local Access” permission.
d. Repeat for “Launch and Activation”.*
If they are large transactions, it might be that the server is actually still performing the rollback which might take some time.
This page
http://www.jaygeiger.com/index.php/2015/03/03/how-to-kill-a-frozen-linked-sql-server-connection/
provides a workaround.
It consist in manual TCP connection termination. It's not an ideal solution but it's the best one I know. It's better than having to restart the entire SQL Server.
Btw. I found that link at https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers page mentioned in Ahd's post
for me killing the OLEDB external resources did not worked and i unfortunately had to restart the SQL server instance to fix this issue always
i my cases it have select with OPENQUERY from oracle linked servers or SharePoint lists which simply has a simple error like bad password and it cannot resolve the error and goes and never come back until you restart the service
Transactions that get stuck in KILLED/ROLLBACK can be canceled by killing transactions on local server. If the query is cross-server and you don't want to wait for the rollback, you have to go to the remote server and kill the transaction as well as kill it on the local server.
This applies to any database system.
Does SQL Server has an external log file or internal table for attempted connections, or is that kind of info put somewhere in the Windows Event Log?
You can enable connection logging. For SQL Server 2008, you can enable Login Auditing. In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select "Both failed and successful logins".
Make sure to restart the SQL Server service.
Once you've done that, connection attempts should be logged into SQL's error log. The physical logs location can be determined here.
Another way to check on connection attempts is to look at the server's event log. On my Windows 2008 R2 Enterprise machine I opened the server manager (right-click on Computer and select Manage. Then choose Diagnostics -> Event Viewer -> Windows Logs -> Applcation.
You can filter the log to isolate the MSSQLSERVER events.
I found a number that looked like this
Login failed for user 'bogus'. The user is not associated with a trusted SQL Server connection. [CLIENT: 10.12.3.126]
If you'd like to track only failed logins, you can use the SQL Server Audit feature (available in SQL Server 2008 and above). You will need to add the SQL server instance you want to audit, and check the failed login operation to audit.
Note: tracking failed logins via SQL Server Audit has its disadvantages. For example - it doesn't provide the names of client applications used.
If you want to audit a client application name along with each failed login, you can use an Extended Events session.
To get you started, I recommend reading this article: http://www.sqlshack.com/using-extended-events-review-sql-server-failed-logins/