Уважаемые колеги,
подскажите пожалуйста наиболее простой способ (или комбинацию технических приемов) копирования таблиц из исходной БД ASA 7.0 в другую БД ASA 10.0 на одном и том же компьютере без применения апгрэйда исходной БД до версии 9.0 и использования утилиты dbunload.

Ggg_oldнастройте линк между базами и через него вытягивайте таблицу.А где можно прочитать про линки ?

Dim2000
Бока wrote:

> А где можно прочитать про линки ?

Всё понятно . Задача не по твоим знаниям.
Posted via ActualForum NNTP Server 1.4Ясное дело, так помогите необходимые знания получить максимально простым путем, если Вы конечно знаете где эти необходимые знания лежат.

Бока Dim2000
Бока wrote:

> А где можно прочитать про линки ?

Всё понятно . Задача не по твоим знаниям.
Posted via ActualForum NNTP Server 1.4Ясное дело, так помогите необходимые знания получить максимально простым путем, если Вы конечно знаете где эти необходимые знания лежат.Можно ли это сделать в одной сессии утилиты dbisql ?

Бока Бока Dim2000
Бока wrote:

> А где можно прочитать про линки ?

Всё понятно . Задача не по твоим знаниям.
Posted via ActualForum NNTP Server 1.4Ясное дело, так помогите необходимые знания получить максимально простым путем, если Вы конечно знаете где эти необходимые знания лежат.Можно ли это сделать в одной сессии утилиты dbisql ?Я имел, в виду следующее: есть ли способ, находясь в коннекции к target ASA 10.0 DB в сессии dbisql, скопировать таблицу из source ASA 7.0 DB с помошью техники линкования ?

White Owl БокаЯ имел, в виду следующее: есть ли способ, находясь в коннекции к target ASA 10.0 DB в сессии dbisql, скопировать таблицу из source ASA 7.0 DB с помошью техники линкования ?
Есть, есть. Читай в BOL 10 раздел SQL Anywhere® Server - SQL Usage - Accessing Remote Data Спасибо.

А при использование ODBC-шного варианта, достаточно ли для поддержки такого варианта поставить пользователю вместе с БД только Engine, например для ASA 10.0 - это dbeng10.exe, dbodbc10.dll, dblgen10.dll ?

Если можно, то прошу Вас уточнить список DLLs и EXEs, необходимых для реализации использования линкования в ODBC-шном варианте. Дело в том, что Sybase oграничивает для нас тиражирование компонентов ASA своим пользователям, а навязывать им покупку полной версии ASA мы не хотим.

В сессии dbisql, в коннекции к database user поименованному как "INTER", который имеет authorities of DBA and Remote DBA (это на всякий случай), последовательно запускаю следующие команды со следующим успехом:

DROP SERVER ASA70;
Execution time: 0.016 seconds

CREATE SERVER ASA70 CLASS 'SAODBC'
USING 'driver=C:\Program Files\Plant\dbodbc7.dll;dsn=ASA70_SOURCE';
Execution time: 0.031 seconds

DROP EXTERNLOGIN INTER100 TO ASA70;
Execution time: 0.032 seconds

CREATE EXTERNLOGIN INTER100 TO ASA70
REMOTE LOGIN INTER70 IDENTIFIED BY INTER70;
Execution time: 0.015 seconds

CALL sp_remote_tables (@server_name='ASA70')
Could not execute statement
Unable to connect to server 'ASA70':[Microsoft][ODBC Driver Manager]
Data source name not found and no default driver specified
SQLCODE=-656, ODBC 3 State="HY000"

При этом:
- DSN с именем ASA70_SOURCE определен в Registry фолдере HKEY_LOCAL_MACHINE\ODBC\ODBC.INI\ и соответствующая база стартована by ASA 7.0 Engine из одной из наших аппликаций;
- попытка протестировать коннекцию к данной БД из ODBC Data Source Administrator πριςοδιτ κ τοму, что при нажатии на кнопку "Configure" появляется сообщение
"Тhe setup routines for the Adaptive Server Anywhere 7.0 ODBC driver could not be found. Please reinstall the driver",
а затем сообщение
"Component not found in the registry",
хотя драйвер "Adaptive Server Anywhere 7.0" присутствует в списке драйверов в ODBC Data Source Administrator, и наши аппликации благополучни коннектятся к соответствующей БД через указанный DSN;
- database user "INTER70" в БД, соответствующей DSN "ASA70_SOURCE" имеет authorities of DBA.

В чем тут проблема ???

White Owl БокаВ сессии dbisql, в коннекции к database user поименованному как "INTER", который имеет authorities of DBA and Remote DBA (это на всякий случай),Запоминай:
Remote DBA это уникальные юзера которые имеют только одно назначение - через них к базе коннектятся dbremote.exe и dbmlsync.exe. Все.
Юзер с Remote DBA имеет DBA доступ если им зашел один из реплицирующих агентов и не имеет никаких прав если им зашел кто-то другой. Это сделано для того, чтобы можно было запускать репликацию из внешних шедулеров и вынужденно светить в этих шедулерах пароль юзера. При этом реплицирующий агент требует права на изменения всех таблиц участвующих в репликации, поэтому прав у этого юзера должно быть много... Отсюда и компромисс в виде специального права доступа 'Remote DBA'.ОК,
я добавил привелегии "Remote DBA" to database user "INTER" уже после того как пробовал проделать описанные операции, когда user "INTER" имел только привелегии "DBA". Результат был точно такой же.

White Owl, большое спасибо за помощь !

Получилось очень хорошо и в embeded варианте в коде Power Builder.
В связи с успехами, у меня появились следующие три вопроса:

1.) Кроме dbodbc7.dll, dbcon7.dll, dblgen7.dll и dbeng10.exe, для работы с REMOTE SSERVERS and EXISTING TABLES какие еще DLLs необходимы в embeded варианте ?

В подразделе Book Online SQL Anywhere® Server - Programming -> Deploying Databases and Applications -> Deploying embedded database applications перечислены следующие:
- Message Agent dbremote.exe;
- Database tools library dbtool10.dll, libdbtools10.so, libdbtasks10.so;
- Encryption/decryption module dbencod10.dll, libdbencod10_r.so;
- Language resource library dblg[en]10.dll, dblg[en]10.res;
- VIM message link library 1 dbvim10.dll, SMTP message link library 1, dbsmtp10.dll;
- FILE message link library 1 dbfile10.dll, libdbfile10.so;
- FTP message link library 1 dbftp10.dll, MAPI message link library 1, dbmapi10.dll;
- Interface Library dblib10.dll.

На опыте проверить, что конкретно необходимо, мне пока не удалось, потому что я тестировал пока на компьютере, на котором установлена полная версия ASA 10.0.

2.) Moжно ли ASA Remote SQL использовать для переноса данных из ASA в Oracle, из АСА в Microsoft SQL Server, а также в обратном направлении ?
И если да, то какие DLLs для этого необходимы ?

3.) Moжно ли ASA Remote SQL использовать для переноса данных из Oracle,в Microsoft SQL Server и в обратном направлении ?
И если да, то какие DLLs для этого необходимы ?

White OwlЕсли имелись в виду прокси-таблицы, то да - из ASA ты можешь подключиться к абсолютно любой БД, лишь бы у тебя был для нее работающий ODBC драйвер. Если в качестве "чужой" базы выступает другая ASA база, то да dbodbcX.dll, dbconX.dll и dblgenX.dll действительно будет достаточно. Если я правильно понял, то прокси-таблицы это те которые создаются путем "CREATE EXISTING TABLE ..." после создания Remote Server ("CREATE SERVER ...") и обеспечивается коннект к определенному database user-у на нем ("CREATE EXTERNLOGIN ...").
Если так, то да - это все, что нам нужно, причем для наших END-users только в embeded режиме.
Правильно ли я понял, что dbodbcX.dll, dbconX.dll и dblgenX.dll достаточно для такой работы ?
И более того dbengX.exe в этом случае вообще не нужен ?

White OwlЕсли же вопрос был про систему репликации данных SQL Remote, то нет. Она прекрасно работает между двумя ASA базами, но реплицировать данные с базами других типов не умеет. Зато можно взять Mobilink - он посложнее в настройке и администрировании, зато он может использовать базы других типов в качестве консолидированой, удаленные базы все равно должны быть ASA. Нет репликации нам пока не нужны, но использование прокси-таблиц для перекачивания данных из ASA в Oracle, MSSQL и обратно нужно. Пригодилось бы и возможность использования ASA прокси-таблиц, κак промежуточных для перекачки данных из Oracle в MSSQL и обратно.
Правильно ли я понял, что для обеспечения такой возможности в embeded режиме на клиент-компьютере достаточно иметь следующее:
- от ASA - dbodbcX.dll, dbconX.dll и dblgenX.dll ;
- οτ Оracle и MSSQL - установленные клиенты с соответствующими ODBC драйверами ?

White Owl БокаЕсли так, то да - это все, что нам нужно, причем для наших END-users только в embeded режиме.так.... Кажется, ты не понимаешь что такое этот самый embedded режим :)
ASA может работать как нормальный сервер баз данных - на одном большом компьютере запускается сервер с базой, а пользователи (клиенты) подключаются к этому серверу по сети (по локальной или через интернет). А еще ASA может работать как локальная база для одного единственного пользователя - тогда она (обычно) запускается автоматически когда запускается пользовательское приложение (например на PowerBuilder) и автоматически выключается когда пользователь закрывает свое приложение. Вот этот второй вариант работы и называется 'embedded'.
До тех пор, пока у тебя в офисе всего один компьютер, и только один пользователь который должен работать с базой данных - режим встроенной БД (embedded=встроенный) очень удобен. Но как только у тебя появляется необходимость подключить к этой базе второй компьютер, то сразу требуется переводить базу в сетевой режим.

"Так..." номер два: начинай все же думать в терминах сервера и клиента. У тебя всегда будет сервер и один или несколько клиентов. Сервер ждет когда к нему подключаться, клиент инициирует подключение.
Если ты связываешь две базы напрямую, то одна из них становится сервером, другая клиентом. Они могут быть на одном и том же компе, или на двух разных. Но они все равно будут сервер и клиент. Та база в которой ты создаешь свои прокси-таблицы это клиент. Та база к которой ты подключаешься - это сервер.
ODBC драйвер нужен клиенту, серверу он нафиг не нужен, но клиент без него не сможет никуда подключиться.Именно это я и имел в виду под режимом embedded и именно на клиент-компьютере. Наша аппликация в качестве серверов использует либо Oracle либо MSSQL, а каждая из баз данных ASA используются только на одном компьютере и только одним пользователем:
- во-первых в качестве repository для серверной БД;
- во-вторых, для проведения апгрэйда баз данных на Oracle или MSSQL в соответствии с апгрэйдом аппликации;
- в-третьих, для передачи информации из компании-контрактора в компанию-субконтрактора, и наоборот, в том случае, когда эти компании пользуются разными серверами.

White Owl БокаПравильно ли я понял, что dbodbcX.dll, dbconX.dll и dblgenX.dll достаточно для такой работы ?
И более того dbengX.exe в этом случае вообще не нужен ? Комп 1: На нем стоит ASA база и он играет роль сервера. Серверные функции выполняет dbsrvX.exe.
Koмп 2: Играет роль клиента. На него ставится интерфейсные драйвера (ODBC например) и клиентская программа. Если ты хочешь в качестве клиента использовать вторую ASA базу, то запускаешь на этом втором компе вторую копию dbsrvX.exe (если хочешь чтобы эта база сама была сервером для кого-нибудь) а если не хочешь чтобы к ней кто-либо подключался кроме локального пользователя запускаешь dbengX.exe
Если у тебя всего один комп и обе базы находятся на нем, то обе базы могут быть запущены через dbengX.exe или обе через dbsrvX.exe. Зависит от того, надо тебе чтобы к ним кто-то еще подключался по сети или не надо.Для моего сценария обе базы ASA находятся на одном компе. Судя по тому, что если, подключившись к embeded базе-target, аппликация выполняет команды "CREATE SERVER ..." и "CREATE EXTERNLOGIN ..." для базы-source, то эта база сама поднимается из offline в online.
Правильно ли предположить, что это обеспечивается наличием на компьютере dbengX.exe ?

White Owl Бокаиспользование прокси-таблиц для перекачивания данных из ASA в Oracle, MSSQL и обратно нужно. Пригодилось бы и возможность использования ASA прокси-таблиц, κак промежуточных для перекачки данных из Oracle в MSSQL и обратно.Да, это возможно.Правильно ли предположить, что для осуществления этого сценария со стороны ASA достаточно наличие на клиент-компьютере всё тех же dbodbcX.dll, dbconX.dll и dblgenX.dll ??

White Owl Бокаиспользование прокси-таблиц для перекачивания данных из ASA в Oracle, MSSQL и обратно нужно. Пригодилось бы и возможность использования ASA прокси-таблиц, κак промежуточных для перекачки данных из Oracle в MSSQL и обратно.Да, это возможно.Правильно ли предположить, что для осуществления этого сценария со стороны ASA достаточно наличие на клиент-компьютере всё тех же dbodbcX.dll, dbconX.dll, dblgenX.dll и dbengX.exe ???

Dim2000 БокаПравильно ли предположить, что для осуществления этого сценария со стороны ASA достаточно наличие на клиент-компьютере всё тех же dbodbcX.dll, dbconX.dll, dblgenX.dll и dbengX.exe ???
Нет. Это только ODBC-клиент.А какие ещё компоненты ASA, кроме движка (dbengX.exe) и ODBC драйвера (dbodbcX.dll, dbconX.dll, dblgenX.dll), НЕОБХОДИМЫ И ДОСТАТОЧНЫ для следующих сценариев:
a.) создания и использования в локальной БД ASA прокси-таблиц на реальные таблицы в другой БД ASA, находящейся на том же компьютере ??
b.) создания и использования в локальной БД ASA прокси-таблиц на реальные таблицы БД Oracle или MSSQL серверов ??

Заодно по сценарию b.) попутный вопрос:
- понятно, что через прокси-таблиц, созданные на реальные таблицы, находящиеся в БД Oracle/MSSQL, можно инсертировать данные из этих Oracle/MSSQL БД в реальные таблицы локальной БД ASA;
- но можно ли через прокси-таблицы, созданные на реальные таблицы, находящиеся в БД Oracle/MSSQL, инсертировать данные из локальной БД ASA, где эти прокси-таблицы созданы, в соответствующие реальные таблицы , находящиеся в БД Oracle/MSSQL ???

Ребята, я прошу прощения, но уверенный ответ на вопрос по сценарию a.) из моего предыдущего поста:
какие ещё компоненты ASA, кроме движка (dbengX.exe) и ODBC драйвера (dbodbcX.dll, dbconX.dll, dblgenX.dll), НЕОБХОДИМЫ И ДОСТАТОЧНЫ для создания и использования в локальной БД ASA прокси-таблиц на реальные таблицы в другой БД ASA, находящейся на том же компьютере (??),
- мне очень желательно получить до завтрашнего утра.

Dim2000 БокаА какие ещё компоненты ASA, кроме движка (dbengX.exe)
dbengX.exe - это не движок!!! Посмотри хотя бы на его размер. А что это с точки зрения терминологии ?

Бока- но можно ли через прокси-таблицы, созданные на реальные таблицы, находящиеся в БД Oracle/MSSQL, инсертировать данные из локальной БД ASA, где эти прокси-таблицы созданы, в соответствующие реальные таблицы , находящиеся в БД Oracle/MSSQL ???
Да, при наличии прав.[/quot]Отлично.

pand Бока

А при использование ODBC-шного варианта, достаточно ли для поддержки такого варианта поставить пользователю вместе с БД только Engine, например для ASA 10.0 - это dbeng10.exe, dbodbc10.dll, dblgen10.dll ?

Если можно, то прошу Вас уточнить список DLLs и EXEs, необходимых для реализации использования линкования в ODBC-шном варианте. Дело в том, что Sybase oграничивает для нас тиражирование компонентов ASA своим пользователям, а навязывать им покупку полной версии ASA мы не хотим.

есть такой раздел в хелпе
Applacation Techinques
->Deployment Techinques
описывается какие файлы для чего нужны
-> Chapter 41
-> Deployment database
есть описание что нужно для работы ASAшкиМы до сих пор поставляли только dbeng7.exe, dbodbc7.dll, dblgen7.dll, и этого было достаточно для работы с локальными БД ASA 7.0 в embeded режиме. Вот сейчас переходим на ASA 10.0. Ясно, что необходимо поставлять dbeng10.exe, dbodbc10.dll, dblgen10.dll и желательно dbcon10.dll.

Мне пришла в голову идея использовать технику прокси-таблиц для перекачки таблиц из БД в БД, находящихся на одном компьютере, вместо техники использования PowerBuilder-овских Data Store по следующим причинам:
- техника использования PowerBuilder-овских Data Store более муторная и нудная, чем простая техника использования прокси-таблиц с помощью только SQL комманд. Например можноиспользовать bulk-copy ("SELECT * INTO copy_table FROM proxy_table"), а затем создать primary и foreign keys и индексы ;
- производительность перекачки SQL командами через прокси-таблицы несомненно выше, чем через Data Store.
Именно в связи с этим я и бы хотел знать: нужно ли использовать ещё какие-либо компоненты (кроме вышеуказанных DLLs и EXE) для работы с прокси-таблицами в embeded режиме ?
Я конечно это проверю на компьютере, на котром не установлены продукты Sybase, но думал, что, возможно, кто-то из участников форума уже об этом знает точно.

pandа можно я еще ложку дегтя капну
каким образом Sybase ограничивает Вас в тиражировании компонентов ASA ?У нас есть с Sybase специальное соглашение, согласно которому, кроме Runtime Engine, разрешенного к распространению в соответствии с лицензией, которая идет "роялти фри" с PowerBuilder, мы имеем право поставлять Database Engine и ODBC драйвер для каждой версии ASA, входящей в очередную версию PowerBuilder Enterprise (в обсуждаемом случае это PB 11 и ASA 10).
Если же для работы с прокси-твблицами необходимы еще какие-то компоненты, то мы должны будем обновить соглашение. Но желательно знать минимально-некобходимый состав таких компонент.

pand- по партнерской программе вроде особых ограничений нет ( только АСАшку покупать для клиенту надо )Что означает "покупать АСАшку" ?
Мы как раз стремимся и сами лишнего не покупать и пользователей не вынуждать это делать.

Ещё один "ЗА" в пользу использования прокси-таблиц для перекачки по сравнению с Data Store - это то, что blobs в PB нужно обрабатывать с помощью отдельной от Data Store техники, что занудняет код и ухудшает производительность перекачки.

pand Бока
Мне пришла в голову идея использовать технику прокси-таблиц для перекачки таблиц из БД в БД, находящихся на одном компьютере, вместо техники использования PowerBuilder-овских Data Store

наверное вместо Data Store следует читать PipeLine ?Я думаю, что в основе разработки PipeLine скорее всего лежит техника Data Store. Я же имел в виду в коде PB заполнение Data Store в source-транзакции, а затем update таблицы, через заполненное Data Store. Я эту технику плохо знаю, и с блобами неохота отдельно возиться, поэтому мне гораздо больше понравилась техника использования для таких целей прокси-таблиц.

pand Бока
Я конечно это проверю на компьютере, на котором не установлены продукты Sybase, но думал, что, возможно, кто-то из участников форума уже об этом знает точно.

Хелп к билдеру об этом точно знает :) нужно его только правильно спроситьПопробую, может подскажете как правильно спросить ?

pand Бока
У нас есть с Sybase специальное соглашение, согласно которому, кроме Runtime Engine, разрешенного к распространению в соответствии с лицензией, которая идет "роялти фри" с PowerBuilder, мы имеем право поставлять Database Engine и ODBC драйвер для каждой версии ASA, входящей в очередную версию PowerBuilder Enterprise (в обсуждаемом случае это PB 11 и ASA 10).
........
Что означает "покупать АСАшку" ?
Мы как раз стремимся и сами лишнего не покупать и пользователей не вынуждать это делать.

а можно с Вами в привате пообщеться поподробнее на эту тему. Может я как то не правильно понимаю партнерскую программу ?
Стремление похвальное и я к томуже стремлюсь.Пожалуйста, но я пока не понял как на этом форуме организован приват.

В результате эксперементальной проверки exe моей программы с использование прокси-таблиц на чистом компе выяснилось, что необходимо наличие следующих DLLs :
dbserv10.dll
dbctrs10.dll
dbcon10.dll
dbodbc10.dll
dblgen10.dll
dbicu10.dll
dbicudt10.dll
Получилось так, что dbeng10.exe и dbcon7.dll я положил как бы по умолчанию до начала проверки, поэтому о их необходимости я точно утверждать не могу. Хотя dbcon7.dll, видимо, необходим для создания DSN в ODBC администраторе.

Кроме того выяснилось, что для работы с БД ASA 7.0 мы поставляем конечным пользователям следующиее компоненты:
dbeng7.exe
rteng7.exe
dbserv7.dll
dbctrs7.dll
dbcon7.dll
dbodbc10.dll
dblgen10.dll

Поскольку DLLs, соответствующих по именам dbicu10.dll и dbicudt10.dll, ни в директории WIN32 версии 7.0 ни в директории WIN32 версии 9.0, я не нашёл, то делаю вывод, что это что-то новое для ASA 10.0, но не связанное с прокси-таблицами, поскольку прокси-таблицы использовались и в предыдущих версиях.

В предыдущем моём посте есть неточности в наименованиях DLLs, поэтому я решил уточнить текст.

В результате эксперементальной проверки exe моей программы с использование прокси-таблиц на чистом компе выяснилось, что необходимо наличие следующих DLLs :
dbserv10.dll
dbctrs10.dll
dbcon10.dll
dbodbc10.dll
dblgen10.dll
dbicu10.dll
dbicudt10.dll
Получилось так, что dbeng10.exe и dbcon10.dll я положил как бы по умолчанию до начала проверки, поэтому о их необходимости я точно утверждать не могу. Хотя dbcon7.dll, видимо, необходим для создания DSN в ODBC администраторе.

Кроме того выяснилось, что для работы с БД ASA 7.0 мы поставляем конечным пользователям следующиее компоненты:
dbeng7.exe
rteng7.exe
dbserv7.dll
dbctrs7.dll
dbcon7.dll
dbodbc7.dll
dblgen7.dll

Поскольку DLLs, соответствующих по именам dbicu10.dll и dbicudt10.dll, ни в директории WIN32 версии 7.0 ни в директории WIN32 версии 9.0, я не нашёл, то делаю вывод, что это что-то новое для ASA 10.0, но не связанное с прокси-таблицами, поскольку прокси-таблицы использовались и в предыдущих версиях.

Кроме того хотелось бы отметить, что коннектироваться из ASA 10 к ASA 7 и наоборот ни через Sybase Central ни в ODBC администраторе (тест коннекции) мне не удалось.
В обоих случаях дает сообщение "specified database is invalid".
Правда через ODBC администратор я проверял только в одну сторону - пытался создать DSN для БД ASA 10 c помощью ODBC драйвера ASA 7.

Вот с ASA 9 на ASA 7 коннекция работает, в обратную сторону не проверял.

pandЕще раз просьба - напиши pand {AT} ukr{dot}netПослал свой адрес.

White OwlА вот подключаться можно при помощи драйвера любой версии к базе любой версии. Если ты делаешь DSN на основе драйвера из ASA7, ты можешь подключаться к любому из ASA серверов за все время жизни ASA. Тоже самое и с драйверами из SA10.Дело было так:
- на компьютере, на котором находятся только поставляемые нами и перечисленные мной выше компоненты ASA 7, я положил базу, сделанную в ASA 10;
- затем в ODBC администраторе создал DSN на этe базу, используя драйвер ASA 7;
- затем при попытке сделать Test Connection в окне ODBC администратора я получил сообщение "specified database is invalid" или что-то в этом роде.

Теперь обьясню в чём был смысл данного теста:
- пользователь работает в Oracle в русской среде и использует спец-символы (none-ASCII code) для обозначения едениц измерения (типа градус и т.п.);
- этот пользователь переносит часть его БД вместе с единицами измерения в ASA 7 БД из Oracle;
- в ASA 7 мы поставляем БД только с Western European collation и charset, поэтом в результате трансфера некоторые единицы измерения выглядят дефектными;
- в ASA 7 нет возможности использовать unicode, только национальные collation и charset;
- в ASA 10 БД мы перешли на использование UTF8BIN и хотели попробовать использовать такую БД для трансфера данных у данного пользователя;
- но загвоздка в том, что в той версии нашего продукта, которую использует данный пользователь, мы не имее права поставлять ни одного DLL или EXE из ASA 10.
Вот поэтому то я и производил такой тест.

Возник вопрос: в связи с контексом вышеописанной проблемы, может ли помочь использование в качестве значения параметра "Charset" в DSN, построенном для target ASA 7 БД (с Western European collation и charset), подходящее для русского языка значение (например "cp855" или "cp866") при трансфере едениц измерения из Oracle source БД в русской среде ("NLS=RUSSIAN_CIS.CLMSWIN1252") ???

Точно известно, что на русско-ориентированном клиент-компьютере спец-символы из Oracle БД на сервере, имеющей unicode charset, смотрятся правильно, но после того как они перекачиваются на этом компьютере в нашу ASA 7 БД с латинским charset, поставленную на этом же русско-ориентированном компьютере, символы из этой ASA 7 БД смотрятся уже дефектными.

Так для правильного трансфера из unicode Oracle БД в латино-ориентированную ASA 7 БД, находящуюся на русско-ориентированном клиент-компьютере в DSN для этой латино-ориентированной ASA 7 БД нужно пробовать значения charset, ориентированные на латинницу, или на кирилицу ???

П.С.: Линки и прокси-таблицы я начал использовать только сейчас для апгрэйда нашего продукта в последнюю его версию с одновременным апгрэйдом, поставляемых нами ASA БД в версию 10.0.
А в той версии нашего продукта, которая используется в описанном проблематическом случае, трансфер производится в PowerBuilder-е путем использования DataStore в двух параллельных транзакциях, одна из которых открыта для исходной Oracle БД, а другая для принимающей ASA 7 БД. Причем коннекция к Oracle осуществляется через native драйвер PowerBuilder-а для Oracle.
Короче ODBC драйвер для Oracle в данном случае не при делах.