Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
18.04.2006, 18:30
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
Мучаемся по немногу с мобиликом, и возникают терзающие душу вечные вопросы - ......"а чё будет если схему поменять?"... хотя к сожалению двигает этим настроением не любопытство а в необходимость: программу дорабатываем, схему базы тоже и так еще не известно сколько протянет, а запускать репликацию нужно уже. Например при синхронизации модели и базы (reverse engeniring) в PowerDesigner он мотёрыё скрипты мутит. Создает временные таблицы..удаляет внешние ключи.. , затем сами таблицы, создаёт новыё таблицы, копирует в них обратно информацию с временных таблиц, возвращает обратно констрейны, тригеры, процедуры и то всё и то всё.... Ведь нельзя ничего такого сделать пока не удалить временно таблицы из публикации, не добавишь колонку, не удалишь внешний ключ.... Вопрос , что же будет мобилинком и его логом транзакций если удалить таблицу из публикаци создать новую с тем же именем и вновь включить туда же обратно, и если таких таблиц много...? Он мне не выругается шестнадцатиричным кодом или ещё чем нибудь? Кто нибудь страдал таким? Тоесть имел дело с работающей схемой репликации и менял схему баз? Проблемы были при таком? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.04.2006, 19:06
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
в приложенном файле вариант решения, по примеру которого я делал в своей базе, проверял в тестовом режиме, все работает как надо, но на рабочих базах воспользоваться пока не приходилось. Смысл решения в том, что когда заканчивается сеанс синхронизации, вызывается процедура sp_hook_dbmlsync_schema_upgrade, в которую можно поместить свой обработчик события, который должен заниматься модификацией структуры базы. То есть в этой процедуре можно удалять и содавать таблицы, внешние ключи, тригеры и т.п., так как база в этот момент полностью сихронизирована. В данном примере этот обработчик проверяет наличие записей в спец. таблице, которая содержит sql команды модификации структуры базы (содержимое таблицы синхронизируется в этом же сеансе). Если записи есть, команды выполняются. Скрипт модификации обязательно содержит удаление и восстановление публикаций, в которых участвуют модифицируемые таблицы, а также содание подписки с новым номером версии. Если все прошло нормально, то следующий сеанс начнется с новой версией скриптов синхронизации, с того самого места на котором остановились в прошлый сеанс. Проблема может быть тогда, когда база модифицируется так, что невозможно поддерживать старые и новые версии скриптов, тогда придется организационно применять модификацию методом "все вдруг" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2006, 16:25
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
Пока спасибо!. Вам есть чему позавидовать если применять модификации неприходилось. Временно немогу дополнительно ничего спросить, но знаю что эта тема для меня скоро не закроется. Применять модификаци, мне представляэться действительно трудно даже в SQLRemote.. темболее если учитывать то - что не со всеми отделениями может быть налажена связь одновременно, и уловить момент когда вся система синхроизирована полностью чтобы приментить SQLPassthrou трудно. В Mobilink'e есть скрипты... что даёт некое ощущение контролируемости.... но мне кажется затраты связанные с проведением модификации схем будут ужасными (неисключено что будут и жертвы...).. Если у кого есть сколько бы там не было опыта с этакими проблемами .. по возможности откликнитесь ... нельзя ведь так человека одного оставлять.. сам на сам с этими монстрами....кто бы они небыли Mobilink или Remot'ы там всякие.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2006, 16:50
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
А зачем это в SQLRemote "улавливать моменты одновременной синхронизации" ? Мы ложим операторы изменения схемы в PASSTHROUGH по подписчикам, они наложатся на консолидированную БД и поедут вместе с данными по подписчикам. Абсолютно здесь не вижу никаких сложностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2006, 17:57
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
Но разве система на этот момент не должна быть полностью синхронизирована по старой схеме. Если мы изменяэм таблицу в консолидированной базе, допустим добавляем колонку, потом заполняем, делем eё not null .. всё это конечно-же вставляем в PASSTHROUGH и отправляем клиетам тоже.... Но как тогда изменения в клиентах по строй схеме применятся в консолидированной если она уже будет изменена? Я это спрашиваю потому что практики с репликациями вообще не имею. Всё что у меня есть - это 3 недели ненапрягающего учения SQLRemote некольких попыток и експериментов, потому как бросил это дело из-за того что для SQLRemote в ASE не очень гибкая система распределения данных (только по столбцу подписки), а денормализировать схему базы уже никто не будет, и с триггерами как-то трудно будет обращатся. Затем решили показнакомится с Mobilink, который всех впечатлил своими разнообразиями - ну типа гибкостью и то всё. Затем мы заглядываем в будущее... и что-то не верится что оно будеть так тривиально как демоскрипты в онлайн документации. Да и не скрипты нас волнуют.. их мы уже почти накрябали .. и не сложно было, не такая уж проблема большая, деже если на их отладку уйдут недели.... Самое страшное для нас, я повторюсь, это изменения структуры баз данных .. Ну и на счёт PASSTHROUGH скажите пожалуйста Ваше мнение, я действительно в этом деле не очень.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.04.2006, 19:14
|
|||
|---|---|---|---|
Mobilink - проблемы часто бывают при изменении в схеме? |
|||
|
#18+
Я честно говоря сделал немножко хитрее - не стал связываться с PASSTHROUGH, хотя бы по той причине, что невозможно проконтролировать его выполнение на удаленных подписчиках и сделал следующее: 1. Есть служебная табличка удаленных скриптов с структурой ВремяСкрипта, Сервер, Скрипт, Статус, ТекстОшибки 2. В нее вставляется все, что необходимо выполнить на удаленных и консолидированной БД как ручками в администраторской консоли, так и другими обьектами БД. 3. Табличка участвует в репликации 3. На табличку висит триггер, который в случае добавления, изменения или удаления записи с кодом сервера, соответствующим текущему серверу, вызывает специальное событие 4. Событие пытается заблокировать табличку удаленных скриптов, что соотествующе приводит к тому, что пока репликация продолжает ввод скриптов в таблицу, событие висит и ждет. 5. Далее событие по возрастанию времени создания скриптов выстраивает их в очередь и через динамический SQL начинает их выполнять 6. После успешного выполнения скрипта, в таблицу на этот скрипт выставляется успешный статус выполнения скрипта, в случае неудачного выполнения скрипта ошибочный статус с текстом полученной ошибки. В случае ошибки, событие прерывает работу и больше при вызове не будет обрабатывать скрипты, пока не будет изменен статус ошибочного скрипта. 7. Соотвествующе изменения статусов реплицируются обратно в консолидированную БД, где админы выдят, кто и что обновил и на чем споткнулся. 8. В случае обнаружения ошибки, администратор может исправить ошибку в скрипте для подписчика, поставить статусы игнорировать, успешно выполнен или просто его удалить. Любое действие администратора соотвествующе будет реплицировано обратно на подписчика и там событие продолжит свою работу по выполнению обработки полученных скриптов. Соотвествующе через данную схему работы я просто могу создать на консолидированном сервере новое поле: Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. P.S. Ну а для тех клиентов, у которых все филиалы имеют хоть какой то интернет с 80-ым портом хотя бы на уровне модема, я даже еще легче делаю - у меня на ASA с использованием XML веб-сервисов и веб-интерфеса написана собственная достаточно мощная система синхронизации версий БД и клиентских частей, с претензией на нулевое администрирование для удаленных клиентов, по функционалу на много превосходящая PASSTHROUGH и мою вышеописанную систему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=55&mobile=1&tid=2012899]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
72ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
| others: | 232ms |
| total: | 392ms |

| 0 / 0 |
