Уважаемые колеги,
подскажите пожалуйста наиболее простой способ (или комбинацию технических приемов) копирования таблиц из исходной БД 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, находящейся на том же компьютере (??),
- мне очень желательно получить до завтрашнего утра.