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 a 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, because 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.
(CR 401934) DirectConnect for Oracle has multiple settings that correspond to the character set and language setting, which can set in many ways. However, you must keep the character set setting consistent with the charset, languages, and charset settings.If the configuration parameter charset is set to Sybase iso_1, the mapping coded in the “charsets” stanza must be mapped to Oracle’s equivalent character set, which is we8iso8859p1. In addition, this setting must also be reflected in the “languages” stanza by including the we8iso8859p1 in the Oracle charset setting. If these are not set consistently, if a character is used that is contained in either the Sybase or Oracle character set and not in the other, you may receive an “ORA-00911: invalid character” message.DirectConnect for Oracle converts the incoming client characters to the charset setting, which should match that of the Oracle setting. When characters are returned to the DirectConnect for Oracle client, they are then converted back to the character set setting of the client.The language setting corresponds to the language in which the local DirectConnect for Oracle error messages are returned. The setting for Oracle Language and Territory coded in the languages stanza is the language in which the Oracle defined error messages will be sent back to the client. All attempts must be made to make sure the language settings match.
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 will 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 performs blank-padded comparisons.
The Admin Service of DirectConnect 12.6.1 has been changed from to read and write encrypted passwords to the user.pwd file. Earlier versions of user.pwd files are not supported with DirectConnect 12.6.1 and will result in administrator login failures. To fix this problem Administrator IDs and passwords from earlier installations must be reentered to the new Admin Service.
