Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
23.05.2016, 11:20
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
Добрый день, Есть поле NUMERIC(15, 2), надо поменять на NUMERIC(15, 4). ALTER TABLE не проходит -- ругается на потерю точности. Реально, в таблице нет данных, которые бы исказились при таком изменении типа. UPDATE RDB$FIELDS проходит и позволяет выполнить указанную задачу. Обновление системной таблицы выполняется в единственном подключении к БД, после чего транзакция комитится, а подключение закрывается. Вопрос: после операции UPDATE RDB$FIELDS надо ли сразу делать бэкап-рестор или можно продолжать работать с базой. Грозит ли это чем-нибудь впоследствии? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 11:20
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
Сервер 2.5.6. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 11:35
|
|||
---|---|---|---|
Последствия редактирования RDB$ таблиц |
|||
#18+
Если в RDB$FORMATS появилась новая запись (после коммита апдейта RDB$FIELDS), то может и пронесёт :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 11:54
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
Глупый вопрос. Если NUMERIC хранится как целое и только при выдаче результата сервер проставляет десятичую точку в соответствии с установленными параметрами типа, то как тогда получается, что при изменении типа с NUMERIC(15,2) на NUMERIC(15,4) мы получаем правильный результат? Т.е. было 123.45 стало 123.4500, а не 1.2345. Там все-таки проходит апдейт всем значениями? Или как это работает? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 12:23
|
|||
---|---|---|---|
Последствия редактирования RDB$ таблиц |
|||
#18+
sysdba22, движок запоминает в rdb$formats блоб с описанием метаданных таблицы и делает это при каждом изменении оных. В каждой записи есть номер формата (фактически - номер версии метаданных таблицы). В rdb$relations есть номер текущего формата. Поэтому, прочитав запись с номером формата N и, зная текущий формат M, можно на лету преобразовать старый формат в новый. И никаких апдейтов ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 12:29
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
о, а то я 15 лет мучался вопросом как это работает :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 12:37
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
sysdba22о, а то я 15 лет мучался вопросом как это работает :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 13:19
|
|||
---|---|---|---|
Последствия редактирования RDB$ таблиц |
|||
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.05.2016, 14:12
|
|||
---|---|---|---|
|
|||
Последствия редактирования RDB$ таблиц |
|||
#18+
В ФБ3 прямое редактирование RDB$ таблиц запрещено. ALTER TABLE там будет работать так же как и сейчас? Т.е. кидая ошибку при ПОТЕНЦИЛЬНОЙ потере точности, а не при реальной? Если да, то это будет проблема. Например, как в нашем случае, когда надо в сжатые сроки провести деноминацию с добавлением копеек на базах предприятий, многие из которых работают в режиме 24х7. Конечно, можно удалять триггеры и чеки, создавать временное поле, переносить туда, удалять старое поле, переименовывать временное, восстанавливать триггеры и чеки. Но, когда баз туча и полей таких в одной базе могут быть сотни... И на крупных базах (более 100 Гб) такой процесс не будет быстрым. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=40&tablet=1&tid=1562170]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 146ms |
0 / 0 |