Изменение словаря, чем грозит.

Программирование на Атлантисе (VIP, FCOM, ARD), FastReport

Модераторы: m0p3e, edward_K, Модераторы

Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Изменение словаря, чем грозит.

Сообщение Vik »

Добрый день. Возникла необходимость добавить в таблицу KatMc свое поле и индекс. Наслышан о том, что такое действие категорически не рекомендуется. В частности, выдержка из документации:

Код: Выделить всё

Категорически не рекомендуется пользователям использовать alter dictionary, т.к. при этом летит КС словаря. Соответственно, становится невозможен контроль соответствия приложения и БД. Отсюда возможны (и были реально) крупные неприятности. Теоретически - вплоть до полной потери БД.
Но тут не написано ничего про добавление нового поля. Кто-нибудь изменял стандартные таблицы, имел после этого проблемы? В общем, кто что посоветует?
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5188
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Re: Изменение словаря, чем грозит.

Сообщение edward_K »

добавление нового поля, индекса, таблицы в автомате изменит контрольную сумму. Для нормальной работы ее нужно сбрасывать в 0.
В теории добавить можно, но только в конец. Тоже касается и индексов. Иначе 100% глюки. Более безопасно добавить свою таблу.
Ну и готовтесь к решению проблем с конвертацией или запуском chkmssql например. Перед этими процессами желательно привести базу в первозданный вид(особенно перед конвертацией, chkmsql лечится и так, но не у всех получается).
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

Спасибо, тогда, наверное, буду искать другой путь.
Sheinina
Местный житель
Сообщения: 366
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Re: Изменение словаря, чем грозит.

Сообщение Sheinina »

Поле и индекс в существующей таблице действительно добавлять не стоит. А вот таблицы добавляла неоднократно и проблем не испытывала. При конвертации просто надо инфу из своих табличек прикопать, после конвертации снова их создать и закачать инфу на место. Контрольная сумма изменяется одним запросом.
Все вышесказанное делала на Первасиве :)
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

Таблицы свои я и сам неоднократно создавал, тут у меня вопросов нет никаких. Меня интересовало лишь, какие проблемы могут быть именно при добавлении поля в стандартную таблицу.
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

В общем, вот что говорят сами разработчики (товарищ cruger):
Модификация словаря

Модификация словаря бывает прикладная - в обновления поставляются скрипты, которые надо запускать, и пользовательская - клиент сам решает, как ему нужно доработать стандартный словарь.

Пользовательская модификация словаря осуществляется простым запуском соответствующих запросов (create table, alter table etc), без оператора alter dictionary и параметра FullSQL. Или, что лучше для дизайнирования, из модуля Support-Консоль управления. При этом контрольная сумма остаётся такой же, какой была до этой модификации, т.е. пользовательские изменения словаря в расчёте контрольной сумме не учитываются. Занулять контрольную сумму словаря не надо.

С помощью пользовательской модификации можно не только создавать и изменять свои таблицы, но и:
- добавлять поля в конец стандартных таблиц;
- добавлять индексы к стандартным таблицам;
- добавлять сегменты индексов стандартных таблиц;
- удалять индексы стандартных таблиц;
- возможно (давно не проверял), удалять сегменты индексов стандартных таблиц.
Другие изменения структуры (полей, индексов) стандартных таблиц невозможны. Однако можно менять ссылочную целостность (как декларативную, так и ограничивающую) - к структуре она не относится.

Что даёт добавление полей, очевидно. Например - отказ от внешних атрибутов-классификаторов, что позволяет более просто и качественно добавлять свою логику. Но это более интересно программистам.

Манипуляции же с индексами более интересны администраторам. С одной стороны на поддержку индексов СУБД тратит определённые ресурсы. Чем больше индексов, тем больше БД, тем медленнее модификация, тем (на блокировочных СУБД) чаще конфликты изменений. С другой стороны - чем больше нужных индексов, тем быстрее поиск, да и сортировка работает.

Неиспользуемые индексы можно удалить (встаёт вопрос, как узнать о неиспользуемом индексе, но это тема для отдельного обсуждения). Используемые индексы можно доработать. Например, удалить неиспользуемые сегменты (тут, очевидно, вопрос тот же, только более сложного уровня). Более интересно - добавить свои сегменты в используемый индекс. Это может дать, например, более быстрый поиск в наложенных ограничениях, или автоматическую сортировку там, где её не предусмотрел разработчик. Наконец, добавление своего индекса часто оправдано при собственных доработках.

Пользовательскую докомпиляцию можно выполнять как из лицензируемых Support-Консоль управления (тут доступно GUI по изменению словаря), Support-SQL, так и из нелицензируемого (но штатно обновляемого!) консольного asql.

Для справки. Ограничения пользовательской докомпиляции не связаны с лицензионными или иными подобными ограничениями. Они связаны лишь с поддержкой корректности функционирования системы. Т.е., если вы хотите разломать свою систему, смело используйте alter dictionary & FullSQL. К сожалению, наши условия абонентского обслуживания несовершенны, и мы в любом случае будем пытаться разобраться в поломанной вами же базе.

Примечание. Известный хинт с занулением контрольной суммы связан с тем, что на Атлантисе 3.?? флаг пользовательского изменения словаря при расчёте контрольной суммы не учитывался. Он взводился, при самом изменении контрольная сумма не рассчитывалась, но при любом пересчёте она съезжала. Эта недоработка давным давно устранена.
Широко применяемая пользователями ошибочная практика alter dictionary & FullSQL связана, очевидно, с тем, что давным давно, когда часто происходила прикладная докомпиляция БД, пользователи, желающие выполнить пользовательскую докомпиляцию, предпочитали изучению документации смотреть исходники прикладной докомпиляции и делать так же, как там, не утруждая себя пониманием того, что же они делают.
Итого: забудьте про зануление контрольных сумм, alter dictionary и FullSQL - это инструменты для настоящих профессионалов (ака прикладные программисты), хехe
Нашел тут
Так что можно добавлять поля все же)
ilshat
Местный житель
Сообщения: 222
Зарегистрирован: 04 июн 2008, 14:35
Откуда: Стерлитамак
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение ilshat »

- это инструменты для настоящих профессионалов (ака прикладные программисты), хехe
Вот это "ХЕХЕ" меня более всего добило. Не пойму до сих пор что это значило? Презрение?
Порог вхождения в нормальный SQL, к примеру, намного ниже, чем в недо-SQL галактический.
А докомпилировать словарь все равно ссыкотно. Пусть уж будут внешние атрибуты, так спокойнее.
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5188
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Re: Изменение словаря, чем грозит.

Сообщение edward_K »

если поля добавлять в конец, то в принципе все работает. Основная проблема - конвертация, нужно проверять изменилась ли таблица, и если да, то приводить сначала в первозданный вид, а после конвертации(лучше даже модифицировать стандартную докомпиляцию словаря) добавлять снова. Удалять индексы или сегменты индекса очень не безопасно.Добавить свой может быть, но тоже в конце. У меня было модифицированно штук 5 стандартныз табл когда-то - и ничего после выработки таких правил окна стали открываться даже с данными :). Основная проблема как галка собирает представление - а там используются не наименования полей, а их номера. Тем более опасно, если есть обращение к таблице в dll (класс таблицы жестко вшивается в код). Также не стоит менять размер и тем более тип стандартных полей.
galover
Местный житель
Сообщения: 794
Зарегистрирован: 16 ноя 2007, 13:52

Re: Изменение словаря, чем грозит.

Сообщение galover »

почему не стОит? А если не шаманить с контрольной суммой, то есть не изменять ее как крюгер-Терсин советует, все равно будут проблемы?
m0p3e
Местный житель
Сообщения: 1386
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва

Re: Изменение словаря, чем грозит.

Сообщение m0p3e »

Если есть необходимость добавлять поля в таблицу и потом по ним желательно иметь индексы, то делал таблицу дубликат. Например к KatMc добавляем таблицу KatMcEx. В нее добавляем поле cKatMc = KatMc.nrec и новые поля. Описываем индексы. Никаких проблем с дальнейшей докомпиляцией. А играя с программными триггерами можно обеспечить и ссылочную целостность.
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

Насчет того, какие могут возникнуть проблемы. У тестовой базы добавил в поле KatMc свое поле. Долго работал, проблем никаких уже и забыл, что поле добавил. А добавил я поле в той базе, с которой компилировал свои ресурсы. И вот в один момент, несколько моих интерфейсов стали выдавать ошибку о несовпадении контрольной суммы интерфейса oObjMc_Obj1 (я его частенько использую). Я подумал, что проблема в том, что изменилось описание - но, как узнал от разработчиков, описание этого интерфейса не менялось с 2006 года. В итоге, убил полдня, прежде, чем вспомнил, что буффер таблицы KatMc в моей базе отличается от оригинального, потому как я добавлял поле. Таким образом, при добавлении своего поля в таблицы, буфферы которых участвуют в качестве типов в объектных интерфейсах, использовать эти объектные интерфейсы становится невозможным или затруднительным.
galover
Местный житель
Сообщения: 794
Зарегистрирован: 16 ноя 2007, 13:52

Re: Изменение словаря, чем грозит.

Сообщение galover »

а как добавлял свое поле? с пересчетом контрольной суммы или без (alter dictionary & FullSQL использовались)?
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

galover писал(а):а как добавлял свое поле? с пересчетом контрольной суммы или без (alter dictionary & FullSQL использовались)?
В данном конкретном примере не важно с пересчетом контрольной суммы это делаешь, или без. Но добавлял без пересчета контрольной суммы, без alter dictionary и без FullSQL. Просто в саппорте добавил поле по f4 на таблице.
galover
Местный житель
Сообщения: 794
Зарегистрирован: 16 ноя 2007, 13:52

Re: Изменение словаря, чем грозит.

Сообщение galover »

Так лучше не делать, нужно подготовить lot и vip-ом прогнать. Есть подозрение, что контрольная сумма как раз и поменялась.
Vik
Местный житель
Сообщения: 370
Зарегистрирован: 28 сен 2006, 15:43
Откуда: Санкт-Петербург
Контактная информация:

Re: Изменение словаря, чем грозит.

Сообщение Vik »

Да какая разница в этом случае? Ошибка будет независимо от того, была пересчитана контрольная сумма словаря или нет. Тут все упирается в то, что изменилась структура таблицы KatMc. И, как следствие, type$KatMc в моем словаре не будет равен type$KatMc в оригинальном словаре. Соответственно, и объектные интерфейсы, использующие буферы таблицы KatMc будут различаться. Глубоко фиолетово, был ли при этом использован alter dictionary иди FullSQL при изменении таблицы KatMc. Разве не так?
Ответить