For a new project we have to export data from a SQL Server 2012 database to a PostgreSQL database. We have the SQL Server schema but have to create one for PostgreSQL. As far as possible we would like the schemas to match. Can anyone give any advice on the best way of converting a SQL Server schema to a PostgreSQL one? Are there any tools or scripts which will help? I have seen a PostgreSQL function but to be honest I have no PostgreSQL experience and our remit stops at the data being imported into PostgreSQL so I would like to do everything from the SQL Server side (planning to use SSIS with the 64-bit ODBC driver for PostgreSQL to export the data once we have the schema created)
Although not free, I've used Toad Data Modeler for this in the past. We never used it on any particularly complex schemas, but it did do a good job of keeping schemas in sync between various DB platforms.
Your mileage may vary, but it's worth a look.
I don't know a direct schema converter but most data modeling tools offer such conversion functionality. We use Dezign for Databases. This tool has got a function "switch target dbms". This a data modeling tool just like Toad Data Modeler mentioned here before. With the database independent modeling functionality you can keep schemas on different db platforms in sync. For data synchronization (data pump) between different database platforms you can use DataDiff CrossDB.
Related
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 am generally a Sql Server coder, but we have a client who wants to move a system from Sql to ORACLE due to the new licensing model of Sql Server.
I know historically, ORACLE has no logical grouping of objects within a db/schema, along the lines of a Sql Server schema. It's been a while since I've done any real ORACLE work though, so I'm just wondering if somewhere along the line, they may have added such a construct?
The version of ORACLE we are porting the Sql Server database into is ORACLE 11g (11.2).
Traditionally, I've seen oracle developers do this using just a prefix on table/view/object names. So for example a Sql Server object users.OPTIONS might become USR_OPTIONS in ORACLE. This works to be sure, but it just feels really kludgey to me, as it's not so much an actual hierarchy, but is sort of "forcing" one in by simply using contorted names.
Oracle has schema support in Oracle 11gR2. Oracle schemas are tied to a user. You'll have to (somewhat confusingly) create a user for each schema that you're creating. This isn't a big deal, but some people find it distasteful.
Oracle 12c Enterprise Edition has a feature called Multitenant that allows for multiple databases on the same Oracle server in much the same way that SQL Server allows out of the box.
We are trying to build a data access layer for using both Oracle and SQL Server (not at the same time).
We use EF Model-first for creating the model and the create the SQL scripts for building the database. Our first thought was to create 2 EDMX files, one for each type, and use the appropriate one depending on the client's need. We are using the Oracle and SQL Server database generation workflow and DDL generation template to create the scripts for each database.
Our main problem is when the database schema changes we do not want to drop and recreate the DB but only create the migration scripts to update the DB base on our model (clients have many data that will be lost).
We use EF power pack for extracting the migration scripts for SQL Server but there is nothing like it for Oracle.
We want help to find a good data layer (1 EDMX for both Oracle and SQL Server if it's possible and not complicated) and a good way to generate database changes from our model to update existing client DBs in case of a new application release
We found this as a starting point
http://msdn.microsoft.com/en-us/data/ff830362 but there is not mention for Oracle support.
We have tried code-first and EF Migrations but Oracle failed us again on the DB creation and migration.
Any recommendation on how we can accomplish this?
Thank You
There is no way to have single EDMX for both SQL Server and Oracle. EDMX consists of three parts CSDL (entity definition), SSDL (database definition), MSL (mapping between those definitions). SSDL must always target concrete database so you need at least separate SSDL for Oracle and SQL Server and if you are lucky you will not need separate MSL as well (mapping must be exactly same which will probably not happen if you are using any tool to generate the database).
So you always need at least part of EDMX file for second DB and manually maintain it.
If you need DB migration supporting Oracle you must look for tool from Oracle (or third party). For example RedGate offers tools supporting schema migration for both SQL Server and Oracle.
Visual Studion Premium and Ultimate edition also offers tools for comparing database schemas. It by default supports only SQL Server but Toad Extensions should add support for Oracle as well.
Once you have any of these tools you just need to compare schema deployed on customer server with your new schema and the tool should create migration script for you.
The best article I found on this topic is from Paul Reynolds Blog.
Try to go through from part 5 to part 9.
There are so many gotchas about Oracle mentioned there... is very helpful!
Is it possible using SQL Server Replication to replicate data to AND from (bi-directional) Oracle and SQL Server? The schemas are completely different. In real-time would be a bonus.
Have already investigated Oracle Golden Gate, which seemed to do the job, although the licence cost is not insignificant!
I wondered if anyone has had any experience in replicating data across different schemas, and what other tools they employed? I realise this is a bit of an open-ended question but any advice and previous experiences would be most useful.
Thanks
Duncan
I recently had to create a solution to import periodically lots of data from different databases (most of the time from Oracle databases) to a SQL Server database (a data warehouse). To do so, I used SQL Server Integration Service to create a package able to import, transform and insert the data as I wanted (since it was from heterogeneous sources too). This software comes with SQL Server and the version 2005 and superior is really easy to use (graphical programming). In your case, you could trigger your created services when needed. I am not sure it is the best solution since you would need to create a SSIS service for each direction (from Oracle to SQL Server and from SQL Server to Oracle).
I have an Interbase DB. How can I convert it to SQL Server?
You could use SQL Server built in Data Transformation Services (DTS) in SQL Server 2000 or SQL Server Integration Services (SSIS) in SQL Server 2005.
Try setting up an ODBC DSN for Interbase. Then in DTS / SSIS use the Other (ODBC Data Source) and the DSN.
If that does not work then see if Interbase has a utility to export to text files and then use DTS / SSIS to import the text files.
If you want to spend some money, this will do it:
http://www.spectralcore.com/fullconvert/tutorials/convert-interbase-firebird-to-mssql-sql-server.php
The Interbase DB Wikipedia page says that it supports OBDC and ADO.NET, so I would think that SQL Server can probably import this database on its own. I don't have access to an Interbase DB installation to try, but you might find these pages helpful.
MSDN on import data wizard
MSDN on bulk import command (if Interbase DB can dump a text file)
Article on bulk importing from an ADO.NET supporting source
Hopefully somebody will have direct experience with this database and can help. Good luck!
If you only need to convert tables and data, that's rather simple. Just use ODBC driver for InterBase, connect to it and pump the data.
However, if you need business logic as well, you cannot covert it just like that. You can convert regular tables and views without too much problems. Domain info would be lost but you don't need it in MSSQL anyway. The only problem with tables can be array fields, which you need to convert to separate tables, but that isn't too hard either.
The problem is the conversion of triggers and stored procedures, since InterBase uses its own, custom PSQL language. It has some concepts that are different from MSSQL. For example, you have procedures that can return resultsets, and you would need to convert those to MSSQL functions.
In any case, it shouldn't be too hard, since you're going from low to high complexity, but there are no tools to do it automatically.