I'm trying to create a completely new database from an existing MySQL database, bringing over both data and schema, but so far the only way I've been able to do this is to first import the MySQL database into MS Access, and then into SQL Server 2005? Crazy right? Surely, there is a way that doesn't involve a tedious, custom time-consuming programming, right (perhaps using SSIS)?
A few additions to my original description above:
Its a pretty good size database (easily a few gigs).
I'm working in an MS environment (asp.net, C#)
I'm under a tight deadline so I'm looking for an automated process that requires little to no effort in the conversion process.
SSIS would be the preferred way via BIDS (VS 2005)
Thanks for all the great input!
I believe that using the phpMyAdmin tool you can script the MySQL database structure and data into a sql script. Then you simply run those two scripts on your SQL Server 2005 database and it should, in most cases, create the database and fill it with data. It's been a couple years since I had to do it myself, but as I recall that was the process I used to transfer a MySQL database to SQL Server in the past. You will probably have to alter the structure script to change some of the data types to their SQL Server equivalents, but the data should load just fine once you've got the data types all sorted.
I think you can use SQLYog to generate some fairly standard SQL which will dump out and recreate your db, with data. You may have to massage its output for SQL Server's dialect of SQL a bit, though...
The responses I received were certainly helpful, but the solution it would seem is to do a mysqldump and then run that script from SSIS, massaging the output as needed; however, AFAIK it is not possible to use VS 2005 BIDS to create an SSIS package that completely transfers a MySQL database to a SQL Server 2005 database (data and schema) using Windows Vista 64. I said AFAIK, but who knows the interwebs have much to reveal :)
Related
I am struggling a bit with the following. Our forecasting tool generates some 100k of records of forecast information in Access each month. The tool is an Excel - Access combination. I want to upload the data from Access to SQL Server after the forecast is done (for multiple purposes). I tried to look up the most easy way but not sure what to use. ADO seems handy where I could integrate that in an existing macro that cleans up the database. Anybody done this before and has some snippet of code to use?
We use SQL Server Management Studio 2008, but not sure whether that's relevant here.
Thanks in advance,
Michiel
In Access, link via ODBC the tables in SQL Server you wish to upload to.
Then create and run append queries to insert the data in the linked tables.
I suggest using SSIS package which is started by job on sql server side (by shedule or manual). You can create package with the help of sql server import/export wizard. I think this is the best way to import data from access to sql server.
Thanks for the answers. I will try to do the linked table way, but I already had a look to that and it seems that due to the fact that I use citrix server I was not able to link it directly to SQL server via ODBC. So I have to check what's different there. Not familiar with the SSIS package yet but I will definitely look into that if the first option does not seem to work out.
Thanks again guys
We are in the process of moving our backend from ms sql server to mysql. Actually we currently use a couple mysql servers, but mostly ms sql server. I mention this because we are not totally new to mysql. Each day we do a lot of ETL to keep our backend in sync with a legacy system. We move a lot of data and working with sql server has been so much easier than working with mysql for ETL. I know SSIS is MS, but still it has been a headache.
We are using sql server 2012 and BIDS 2010. It has been a struggle to move mysql data at the same rate as ms sql data. We are mainly dealing with innodb tables in mysql. To summarize I have been using the mysql ODBC connector and the ODBC destination in SSIS. The first step is to turn autocommit off on imports. Even with that setting off I can see in package execution that the data source ends up waiting on the destination. It gets about 40,000 rows ahead and waits.
Next I export the data to a text file and then import using a sql task and the INFILE command. This gives pretty good performance, but at the expense of more moving parts. I've had a couple issues with this approach, but it does work and perform well.
Lastly I tried a 3rd party SSIS component from Devart. It creates custom mysql source and destination components. The performance isn't as good as INFILE, but it's not bad and it makes the package simple like when dealing with sql server... a data source and a data destination. No messing with auto commits, exports, INFILE, etc. However I can't use the connections to do other tasks like truncate tables and stuff. So I still have my ODBC connection to do those tasks. I'm going to ask Devart about this.
Right now it looks like Devart is going to be a nice balance. If I absolutely need the performance I have the INFILE method.
I also tried the mysql net connector and could not get that to work at all. I'm running on Windows 7 64bit with Sql Server 2012 64bit. Basically everything I need in BIDS runs in 32bit so I'm guessing this part of issues.
My question is what are others doing when it comes to moving mysql data with SSIS? It has been such a hassle. It would be nice to get some input on what others are doing. What methods are you using? Are you using 3rd party components? Is there a better/dedicated place to discuss SSIS and mysql?
We are planning to migrate an Oracle 10g database to SQL Server 2008 R2. At the moment nothing is implemented in the target database and this will give us the opportunity to change and improve the existing schema during the migration.
Not only the data, but also stored procedures and views have to be imported.
I already worked with SSIS and I found an excellent product for data manipulation. A colleague mentioned SSMA for the migration. However after some research on the net it seems that it would be suitable mainly for data migration and conversion, while SSIS seems to provide a wider set of functinalities (Tasks, custom scripts, etc).
Which are the pro/contra of the two products and which one would best fit for the task?
I would recommend a hybrid approach. Use SSMA to convert the schema and objects from Oracle to SQL Server. Then improve and or change the objects as you see fit on the SQL end. Once your satisfied with your new schema. Use SSIS to move the data still waiting on the Oracle side into the new schema waiting for it on SQL.
As for a quick comparison of SSMA and SSIS... SSIS is by far superior for the ETL aspects of moving data from one place to another; but I wouldn't necessarily recommend it for the creation/modification phase of what you describe above. I think you'll find that process much easier with SSMA. On the flip side SSMA doesn't offer much in the way of transformation during the copy process.
I would go for an hybrid of the two.
Do you know you can trig SSMA from command line? This way you can execute the SSMA migration as a part of the SSIS solution.
You can also save your SSMA project as an SSIS package:
Once migrated keep doing the extra work with SSIS.
I have a table in SQL (using SQL Server Management Studio 2008) that's around 300,000,000 rows. Due to powers beyond my control this lovely table has to be converted to access datebases (plural since there is no way access will ever be able to handle so many rows).
I was hoping that rather than face the rather daunting tast of creating many csvs and importing them each into their own database there was a way to automate the process? Any ideas?
Thanks so much!
My suggestion would be to leave it in SQL server and use an ODBC connection to access it from MS Access
Is there any way we can share the SQL Server 2008 database Diagram (Other then capturing the jpeg).
I've used the 2005 version of this tool which did the job very nicely.
EDIT: The original link is dead. However http://devnuggets.blogspot.com/2011/04/script-diagram-really.html seems to be the same person's code for scripting/moving diagrams.
The SQL Server 2008 diagrams are stored in a sysdiagram table in the same database as a binary value.
We can copy the binary data and then reinsert them at another databse to recreate them there. But the table structure of the database needs to be there as well. So in this case it is of no important use for sharing.