Following are issues pertaining to DirectConnect for Oracle.
If you set up DirectConnect for Oracle as a Windows service, you must remove the service using instdco.exe as described in the DirectConnect for Oracle User’s Guide. The InstallShield Uninstall process does not remove the Windows service.
If the default character set for DirectConnect for Oracle does not match that of Adaptive Server Enterprise/Component Integration System (ASE/CIS) and writetext is issued to insert text, the text field is not converted as expected. For the us_english language, this should not be a problem, as the normal printing characters are the same in the supported character sets. However, for other languages, this can pose a problem.
The workaround is to make sure that ASE/CIS has the same default character set as DirectConnect for Oracle. For better performance, it is always best to use the same character set.
Joins between char columns and varchar columns might not return any rows. In addition, the query returns no rows when run directly against Oracle. However, running the query against Adaptive Server with the same data will return rows. The difference occurs because Sybase and Oracle have different comparison rules when the columns are not all fixed length. The workaround is to alter the table definitions so the column definitions match.
If a column c1 of type char(5) has a value “a” inserted into it, the following SQL statement does not return any rows if the table is on an Oracle database:
select...where c1 like "a"
Oracle does not make blank-padded comparison for arguments to like clauses. However, when executed against a table on Adaptive Server, the same SQL statement fetches the row.
Given the same setup, the following SQL statement returns the row when the table is on either Adaptive Server or Oracle:
select...where c1 = "a"
When c1 = “a” is used, Oracle produces blank-padded comparison.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
