InterBase: тормозология и глюконавтика
Страница 37. Глюки, которые официально исправлены в 5.5

Глюки, которые официально исправлены в 5.5 (52 шт)

• Новый установочный скрипт и файл interbaseLICENSE не документированы в README
• Справка к WISQL не обновлена
• Сервер повисает из за глюков в менеджере блокировок
• Вызов хранимой процедуры из InterClient'а вешает сервер (Интересно, они вообще когда-нибудь думают защищать свой протокол?)
• Обновления, сделанные триггером не отматываются при rollback (Ни чего себе!)
• Исключения (а при некоторых кодировках, включая win1251 - порча базы) при попытках перекодировать из Unicode_fss
• Слишком большое количество версий метаданных портит базу, в частности, из за многих alter trigger (Надо учитывать. Правда, не говорят, при каком количестве.)
• Большое количество grant'ов на одну таблицу портит базу
• Невозможно загрузить gdsintl, если interbase установлен в путь, включающий точку. Обходной путь задокументирован
• Запрос ко вьюшке, основанной на другой вьюшке, обрушивает сервер
• gfix -attach не даёт активной транзакции завершиться
• Многопользовательский тест допускает только 96 подключений к NT
• Восстановление из бэкапа может не пройти, если база содержит хранимую процедуру, основанную на вьюшке
• "WARNING: column EM_FNAME is not defined in table RDB$PAGES" (Я это видел, когда разбэкапливал базу 4 утилитой gbak 5.1. Главная странность в том, что RDB$PAGES не имеет отношения к полям.)
• cast() возвращает неправильный результат для чисел numeric < 1
• Улучшение документации на лицензирование 5.0
• Преобразование numeric в char даёт ошибку, если char() слишком длинный
• Преобразование максимального по модулю отрицательного целого в строку даёт ошибку
• Ошибки при select'ах на внешних файлах
• Слишком большое количество (свыше 200) alter table в скрипте приводят к сообщению "request depth exceeded"
• isc_info_base_level врёт о версии базы
• gbak портит принадлежность хранимых процедур пользователям
• gbak не проходит на некоторых базах, содержащих триггера для поддержки ссылочной целостности
• gbak портит принадлежность таблиц пользователям (По-моему, они это уже исправляли. Дежа вю?)
• grant на хранимые процедуры ведёт себя глючно
• rtrim() в запросе select обрушивает сервер (Здесь и далее видимо имеются в виду функции из того dll, который прилагается к версии 5 и выше. Оказывается, он ничем не лучше нашего в его начальном состоянии)
• Ltrim(), rtrim(), lower() возвращают неправильную длинну строки char()
• Lower() возвращает некорректные результаты
• Функции, скомпилированные Borland C++, не возвращают память
• Дропанье триггера дропает сервер под HP-UX
• SYSDBA не может сделать revoke, если соответствующие привилегии были переданы пользователем дальше
• alter trigger inactive обрушивает сервер (ни разу не видел, хотя в 5.0 может и есть)
• Сервер под NT падает, если триггера по многу раз подряд дропаются или альтерятся
• Внешние функции иногда обрушивают сервер (Это действительно так, особенно когда не отлажены, но такова уж природа вызова этих функций из недр interbase. Может быть имеется в виду какой-либо случай, когда функция корректна, но сервер падает. Вполне может быть, но подробностей они не разъясняют.)
• Gbak 5.1.1 иногда не восстанавливает .gbk-файлы, сделанные в предыдущих версиях (Я пробовал восстанавливать 4.0-4.2, всё проходило без особенных неожиданностей. По крайней мере ничего такого, чтобы глючило в 5.x, но не глючило в 4.x. Наоборот - да.)
• Скрипт ISQL обрушивает сервер (опять не разъясняют детали, конкретных примеров выше - сколько угодно)
• Alter на процедуру, используемую другой процедурой привощит к отрубающей ошибке bugcheck (Не разъясняют, что значит "использует": то ли активный в данный момент вызов, то ли просто ссылку изнутри тела)
• show triggers работает очень медленно из-за недоступного системного индекса (То, что у них индексов на метаданных хронически не хватает, глюк известный. А вот чтобы show triggers тормозил, я как-то не замечал.)
• Многошаговые триггера могут не исполнить все шаги (Ого! Надо учесть.)
• Объекты базы данные после восстановления из бэкапа принадлежат тому пользователю, под которым делалось подключение для этого восстановления (Похоже, они на этом глюке помешались. Видел сообщения о нём раз 5. Чуть ли не во всех версиях. Интересно, они его всё-таки исправили в 5.5 или в списке глюков 6.0 тоже будет такая же строчка?)
• Невозможно сделать alter на процедуру, которая ссылается на другую процедуру, если у той изменился список параметров (Ну это мы и без них заметили)
• Ограничения check не проверяют результаты триггеров
• Сервер interbase обваливается, если попытаться дропнуть триггер, используемый в данный момент
• Проблемы в мурыжере, извините, в менеджере блокировок
• Сервер обваливается, когда проедуру дропают сразу же после вызова
• Show grant пропускает ключевое слово Trigger (Похоже, у них совсем крыша поехала. Зачем гранты на триггера?)
• Невенрая проверка права Execute для хранимых процедур
• Слишком много информационных сообщений в Interbase.log (По-моему, наоборот, слишком мало. Ни в чём разобраться невозможно. Наиболее важные детали, как правило, оказываются опущенными. И повлиять на этот процесс невозможно. Весьма хреново.)
• Неправильные путь в параметре gsec -database вешает NT Server (Это глюк обоих продуктов)
• Офигенный рост памяти при восстановлении базы с некоторыми разновидностями взаимозависимых хранимых процедур
• Commit на некоторых видах хранимых процедур обрушивает свервер (Во-первых, не говорят, что должно быть в процедуре. Во-вторых, не говорят, к чему Commit: к созданию процедуры или к её последующему вызову.)
• Сервер обрушивается и/или портит базу, если более 50 пользователей одновременно мучают его тяжёлыми запросами достаточно длительный промежуток времени
  
  
  

  « Предыдущая страница - Следующая страница »