Data Source Type | Limitation |
Microsoft SQL Server | When using Microsoft SQL Server with the bcp utility, you might get data type mismatch errors if you are using BLOB or CLOB data types. |
To Netezza | Netezza cannot be the data ship target for source tables containing data of type BINARY or VARBINARY (for example Oracle). |
Netezza cannot be the data ship target for tables with LONGVARCHAR or VARCHAR columns more than 64 KB long, because creation of the temporary table fails. | |
When Netezza is the data ship source, data types of FLOAT or DOUBLE might lose precision because of rounding of values sent to a target of a different type. | |
Netezza to Sybase IQ | With data ship from Netezza to Sybase IQ, NULL values are replaced with zeroes, which results in different query results than when data ship is disabled. |
Sybase IQ or Netezza to Oracle | When Sybase IQ or Netezza data sources use Oracle as a data ship target, trailing spaces sent in the shipped table are trimmed in the result sets with the Oracle table. |
Sybase IQ to Netezza | When Sybase IQ data sources use Netezza as the data ship target can cause a data mismatch because the Netezza database appends a padding space character in result set data. |
To Oracle | If an Oracle database is a data ship target and the transferred data contains UTF-8-encoded East Asian characters, a column length limitation exception can occur. Oracle databases with a UTF-16 character set does not have this problem. |
To Sybase IQ | If you are moving data of type FLOAT to a Sybase IQ database, the scale of the data can be lost because of the way that the Sybase IQ JDBC driver handles the FLOAT data type. |
Sybase IQ Type4 Driver | Sybase IQ Type4 driver appears to lose the precision of time stamp columns by promoting or demoting it. To avoid this issue, use the Sybase IQ Type2 driver. |
Teradata | Teradata controls the number of concurrent FastLoad and FastExport tasks using the MaxLoadTasks and MaxLoadAWT parameters. Excess FastLoad or FastExport tasks are rejected. |
The maximum number of sessions for each FastLoad or FastExport job is limited to the number of AMPs of the Teradata database. Eight sessions work well for most scenarios. | |
Teradata’s implementation of UNION does not follow the SQL standard, which can result in a data mismatch when the data is shipped to Teradata. | |
A row fetch size bigger than 64 KB causes a Teradata error. Refer to Teradata documentation for the best solution to this problem. | |
Teradata FastLoad requires that the target table be empty. If the target Teradata table is not empty, JDBC is used to load data into the table. | |
To Vertica | For Vertica, the maximum length of a BINARY or VARBINARY column is 65000. |