Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
...Не было у бабы забот, купила баба порося... Дано: работающая репликация через SQL Remote. Требуется сменить ее на Mobilink. Как это сделать наименее безболезненно? Мне почему-то не очень улыбается ручками прописывать сотни скриптов на upload/download... Должен же там быть какой-нибудь "скриптосоздаватель"? Чтоб дать ему имя публикации и он бы мне нарисовал все необходимые скрипты... --- http://www.rusug.ru] Портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 21:05 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
опция - za генерит 4 основных активных скрипта, upload_insert upload_update upload_delete download_cursor или можно с помощью - ze сгенерить 4 основных тестовых скрипта example_upload_insert example_upload_update example_upload_delete example_download_cursor Для генерации скриптов нужна опция SendColumnNames=ON ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 21:14 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
morisопция - za генерит 4 основных активных скрипта, О! Слона то я и не приметил. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 21:23 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
хм... еще вопрос. А как повторить логику subscribe by в Mobilink? Что писать в where? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 22:12 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White Owlхм... еще вопрос. А как повторить логику subscribe by в Mobilink? Что писать в where? У вас скрипт будет выполняться на стороне консолидированой базы в скрипт передается username вот к нему и надо привязываться а что прописывать в where уже Вам решать. можно кстати вместо простого select использовать SP. в download_cursor прописываете условие по которому записи попадают в удаленную базу в download_delete_cursor условие по которому записи удаляются из удаленной. Вопрос ради интереса. Чем обосована смена протокола синхронизации.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2007, 23:46 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
pandУ вас скрипт будет выполняться на стороне консолидированой базы в скрипт передается username вот к нему и надо привязываться а что прописывать в where уже Вам решать. можно кстати вместо простого select использовать SP. в download_cursor прописываете условие по которому записи попадают в удаленную базу в download_delete_cursor условие по которому записи удаляются из удаленной.А пример можно? pandВопрос ради интереса. Чем обосована смена протокола синхронизации.?Теоретически, mobilink более устойчив к падениям базы. SQLRemote привязана к логу, а у Mobilink вроде-бы такой привязки нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2007, 00:07 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White Owl pandв download_cursor прописываете условие по которому записи попадают в удаленную базу в download_delete_cursor условие по которому записи удаляются из удаленной.А пример можно?Уже не нужно, сам сообразил :) Зато возник другой вопрос. Если в реплицируемой таблице нету поля с default timestamp. И мы пишем скрипт так как предлагается в BOL: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2007, 00:37 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White Owl Дано: работающая репликация через SQL Remote. Требуется сменить ее на Mobilink. Как это сделать наименее безболезненно? Вопрос из любопытства: а зачем это понадобилось и что даст? Сам до сих пор еще ни разу мобилинк не юзал и особо не вникал. А вдруг оно и мне сгодится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2007, 09:45 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
если будет какой-нить КПК, то на нем будет работать только mobilink? или имеется аналогичный sql/dbremote? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2007, 13:15 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
авторSQLRemote привязана к логу, а у Mobilink вроде-бы такой привязки нету. Co стороны сервера первичных данных (remote DB), Mobilink будет работать по логу. На консолидированной же БД, которой может быть либо ASE, либо Oracle, или MSSQL, Mobilink при инкрементальная синхронизация будет работать на основе тригеров. Если инкрементальная синхронизация не рализована (по дефолту), то будет snapshot с консолидированной БД на remote DB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2007, 17:15 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
Александр ГoлдунВопрос из любопытства: а зачем это понадобилось и что даст? Сам до сих пор еще ни разу мобилинк не юзал и особо не вникал. А вдруг оно и мне сгодится? Зачем понадобилось... ой... Большой Босс решил образование получить, пригласил консультанта из iAnywhere и тот ему понарассказывал кучу баек про устарелость SQL Remote и прогрессивность Mobilink. А я как DBA, теперь отдуваюсь. А насчет сгодится или нет вопрос очень даже сложный. Минусы Mobilink на которые я уже успел напороться: - Для того чтобы запустить репликацию надо для каждой реплицируемой таблицы написать как минимум два скрипта. Один будет делать выборку строк в базе отправителе, второй записывать полученые строки в базу получатель. Это для репликации простых insert'ов. Потом еще желательно скрипты для update и delete... В общем объем работы по первоначальной настройке, особенно когда еще плаваешь во всем этом - просто ой. - Для инкрементальной репликации скрипт делающий выборку строк на отсылку ориентируется на поле с 'default timestamp'. Если такого поля в таблице нет, то для этой таблицы возможна только полная пересылка всех строк. - Не смотря на то что скрипты работают на основе данных, лог тоже используется. Как я понял, Mobilink вытаскивает из лога список таблиц которые были обновлены с момента последнего сеанса связи. То есть главный заявляемый минус SQL Remote - жесткая завязаность на лог Mobilink'ом не исправляется... - Если посылающая база между последним бэкапом и смертью успела провести несколько успешных сеансов репликации, то никакого волшебного отката на момент бэкапа в базе получателе не произойдет. Теоретически можно будет подправить временно все скрипты чтобы они игнорировали last_modified поле и переслать полный snapshot. Но мне почему-то кажется, что объем ручной работы по переписыванию скриптов туда-обратно будет сравним по объему работы при повторной синхронизации баз на SQL Remote. Если пользователи Mobilink считают что я где-то наврал - с удовольствием выслушаю ваши поправки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.05.2007, 02:05 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White OwlЗачем понадобилось... ой... Большой Босс решил образование получить, пригласил консультанта из iAnywhere и тот ему понарассказывал кучу баек про устарелость SQL Remote и прогрессивность Mobilink. А я как DBA, теперь отдуваюсь. [/qout] "Железный аргумент" ну да Бог с ним. [quot White Owl] 1. - Для того чтобы запустить репликацию надо для каждой реплицируемой таблицы написать как 2. - Не смотря на то что скрипты работают на основе данных, лог тоже используется. Как я понял, Mobilink вытаскивает из лога список таблиц которые были обновлены с момента последнего сеанса 3. - Если посылающая база между последним бэкапом и смертью успела провести несколько Если пользователи Mobilink считают что я где-то наврал - с удовольствием выслушаю ваши поправки. 1. Желательно 4 скрипта download_cursor, upload_insert,upload_update,upload_delete ( для полноценной репликации в две стороны это минимум) 2. log используется только в удаленной базе в консолидированной выборка происходит на основании запроса в dowload - скрипте. Инкрементальность по timestamp это ( по моему ) для уменьшения объема передаваемых данных. Еще дополнительно нужно корректно обрабатывать удаление данных в консолидированной базе. Ведь что нужно удалять в remote базе отправляется запросом и откуда-то нужно выбирать что удалить. 3. непонял про что идет речь. На мой взгляд использование mobilink имеет смысл если - консолидированая базе не ASA - структура таблиц в консолидированой и удаленной не совпадают или при синхронизации необходима мудреная обработка данных. проскакивал вопрос про кпк если на кпк используется ultralite то только mobilink если полноценная asa то можно использовать и remote и mobilink вообще то mobilink - штука интересная и если ее правильно использовать и главное по теме то можно наворотить неслабую систему репликации. Вот у меня возможно и не сюда вопрос но может кто сталкивался с системами репликации у oracle и MSSQL интересно как реализовано у них . PS Если фразы не связные извините - выздаравливаю после дня ХАИ и 10 окончания егоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2007, 00:38 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White OwlМинусы Mobilink на которые я уже успел напороться: - Для того чтобы запустить репликацию надо для каждой реплицируемой таблицы написать как минимум два скрипта. Один будет делать выборку строк в базе отправителе, второй записывать полученые строки в базу получатель. Это для репликации простых insert'ов. Потом еще желательно скрипты для update и delete... В общем объем работы по первоначальной настройке, особенно когда еще плаваешь во всем этом - просто ой. Неверное утверждение. Для того, чтобы данные просто ездили в одну сторону от консолидированной базы к удаленной достаточно одного скрипта download_cursor. Если необходимо удалять записи в удаленной базе, ктороые помечены в консолидированной на удаление - это делается через download_delete_cursor. Скрипты upload_delete, upload_insert и upload_update необходимы для обратного действия - отправки изменений из удаленной в консолидированную базу. White Owl - Для инкрементальной репликации скрипт делающий выборку строк на отсылку ориентируется на поле с 'default timestamp'. Если такого поля в таблице нет, то для этой таблицы возможна только полная пересылка всех строк. Почти так и есть. Просто и в том, ив другом случае никто не мешает накладывать дополнительные5 условия на выборку кроме условия на пользователя или времени изменения записи. White Owl - Не смотря на то что скрипты работают на основе данных, лог тоже используется. Как я понял, Mobilink вытаскивает из лога список таблиц которые были обновлены с момента последнего сеанса связи. То есть главный заявляемый минус SQL Remote - жесткая завязаность на лог Mobilink'ом не исправляется... Причем тут лог? Консолидированной базой может быть не только Sybase (хотя и у других баз тоже лог есть). В общем-то Mobilink-у главное чтобы скрипты соответствовали выбранной консолидированной базе и в этой базе были все нужные системные таблицы и настройки. White Owl - Если посылающая база между последним бэкапом и смертью успела провести несколько успешных сеансов репликации, то никакого волшебного отката на момент бэкапа в базе получателе не произойдет. Теоретически можно будет подправить временно все скрипты чтобы они игнорировали last_modified поле и переслать полный snapshot. Но мне почему-то кажется, что объем ручной работы по переписыванию скриптов туда-обратно будет сравним по объему работы при повторной синхронизации баз на SQL Remote. Скрипты трогать необязательно. В удаленном приложении, которое и работает с удаленной же базой вызвать метод сброса БД, и при очереднйо синхронизации с консолидированнйо базой получите на удаленную базу снова целиком snapshot. White Owl Если пользователи Mobilink считают что я где-то наврал - с удовольствием выслушаю ваши поправки. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2007, 01:14 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
Анатолий ИвановСкрипты трогать необязательно. В удаленном приложении, которое и работает с удаленной же базой вызвать метод сброса БД, и при очереднйо синхронизации с консолидированнйо базой получите на удаленную базу снова целиком snapshot.Ээээ... что такое "вызвать метод сброса БД"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2007, 01:48 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
о накатывании изменений в БД, поле добавить, или удалить (сложнее) PASSTHROUGH FOR не работает с ML, см. sp_hook_dbmlsync_schema_upgrade нужно будет писать новые версии скриптов и пр. в качестве замены CURRENT REMOTE USER IS NULL можно использовать LOCATE(connection_property('Name'), 'DBMLsync') <> 0 или завести переменную и туда это скинуть Я сделал таблицу в которой перечислены все таблицы участвующие в синхронизации, всякие настройки, типы таблиц, версии скриптов и пр. Написана процедура которая по этим данным строит скрипты :) по мне так лучше, когда изначально на ML ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2007, 12:30 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White OwlЭэээ... что такое "вызвать метод сброса БД"? Ну, я не совсем удачно выразился. Есть как минимум два способа: 1. Удаление базы и создание заново с той же схемой и получение заново всех данных. (см. метод DropDatabase класса ULDatabaseManager например в Ultralite .NET) 2. Сброс значения времени последней синхронизации (см. метод ResetLastDownloadTime класса ULConnection) и получение заново всех данных из консолидированной БД. Возможно еще удастся что-то сделать утилитами работы с Ultralite-базой (мне просто не понадобилось), в случае если есть прямой доступ к удаленной Ultralite-базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2007, 21:59 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
технология Mobilink хорошо описана в книжке Breck Carter - SQL Anywhere Studio 9 Developer's Guide. Чтобы сократить объем ручной работы рекомендую посмотреть Powerdesigner 11,12 - Information Liquidity Model. Триального периода будет достаточно чтобы сгенерировать все необходимые скрипты для синхронизации и для возможных изменений в консолидированной и удаленных базах данных. Что касается PASSTHROUGH - В интернете где то было описание способа реализации. Создается табличка куда вы будете заносить SQL операторы для выполнения на удаленных базах. Эта табличка включается в публикацию. На удаленной базе после завершения синхронизации вызывается хр. процедура sp_hook_dbmlsync_schema_upgrade в которой вы проверяете табличку и по очереди выполняете поступившие SQL команды. Я это у себя делал и все работало нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 14:33 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
да и вот еще сравнение Mobilink и SQLRemote ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 14:54 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
rcryoтехнология Mobilink хорошо описана в книжке Breck Carter - SQL Anywhere Studio 9 Developer's Guide.Cool! Он еще и книжки пишет. Во продуктивный мужик :) Буду смотреть в книжных. rcryoЧто касается PASSTHROUGH - В интернете где то было описание способа реализации. Создается табличка куда вы будете заносить SQL операторы для выполнения на удаленных базах. Эта табличка включается в публикацию. На удаленной базе после завершения синхронизации вызывается хр. процедура sp_hook_dbmlsync_schema_upgrade в которой вы проверяете табличку и по очереди выполняете поступившие SQL команды. Я это у себя делал и все работало нормально.хм... Примерно так? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. А если в консолидированой будет несколько версий скриптов, то надо будет повторить schema_changes/download_cursor для всех версий? Мысль интересная. Буду думать.... Но вот что меня сейчас волнует больше всего, так это заявленое для Mobilink наплевательство на порядок транзакций. А если у меня все таблицы имеют fk связи между собой? Как вы выходите из положения? Не пользуетесь внешними ключами вообще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:16 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White Owl wrote: > Cool! Он еще и книжки пишет. Во продуктивный мужик :) Буду смотреть в > книжных. Да это, собсно, не новость ;)... кстати, она, по-моему, и в электронном виде есть... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 19:02 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
SQL Anywhere Studio 9 Developer\'s Guide Обсуждение изменения схемы БД и пример авторНе пользуетесь внешними ключами вообще? там где это надо можно использовать FK CHECK ON COMMIT option ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 19:57 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
rcryo SQL Anywhere Studio 9 Developer\'s Guide Э? Ссылка не рабочая. rcryoОбсуждение изменения схемы БД и примерТут все-таки обсуждается как сделать синхронизацию стурктуры БД через SQL Remote. А это я и так знаю :) Это я в Mobilink плаваю пока... rcryo авторНе пользуетесь внешними ключами вообще? там где это надо можно использовать FK CHECK ON COMMIT optionнууу.... в принципе, да. Но это ж мне все ключи прийдется переопределять :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 20:25 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
White Owl wrote: > Э? Ссылка не рабочая. У меня качаеццо... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 20:32 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
Пример изменения схемы БД SchemaUpgradeASA.zip ссылка на книжку рабочая, взята из местного FAQ еще кое-что есть на codeexchange авторНо это ж мне все ключи прийдется переопределять :( может и не все, а где это действительно нужно. а думаешь мало придеться остального делать? - global autoincrement для всех суррогатных ключей. - поле last_modified для каждой синхронизирумой таблицы для которой требуется инкрементальная синхронизация - поле deleted для организации логического или отложенного удаления для каждой синхронизирумой таблицы для которой требуется двунаправленная синхронизация - скрипты upload/download, ну ты уже знаешь + скрипты разрешения возможных конфликтных ситуаций - скрипты подготовки удаленных БД (создание публикаций, подписок и т.д.) - еще порекомендовал бы сразу сделать логирование конфликтов и ошибок синхронизации как на сервере так и на удаленных бд в спец. таблицу, чтобы потом не рыться по логам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 00:23 |
|
||
|
переезд с SQL Remote на Mobilink
|
|||
|---|---|---|---|
|
#18+
rcryoа думаешь мало придеться остального делать? Я не думаю. Я уже знаю :) В общем, пока мы эту идею зарубили. В нашей системе мы сами контролируем структуру удаленных баз, и данные идут однонаправленно из удаленных в консолидированую, вплоть до "к чертям консолидированую, но удаленная должна работать". По сравнению SQL Remote, Mobilink не дает никаких плюсов. Кроме одного минуса (хоть и разового, но все же) большой работы по начальной инсталляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 00:44 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=34559419&tid=2012072]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 252ms |
| total: | 398ms |

| 0 / 0 |
