Some datatype considerations that must be noted.
Joins between char columns and varchar columns may not return any rows. In addition, a query returns no rows when run directly against Oracle. However, when you run the query against Adaptive Server with the same data, it returns rows. The difference occurs because Sybase and Oracle have different comparison rules when the columns are not all fixed length. Alter the table definitions so the column definitions match.
Oracle pads raw(n) datatypes with blanks when users insert values less than n. SQL Server pads binary(n) datatypes with 0s when users insert values less than n.
An error may occur if an Adaptive Server user expects 0-padded data yet accesses blank-padded data. Likewise, there may be problems if native Oracle applications expect to see blank-padded data, yet access 0-padded data.
Oracle allows number datatypes to have a scale larger than the precision. Adaptive Server numeric datatypes do not allow this.
Oracle allows number datatypes to have negative scales. Adaptive Server numeric datatypes do not allow this. If Oracle precision and scale are not specified, precision defaults to 38.
If existing Oracle tables have datetime values with dates earlier than the Adaptive Server minimum date (January 1, 1753 12:00:00:000AM), ECDA Option for Oracle converts these values to the Adaptive Server minimum.
Adaptive Server unichar and univarchar datatypes are supported with Oracle 9i databases. Oracle errors result if these datatypes are used with earlier versions of Oracle.
To support the Adaptive Server unichar and univarchar datatypes, configure ECDA Option for Oracle to use the utf8 charset for both Sybase and Oracle:
This example shows the configuration values needed to support Unicode for a server named “unidco” which uses us_english as its language.
[unidco] charset = utf8 language = us_english . . . [languages] ; ; Maps a Sybase language to an Oracle Language, Territory, and Charset ; us_english american america utf8