Наскоро клиент сподели решение, което разреши проблем, възникнал при използване на нашия SQL Server ODBC драйвер за свързване на Oracle към SQL Server. Грешката, която клиентът получаваше, беше:
DELETE FROM mytable@MYLINKEDDATABASE WHERE MyCol = 'MyValue'; 17:01:01 [DELETE - 0 row(s), 0.000 secs] [Error Code: 2070, SQL State: 42000] ORA-02070: database MYLINKEDDATABASE does not support some function in this context
и това беше разрешено от:
SQL> select fds_class_name from HS_FDS_CLASS;
ODBC11.2.0.2.0_0008
exec dbms_hs.replace_class_caps('ODBC11.2.0.2.0_0008', 564,'ODBC11.2.0.2.0_0008',564,
8191,NULL,1);
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete В Oracle „SELECT FDS_CLASS_NAME FROM HS_FDS_CLASS“ ще върне низ, който идентифицира вашата версия на DG4ODBC. Напр.:
ODBC11.2.0.2.0_0008
Изпълнение на тази заявка:
SELECT * FROM HS_CLASS_CAPS WHERE FDS_CLASS_NAME ='ODBC11.2.0.2.0_0008';
връща редица "способности", които показват как DG4ODBC е конфигуриран да се държи.
В показания по-рано пример колоната клиент беше NVARCHAR Тип. Под ръководството на поддръжката на Oracle клиентът променя начина, по който DG4ODBC се държи по отношение на този тип данни.
Клиентът намери съответното поле в HS_CLASS_CAPS :
564 TO_NCHAR(op1) 0
и го промени с пакета Oracle, DBMS_HS.ALTER_CLASS_CAPS .
Имайте предвид, че това, което правят различните възможности на DG4ODBC, изглежда не е документирано никъде публично. Следователно този блог не може да предостави конкретни насоки как да ги използвате за разрешаване на конкретен проблем. Вместо това блогът е предоставен, за да ви уведоми, че имате друг инструмент на ваше разположение, ако редактирането на параметри в конфигурационния файл DG4ODBC, init
Вижте също
- Изтриване или актуализиране на изявление с помощта на TG4MSQL 10.2 или DG4ODBC 11.2 Препращане към полето Nvarchar, където клаузата дава грешка ORA-2070
- Re:Проблем с Oracle Database Gateway за ODBC и Unicode
