I transfer data from Postgre to SQL Server using SSIS. and somehow the result is not the same like the source, There is special character between code.
Source data in Postgre CL019-B-1003MIN01
Destination data in SQL CL019-B-1003�MIN01
Can you guys have a clue about this ?
Thanks
Related
Migrate a table from Oracle to SQL Server.
I have used Toad to export (select * from table) into a pipe delimited .txt file so it can be used to be consumed in SQL Server. Now the Oracle table has a DATE column and the output from Toad for that column is (2/26/2016 3.05.10.000000 PM). This format is not being compatible for the datetime column in SQL Server side.
I feel we can convert the date in Oracle to a compatible SQL Server format for easier ingestion.
Please help me understand the conversion both from Oracle to a compatible SQL Server format.
Create Oracle Linked server in SQL Server with ODBC connection. and use that Linked server to play with Oracle and SQL Server tables using SQL Server.
You must understand that DATE datatypes are binary data. Using to_date() on a column that is already a DATE is inappropriate. It forces oracle to perform (behind the scenes) a to_char() on the DATE column in order to produce character data that is the required input to to_date(). Then, when you see (in your text csv file) that it has produced a "date" in some particular format, it is because oracle has then had to run the result of your to_date() back through to_char(), using the default NLS_DATE_FORMAT setting to produce a character string for the text output.
So your solution is this:
First, determine what text format of a date MSSQL wants when it uses this csv file. I don't know what that is, but for the sake of argument, let's say it is 'yyyy-mm-dd'. With that information, construct your SELECT in oracle like this:
select mycol1,
to_char(my_date_col,'yyyy-mm-dd'),
mycol2
from my_table;
That said, I agree with the others, why bother with this cumbersome process in the first place? Or even some other intermediary like SSIS? Why not just create a shared server in MSSQL and query the oracle table directly? Or create a database link in the Oracle DB and, using the oracle transparent gateway as the conduit, INSERT directly into the MSSQL table from Oracle? Either the linked server or the database link will be much faster than any external process.
I would suggest a best way to transfer Oracle table to SQL Serveris by using SSIS package.
You can have a Source as Oracle and your conversion issue can be fixed by Data
Conversion task and your Destination can be SQL Server.
We have 40+ Tables present in SQL SERVER DB and we need to copy the data to an IBM DB2 database. What methods do you recommend to accomplish this?
My ANALYSIS:
BCP and Data Import - The team is trying to avoid any BCP files
Write Stored procedure and use LINKED Server in SQL and insert the data in DB2
SSIS Packages to move data.
Please let us know if you have any better way to approach this issue.
Have you considered Information Integration, that is known in DB2 as federation? you can do a select in SQL Server directly from DB2, and with this feature you can define a cursor and then just use the LOAD command.
I am into data migration team, right now we got a project of Japanese database migration. We need to migrate all japanese data to our Oracle database. After which we need to compare Japanese data between source and target database. I just want to know is it possible to write normal SQL queries for Japanese data in SQL server, will it work and What are the risks associated with this?
It should be no problem - SQL Querys in Japan are the same as in the other parts of the world.
There may occur some problems in case of data formating + converting (string format, datetime, collation) + string comparison so I suggest some testing before the whole migration process.
I have an ETL that is importing tables from Oracle to SQL 2008 using the OLEDB FastLoad.
The data in Oracle is non-unicode.
When the table is created in SQL it is created with unicode datatypes.
For some reason the datatypes are being forced from non-unicode to unicode.
Do any of you know of a way to stop this from happening?
Possibly a Oracle driver problem?
I'm presuming you are using SSIS?
Guess what, SSIS wants everything to be unicode, so it assumes that all incoming data is in unicode. If you don't want it to be unicode, you will need to convert each field using a dataconversion task.
This is something you might want to try. Check the value of the NLS_LANG variable in the Oracle Database you are importing to. Changing this variable before running the ETL could help you.
Check the NLS_LANG faq here:
http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm
I am trying to insert rows into a MySQL database from an Access database using SQL Server 2008 SSIS.
TITLE: Microsoft SQL Server Management Studio
------------------------------
ERROR [42000] [MySQL][ODBC 5.1 Driver][mysqld-5.0.51a-community-nt]You have
an error in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '"orders"' at line 1
The problem is with the delimiters. I am using the 5.1 ODBC driver, and I can connect to MySql and select a table from the ADO.Net destination data source.
The MySql tables all show up delimited with double-quotes in the SSIS package editor:
"shipto addresses"
Removing the double quotes from the "Use a table or view" text box on the ADO.NET Destination Editor or replacing them with something else does not work if there is a space in the table name.
When SSIS puts the Insert query together, it retains the double quotes and adds single quotes.
The error above is shown when I click on "Preview" in the editor, and a similar error is thrown when I run the package (albeit then from the actual insert statement).
I don't seem to have control over this behavior. Any suggestions? Other package types where I can hand-code the SQL don't have this problem.
Sorry InnerJoin, I had to take the accepted answer away from you. I found a workaround here:
The solution is to reuse the connection for all tasks, and to turn ANSI quotes on for the connection before you do any inserts, with an Execute Sql task that runs the following:
set sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION,ANSI_QUOTES'
Try using square brackets around the table names. That may help.
EDIT: If you can, I would create views (with no spaces) based on the Access tables, and use those to export. Even if it means building another Access database with linked tables, I think this is your best bet.
I've always struggled with using SSIS with MYSQL directly. Even after installing the ODBC drivers, they just don't play well in data flows. I've always ended up creating linked ODBC connections between SQL Server and MYSQL. I then rely on linked server queries to bring over data. Instead of using a SSIS data flow task, I use an Execute SQL command, usually in the form of a stored procedure that executes an OPENQUERY.
One solution you could do is load the data into a SQL Server database and use it as a staging environment before you load it into the MYSQL database. I regularly move data between SQL Server 2008 and MYSQL and in the past I use to regularly move data between Access and SQL Server.
Another possible solution is to transform the incoming Access data before it loads into the MYSQL database. That may give you a chance to clean up the column names and the actual data that's going through to MYSQL.
Let me know if either of these work for you.
You can locate the configuration setting file my.ini at <<Drive>>:\ProgramData\MySQL\MySQL Server 5.6\my.ini and add "ANSI_QUOTES" to sql-mode.
e.g: sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES". This should solve the issue while previewing in the SSIS editor.