I'm in the process of porting some SQL Server 2005 databases to SQL Server 2008. One of these databases has an associated import application (Windows task) which uses SSIS with a DTS package to import a large dataset from an MS Access database nightly.
In upgrading to SQL Server 2008, I discovered that I can't run the same console application which has been performing the imports due to the missing manageddts DLL in SQL Server 2008. It's several years old and in need of a rewrite for various reason, plus, I've been fairly unhappy with DTS in general. The original reason DTS was chosen was for speed (5 min import time compared to 30+ for ADO.NET).
The format of the data to import is out of my control (the client likes Access). I would also like to be able to run the import from a machine completely separate from the server hosting SQL Server and preferably with minimal SQL features installed.
Options I've considered:
Creating an Access application to connect to both databases (SQL Server and Access) and perform the import (Ugh!)
Revisiting ADO.NET to see if the original implementation was poorly written.
Updated SSIS packages.
What other technologies should I be considering for this job?
I received a suggestion that I use ADO.NET to convert the .mdb file to a bunch of flat files, then use tsql's bulk insert statement to import the flat files. If it works, I'll mark this as the answer.
EDIT:
This worked really well. Far speedier than the old DTS. One down side is that the import user must have bulkadmin rights, and the schema of the flat files must precisely match the tables, but a little coding solved the latter, and a secure, dedicated user account answers the former.
I'm fairly happy with the result.
I guess you should try SSIS. If you don't know enough of it, you will learn a new thing.
Related
I'm working on automating daily imports to my SQL Server (2012) database, but my IT admins are being...unhelpful in implementing the options I'm familiar with. Namely BULK INSERT, OPENROWSET, and to some extent SSIS packages.
I know what the blocking issues are for BULK INSERT and OPENROWSET but IT has declined to address them. They're working on the SSIS issues, but I'm not confident they'll be done anytime soon, so I'm looking for other options.
So, are there other programmatic import options besides these three? Specifically for flat .txt files and .xlsx
I'm new to Microsoft world. I've been tasked with migrating an MS Access 2007 database to SQL Server 2012 database. It will be a one time migration for a client, that will be using SQL Server 2012 moving forward and will drop MS Access from their ecosystem.
Currently, MS Access database has 300 or so tables, with almost no pk/fk connections between tables. A lot of data is replicated within and across the tables. I don't have to redesign the database or normalize it in any way (although looking at it I am itching to do it,but will not). It also has a lot of queries, modules, and macros, along with forms and reports.
While reading about this task at hand and researching online, I came across three possible solutions. Since I have limited experience in db world, I'll need some guidance as to what the pros/cons of each option will be for this specific scenario?
Use SQL Server data import wizard. This seems like a good option. It is easy to use and the task is one time only. Not sure if it will import other objects too (queries etc.).
SSMA is another option, not sure how it is different than the data import wizard.
A colleague suggested SSIS for the task. To me it seems like an overkill, but I don't know enough to make this judgement.
What I'm looking for is some advice on which of these options to use from someone who has done something similar (which I think is not a rare task), to share their experience and industry best practice.
One-off migrations? - use the SQL Server Migration Assistant (SSMA) or the SQL Server Import Wizard.
Repeated, scheduled migrations? - use SQL Server Integration Services. It provides better scripting support that will allow you to repeat the same process to your heart's content.
Between SSMA and SQL Server Import Wizard however, I would recommend SSMA. Not only is it streamlined and straightforward, it provides better support for migrating all your objects from an Access database (Tables and queries) to SQL Server. You can follow this tutorial for learning how to do this: http://sqlturbo.com/from-access-to-sql-with-microsoft-sql-server-migration-assistant-for-access/
I want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.
I'm being demanded to develop a new software that must be built over SharePoint and use Microsft SQL Server 2012.
I have a DB in Postgres, and some of its tables will be used in this new project, so I must import these tables, everyday. I'd like to use WebService to do it, but they want it to be done DB-to-DB directly.
Postgres-to-Postgres is already done and it "works", but importing to Microsoft is being troublesome.
Does anybody know some MSSQL tool that can connect to Postgres and do the import?
Typically for this sort of situation (assuming that it'll be a process that's repeated on a regular basis) you'd use SSIS (comes with most versions of MS SQL Server). Have a look at the first several hits on this Google search, especially the first one.
Another option is to connect to the Postgres database directly from your application via ODBC, and eliminate the redundant copy of the data - and get real-time updates instead of having to wait for the next execution of the SSIS job.
I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.