Александр, чтобы два раза не вставать, озвучу в одной теме известные мне баги, недоработки и неудобства. Исправлять их или нет - решайте сами. Это то, с чем я как пользователь IBExpert'а сталкиваюсь ежедневно и ежечасно в процессе обычной работы разработчика БД.

Баги. Здесь опишу только один:
1. Самый главный баг, которому уже много лет. При нажатии Ctrl+Space не появляется выпадающий список. Лечится перезаходом в среду. Иногда достаточно сделать пару правок в запросе и список опять перестает появляться. В запущенных случаях приходится перезаходить в IBE каждую минуту. Учитывая открытых окон порядка сотни, постоянный процесс перезахода очень радует.

Недоработки:
1. При раскомментировании ХП в "ленивом режиме", которая до этого была закомментирована в выключенном "ленивом" режиме, не раскомментируется секция декларации переменных. В итоге ХП не компилится, приходится выключать "ленивый" режим и снова раскомментировать.
2. При создании внешнего ключа, не проверяется заполнение таблицы, на которую ссылается ключ. После нажатия на "ОК" выдается
И пытаешься сообразить, что пошло не так.
3. IBExpert разрешает снять флаг NOT NULL у поля, входящего в ПК.
4. При создании таблицы или ХП, если хочешь скопировать в буфер обмена название и вместо Ctrl+C нажимается C, по уже никак нельзя вернуть старое название - Ctrl+Z очищает текст.

Неудобства:
1. При создании ВК, нет возможности увидеть, сколько символов занимает имя. Приходится вручную считать количество символов. И так каждый раз, если имя таблицы достаточно длинное.
2. При создании ВК, не указывается, что имя ВК более 31 символа и оно никак не ограничено. Смотришь - вроде все норм, нажимаешь ОК и:
3. При создании ВК при генерации шаблонного имени нет обрезки до 31 символа. Например, вместо FK_LONGNA_13 создается FK_LONGNAME_13, который приходится ручками обрезать, при этом подсчитывая, сколько символов есть под число.
4. Взаимодействие с стрелкой мыши. Пример: открыт редактор поля, стрелка находится под списком доменов на 40 пикселей ниже. Раскрываешь список по Alt+Down, и выбранным становится не текущий домен, а домен под стрелкой.
5. Список доступных слов по Ctrl+Space. Всякий мусор в виде имен триггеров, индексов и ключевых слов SQL-я (IN, ALL и прочая) вообще не нужен, либо нужен строго определенным лицам. Особенно радуют системные домены RDB$NNN в нем - кому вообще это надо?
В списке нужны только: таблицы, представления, ХП, секвенции, UDF и встроенные функции. Всё.
6. Нет подсветки скобок при редактировании вычисляемого поля. В особо сложных случаях на попытку понять, какой не хватает, уходит куча времени. Там же нет выпадающего списка, как в SQL-редакторе. Часто приходится писать поле в редакторе, и потом уже переносить запрос в само поле.
7. При измененении флага события у триггера, нет предложения о переименовании триггера в связи с изменением его типа.
8. В закладке "Данные" таблицы, при открытии списка для ВК, первой строкой идет запись с выбранным кодом. Я не знаю, кто это придумал, но это очень неудобно. Мало того, что путает (идут ID: 4, 1, 2, 3), так и выбор следующего или предыдущего ID проблематичен.
9. В редакторе таблицы "колонка" показывает сумму NOT NULL у самого столбца и у домена. Это путает - непонятно, откуда пришел этот флаг - из домена или так объявлено у поля. По-хорошему тут должно быть два поля: FIELD NOT NULL и DOMAIN NOT NULL.
10. При Replace Text не указывается длина текста, на который заменяется искомый текст. Для новых имен таблицы и ХП это важно - снова приходится вручную пересчитывать длины, проверяя, сколько еще места осталось.
11. При каждом переименовании таблицы или ХП в редакторе скриптов, приходится сбрасывать галку "Promtp on replace" и "Selected text". Хотя тут очевидно - если выделен однострочный текст длиной в 15 символов, какой там Selected Text?
12. Предупреждение об отсутствии прав на таблицу/ХП. Создал разработчик таблицу и забыл дать права на нее. Об этом он узнает, только когда таблица придет в продакшн и пользователь обратится к ней. Если бы прямо на главной странице было написано: "У таблицы отсутствуют права для пользователей/ролей", это исключило бы вероятность ошибки.

Новый функционал:
1. Шаблоны создания таблицы. Например, есть стандартный справочник. В нем поля ID, NAME, генератор для ID. Дополнительно может быть поле POS. Сейчас приходится или с нуля описывать таблицу, либо брать скрипт создания существующей, переименовывать и создавать генератор.
2. Шаблоны прав ролей. Например, есть две роли - одна только на чтение, вторая на правку таблицы. Сейчас надо при создании каждой таблицы справочника прописывать права ролям. Да, это недолго, несколько кликов. А когда ролей будет с два десятка?
3. Поддержка переименования ХП.
4. Перекомпиляции всех зависимых ХП. Переписал вот ХП, а она используется в ХП на пять уровнях выше. И ходишь пять минут по стеку зависимостей, перекомпилируешь их.
5. Открытие окон и комментирования всех зависимых ХП и триггеров. Обычная операция по изменению списка входных параметров ХП состоит из унылого клацанья по клаве и тыканья мышой.
6. Операция по изменению типа поля, которое требует создания временного поля (например, уменьшение длины строки с 50 до 25 символов).
7. Проверка права вызова для всего стека вызовов ХП для пользователя/роли. Например, SP1 вызывает SP2. У роли ROLE1 есть право вызова SP1, но нет права вызова SP2. Об этом я узнаю, только когда у пользователя произойдет

Симонов ДенисВ общем если и делать то только для <3.0
Да.
Симонов ДенисА вот мне имена триггеров и индексов нужны. Я иногда DDL операторы пишу и не только в редакторе скриптов.
Ок. Тогда сделать настройку с доступными видами метаданных, потому что мне они за ни разу не понадобились, так как скрипт с DDL получаю другими средствами IBE.
Симонов ДенисЧто касается "системных" доменов, то реально они вовсе не системные, хоть и создаются автоматом. Нету у них RDB$SYSTEM_FLAG = 1. Можно конечно попытаться фильтровать по префиксу
Думаю, что есть 100% способ определить такие объекты.

IBExpert,

Я как раз и создал одну тему просто для ознакомления вместо тридцати, чтобы потом не было ответа, что лень просматривать и отвечать на десятки топиков. Разбивать пункты на отдельные темы не буду. Если у вас нет интереса даже прочитать текст, я ничего не могу и не буду с этим делать.

Симонов Денис> 2. При создании ВК, не указывается, что имя ВК более 31 символа и оно никак не ограничено. Смотришь - вроде все норм, нажимаешь ОК и:

не символа, а байт, с символами оно совпадает только если название на английском. В 4.0 будет уже 63 символа.
Речь не о максимальной длине, а о том, что нет ограничения. Отлично, в 4.0 будет 63 символа. А если дефолтная длина ВК будет 68 символов? Будет ровно та же самая ошибка.

Симонов Денис> 5. Список доступных слов по Ctrl+Space. Всякий мусор в виде имен триггеров, индексов и ключевых слов SQL-я (IN, ALL и прочая) вообще не нужен, либо нужен строго определенным лицам. Особенно радуют системные домены RDB$NNN в нем - кому вообще это надо?
В списке нужны только: таблицы, представления, ХП, секвенции, UDF и встроенные функции. Всё.

А мне значительно больше. Единственное чего бы я видеть не хотел это автоматически создаваемые домены RDB$nnnn
Настройка видов объектов в списке - идеальное решение.

Симонов Денис> 2. Шаблоны прав ролей. Например, есть две роли - одна только на чтение, вторая на правку таблицы. Сейчас надо при создании каждой таблицы справочника прописывать права ролям. Да, это недолго, несколько кликов. А когда ролей будет с два десятка?

В 4.0 система прав много разнообразней и проще. Часть вещей с правами можно делать в 10 раз легче.
В том числе появится применение нескольких ролей одновременно, если я правильно помню. Поэтому буду делать не две роли, как сейчас, а реально по функциональному назначению. Вот тут шаблоны и пригодятся.

Симонов Денис> 3. Поддержка переименования ХП.

ИХМО, поддержка переименования объектов метаданных должна поддерживаться на уровне Firebird. Сейчас оно есть только для доменов и столбцов таблиц.
Согласен. Но пока этого нет, решение проблемы через сторонний инструмент является выходом.

Симонов Денис> 6. Операция по изменению типа поля, которое требует создания временного поля (например, уменьшение длины строки с 50 до 25 символов).

с учётом зависимостей задача становится мало реальной
Это не так. Достаточно проверить наличие отсутствия зависимостей перед операцией (правильно будет их зачистку возложить на разработчика) и можно начинать ее делать. Если что-то не получилось в процессе - ничего страшного не произойдет - почистить можно будет ручками.

Симонов Денис> 7. Проверка права вызова для всего стека вызовов ХП для пользователя/роли. Например, SP1 вызывает SP2. У роли ROLE1 есть право вызова SP1, но нет права вызова SP2. Об этом я узнаю, только когда у пользователя произойдет

Жди 4.0. Там это будет не так актуально.
Ок.

Симонов ДенисТеперь по поводу автоматической замены в имен в зависимостях при переименовании, не приведи господь к этому. Бездумно коцать тексты десятков ХП, которые в следствии таких замен могут ещё и не правильно работать. Ну его нафиг.
Операция опасная. Но вот сходу не могу определить прямо совсем непоправимые последствия.
Кстати, если брать тупую автозамену, то перекомпиляцию ХП и триггеров можно делать в рамках одной транзакции (по типу обычной перекомпиляции списка ХП) с откатом, если произошло исключение.