I am incredibly frustrated!
I have been trying for months to migrate a MS Access database to SQL Server and nothing has worked. I need to be able to edit data on an Access front-end and the SQL Server back-end.
I've been able to copy a table, but edits on one end are not applied on the other. I'm severely limited in what applications I can download -- it takes at least a week for our IT department to install a new app. I've tried using SSMS 18 (just had it installed today) to create a linked service.
I use "Microsoft Office 12.0 Access ..." (16.0 is not available) as the Provider and leave Product Name and Provider String blank -- I get this error for either a .mdb or a .accdb file.
TITLE: Microsoft SQL Server Management Studio
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 create an instance of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "2022_08_24".
(Microsoft SQL Server, Error: 7302) For help, click:
https://learn.microsoft.com/sql/relational-databases/errors-events/mssqlserver-7302-database-engine-error
The generated script is
USE [master]
GO
EXEC master.dbo.sp_addlinkedserver #server = N'2022_08_24', #srvproduct=N'', #provider=N'Microsoft.ACE.OLEDB.12.0', #datasrc=N'C:\Users\liptonj1\OneDrive - Southern California Edison\Documents\Word Test_be.accdb'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'collation compatible', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'data access', #optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'dist', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'pub', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'rpc', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'rpc out', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'sub', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'connect timeout', #optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'collation name', #optvalue=null
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'lazy schema validation', #optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'query timeout', #optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'use remote collation', #optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption #server=N'2022_08_24', #optname=N'remote proc transaction promotion', #optvalue=N'true'
GO
USE [master]
GO
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname = N'2022_08_24', #locallogin = NULL , #useself = N'False'
GO
The right process is the one implemented by SSMA for Access: https://www.microsoft.com/en-us/download/details.aspx?id=54255
After creating matching tables and migrating the data the last step is to replace the Access tables with ODBC linked tables to the SQL Server so your Access-based forms and reports work directly with the SQL Server data.
Having a linked server from SQL Server to Access is not needed.
Ok, there is ALSO a 3rd option.
Access 2010 was the LAST version of Access to have a built in SQL server migration tool.
So here we are in 2022 12 years later!!!
but, Access 2010, and in fact Access 2007? It has a BUILT IN migration tool!!!
This is on the 2007 menu:
So, AFTER 2010, you ARE strong suggested to use the SSMAA - a seperate download and install.
However, Access 2003, 2007, and 2010? They have a BUILT-IN migration tool to sql server.
I don't have a 15 year old version of Access kicking around anymore, but you may very well want to try and use that tool. Just make sure you DO NOT use or pick the "ADP" option.
This is more a comment than an answer but is too long for a comment.
Try the following steps:
Using SSMS create a database
With that database (right mouse click) use task/import data and connect to your Access database using the Access connection type
Select the table(s) to copy (and copy them)
In your Access front end, connect to the SQL Server database using an ODBC connection and link the source tables
You can then read/write to them directly
While often not the case, we assume that you have a split access database.
That means that you have so called front end (accdb, or mdb). (FE)
And then you have linked tables to a back end (accDB, or mdb). (BE)
And office 12? Ok, that is version 2007 - 15 years old, but should work just fine.
(what other software are you using that is 15 years old? Or are you for some strange reason singling out Access for such a old version???).
Regardless?
So, the basic idea here?
You migrate the tables from the BE to sql server.
You then delete your FE links that point to the Access back end, and now are to create links in your FE that point/link to SQL server (where you presumably) migrated the Access data tables.
Hence:
I've been able to copy a table, but edits on one end are not applied on the other.
Sounds like your FE is still pointing to the older database. I mean EVEN without SQL server, it was often VERY easy to have your FE point to the WRONG database BE. You start editing, and you don't see changes in the database!!!!
So, once you move data to SQL server, then in your FE, you are to delete links
(you are NOT deleting tables here, but ONLY the linked tables in the FE, right, since we DO NOT have tables in the FE, do we?).
why do I export/import the tables, just to delete them?
You are NOT deleting tables!!!! - you are to delete your "linked" tables, or the so called links in your Access FE. You are now not using the BE anymore, and editing of data in your access FE will be directly working against and editing the table(s) that reside on SQL server. There is no concpet of suffeling data between tables - you are using linked tables. The data does NOT exist in the FE, and it never did with linked tables. So, you are being told to delete the linked tables - not the physical tables that were in your BE.
I mean assuming your Access applcation was split, then you don't have the tables in your FE to delete anymore do you? So, no, we not deleting ANY tables here, you are to delete the LINKED tables in your FE that previous pointed to your accDB BE.
You will THEN create NEW table links that now point to the tables you migrated to SQL server.
So, if you not using SSMAA?
Then you use the sql studio tools to create a database in SQL server.
Once you created a database, you are THEN to move the Access table(s) into that database. So, it comes down to what tools you plan to use for this task.
As a result, there is no "shuffle" of data between tables. You have a linked table in your FE. You are directly editing data in that linked table. But, now the linked table is not a access one, but one that resides on SQL server.
Ok, so above quite much outlines the moving parts and how this works.
So, lets take ONE simple table in a Access database. And lets import that table to SQL server. (but as noted, since this is one table, then we can use a simple import. But, AGAIN, if you have a boatload of tables in that Access database, then a dedicated migration tool is MANY times a better choice then a simple import of a table).
So, the first step would be to create a database. This is much similar to Access. You create a new database, and THEN you are to migrate(or import) the Access tables (and data) into that SQL server database.
Once done, then step 2 is to create a linked table to that table sitting in/on sql server.
So, we fire up SSMS, and create a new table.
So, we right click on databases, and choose new database.
And then just type in a name for our database.
And now hit ok.
Now, we right click on this database, and choose import data.
eg:
Now, in this example, we will import just one table.
So, in the import options, we see/get somthing like this:
Note the number of choices. Well, if this is a mdb file, then from above choose the "JET" database engine.
But, if this is a accDB file? (access 2007 and later), then choose the Access data engine as I have.
(and you might have to change the file drop down from *.mdb to all files.
So, that selects the file.
Now next page, you have to select the sql server "driver".
You have TOO many choices here - and it can be VERY confusing.
So, by FAR the best choice here is to ALWAYS choose a SQL server NATIVE driver. (you don't have to - but it will be more pain and suffering if you don't).
So this one:
thus this:
And again, don't know if you using SQL server logons, or windows security here.
Ok, so now we get:
I'm ONLY selecting one table (because this is a CRAP AND BAD way to do a data migration by using a simple import - but we have to start somewhere!!!).
So, at this point, we should be able to expland our database, and see the ONE table.
this:
Ok, so now right click on this table and choose design.
The table designer in SSMS is VERY much like access, so it should be easy to do the next steps:
REMEMBER WHAT I stated above. The import option above we used is a POOR way to import data to SQL server WHEN the goal is to use our Access FE to link to this table.
The REASON WHY is becuase the import option is kind of like a dirty and quick import choice for Excel and flat files and is quick and dirty.
But, it does NOT set our primary key, and all the other settings we would typical have in the Access table (such as PK column, and autonumber).
So, now in design mode, we WILL set the PK column.
So click on the PK column (should be in most cases "ID" - the default for Access).
Then up in the SSMS menu, click on the primary key button.
this:
Ok, that gets the PK (primary key setting).
Now we ALSO need to set this PK as "auto number" (like it was in Access).
So this setting:
So, again, "ID" is selected, and in the property sheet, set the column to "is identify" "yes", and it will put in the 1 and 1 for Increment and seed.
You can now close this table.
So, as noted, for 1 or 2-3 tables, you have to do the above for each table.
As I stated, if you have 40 and ALSO related data and tables, then we want to use a automated tool (like the SQL migration assistant for Access - SSMAA).
But, for this ONE table test, then the above is just fine.
Ok, so now we go to our Access FE, and we can delete this one table that was linked to the back end. (again, we not deleting a table, but ONLY the old existing LINKED table).
Now we create a new linked table to the SQL server table.
In access, then this:
So that option allows us to import or link (we are going to link here).
and we get to this:
ALWAYS NO MATTER what, choose (leave the default to FILE) as per above, do NOT use Machine Data source).
Next we choose the ODBC sql server driver.
WHEN POSSBILE ALWAYS choose a native driver. However, this choice depends if you going to distribute your FE to many users. (the native 11, 12 and up to 18 drivers are NOT installed by default). If you don't see any native drivers, then choose "SQL Server", but the native drivers are a better choice (but the down side is these drivers will have to be installed on all computers. The "SQL Server" one can be a good choice, since it ALWAYS will exist on every computer).
In fact, for this lets go with SQL Server one.
So, this one:
So then this (choose a name) for the conneciton.
next, then finish, and we get this:
The drop down SHOULD show a list of SQL servers you have.
then choose your logon.
I don't know if you using windows authentication, or SQL server passwords.
Then:
SUPER SUPER IMPORTANT STEP!!!!!!!
MAKE SURE you choose your database with this drop down - don't skip this!!!!
Check the box Change the default database to box, and then choose your database we created.
This we can just hit next - nothing to change.
then this - you can (should) try the test data Source button.
Now we are all the way back to the near starting panel, and you can hit ok
And now we get/can select the table to link to:
find your table - select it, and ALSO check that save password button.
At this point, you should see a linked table in Access. If we open it, we get this:
I need to copy data from a linked server Oracle table and append to SQL Server table in a regular time interval.
Without using SSIS or any external etl, can this be done by using open query? I have read in forums that the table has to be exported to csv and then imported back again into SQL Server . Is there an alternative as this will be continuous process ?
Certainly. As long as you've configured the Linked Server properly within SQL Server, and your user account has the right permissions in Oracle, getting and sending data between the two is fairly trivial.
Selecting data from Oracle into SQL Server:
IF OBJECT_ID('tempdb..#myTemp') IS NOT NULL DROP TABLE #myTemp
SELECT *
INTO #myTemp
FROM OPENQUERY(MyLinkedServer, 'SELECT col1, col2
FROM OracleTableName
WHERE SomeColumn = ''Human Resources''')
Inserting data from SQL Server into Oracle:
-- note: please make sure you have your columns in the exact same order!
INSERT INTO OPENQUERY(MyLinkedServer, 'SELECT col1
FROM OracleTableName ')
SELECT myPK
FROM AdventureWorks2014.dbo.SomeTable
And you can even drop or recreate a table in Oracle from SQL Server, and run stored procedures.
To create a linked server, I use the below script and these settings:
-- make sure you have Oracle drivers on your SQL Server, and an up-to-date TNSNames.ora file
EXEC master.dbo.sp_addlinkedserver #server = N'MyLinkedServer', #srvproduct=N'Oracle', #provider=N'OraOLEDB.Oracle', #datasrc=N'TNS_NAME_HERE'
-- disable any logins not explicitly mapped
EXEC master.dbo.sp_droplinkedsrvlogin #rmtsrvname = N'MyLinkedServer', #locallogin = NULL
-- login mapping between SQL Server user and their appropriate Oracle account
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'MyLinkedServer',#useself=N'False',#locallogin=N'domain\username',#rmtuser=N'ORACLE_USERNAME',#rmtpassword='ORACLE_PASSWORD'
-- add a mapping for your SQL Agent account if these will run under jobs,
-- and your SQL Engine account if you still get errors on things that are automated,
-- unless those automated jobs are explicitly running under user accounts
Honestly, the hardest part is making sure you get Oracle drivers installed right on the SQL Server. After that, it's very straightforward.
What I need to do is, a client wants to have a report in an excel doc with multiple worksheets with custom headers. I have tried SSRS 2008 Report Builder 2.0 but naming worksheets is not available with SSRS 2008 Report Builder 2.0. I have tried bcp in SQL Server Management Studio, but am not able to export it into multiple worksheets. I have put the queries into temp tables, is there a way to export those queries into the same excel doc but different worksheets with a different header for each worksheet.
Like this
Notice how each worksheet has a different name and a different header.
Is this possible to do with SQL or is there a workaround for SSRS 2008 Report Builder 2.0?
You could use SQL Server Integration Services 2008R2 (SSIS) to do this. SSIS has an Excel Data Flow Destination that accepts a worksheet name as a parameter. You could construct your SSIS package to populate the various worksheets of a spreadsheet this way.
I know, I know... you too you faced the error:
Msg 15281, Level 16, State 1, Line 1
SQL Server blocked access to STATEMENT ‘OpenRowset/OpenDatasource’ of component ‘Ad Hoc Distributed Queries’ because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of ‘Ad Hoc Distributed Queries’ by using sp_configure. For more information about enabling ‘Ad Hoc Distributed Queries’, search for ‘Ad Hoc Distributed Queries’ in SQL Server Books Online.
You can do it in SSMS through T-SQL, follow this example:
First you need to allow SSMS to bypass the error:
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'Ad Hoc Distributed Queries', 1
RECONFIGURE
Then you can save the result in a precise Excel Tab this way:
INSERT INTO OPENROWSET('Microsoft.ACE.OLEDB.12.0','Excel 12.0;
Database=C:\Users\Zivko\Desktop\SQL Data.xlsx;','SELECT * FROM [Sheet1$]')
SELECT * FROM dbo.DimScenario
The file .XLSX must already be there with the tab having the precise name [Sheet1$]
I have a SQL Server Agent Job on "server X." This job is simple, and uses the following query to refresh a table (on server X) by clearing it, then re-populating it with data from a view (also on server X):
DELETE FROM [ClientList].[dbo].[LatestDownloadLogs]
INSERT INTO [ClientList].[dbo].[LatestDownloadLogs]
SELECT * FROM [ClientList].[dbo].[latestoverview-union]
The "LatestDownloadLogs" table is moving to "server Y," but the "latestoverview-union" view will remain on "server X".
Therefore what I need is something that looks like this:
DELETE FROM [server Y].[ClientList].[dbo].[LatestDownloadLogs]
INSERT INTO [server Y].[ClientList].[dbo].[LatestDownloadLogs]
SELECT * FROM [server X].[ClientList].[dbo].[latestoverview-union]
Of course, it's not that easy, but hopefully that illustrates what I'm trying to accomplish.
Create a linked server on server x to server y.
You could use OPENROWSET, which'll require the connection info, username & password...
But first you may need to turn on Ad Hoc Distributed Queries
EXEC sp_configure 'show advanced options', 1
reconfigure
EXEC sp_configure 'Ad Hoc Distributed Queries', 1
reconfigure
You can then select, insert or delete
SELECT FROM
OPENROWSET (... params...)
UPDATE
OPENROWSET (... params...)
Hope this helps... good luck.