Здравствуйте, уважаемые коллеги. У меня возникло несколько вопросов по FB. Прошу прощения, если уже обсуждалось.

Итак, имеется список таблиц БД с названиями и типами полей, полученный запросом из этой статьи:
http://www.ibase.ru/devinfo/sysqry.htm#1

Вопрос 1. Тип поля в ней записан в виде числового кода. В каком документе можно прочесть про то, какому типу данных соответствует число в RDB$FIELD_TYPE?

Вопрос 2. Можно ли как-нить узнать кодировку строкового поля?

Вопрос 3. В базе, которую я исследую (FB 2.1, юникодные строки в таблице), одно из полей в одной таблице задавалось как varchar (255), однако у меня его длина в этом запросе отображается как 80. Является ли это багом, или я неверно трактую значение поля RDB$FIELD_LENGTH ?

Вынужден проводить это исследование из-за странной ошибки. Одна из таблиц, с которой я работаю, содержит единственную строку, одно из полей как раз объявлено как varchar (255) в юникоде. Всё время я писал в это поле 20-символьные строки. Когда пришло время нарастить строку до 21 символа, попытка записи в это поле с клиента выдала баг Ariphmetic exception... . Запустил свой SQL-редактор, подцепился к базе, попробовал задать запрос руками - 20символьное значение пишется на ура, а при добавлении 21 символа - вышеописанный эксепшн. Возможности заинсталлировать IBExpert, увы, нет.

И ещё, коллеги, такой вопрос. Существует ли на рынке какой-нить платный или бесплатный аналог IBExpert, не требующий инсталляции?

Первый вопрос про типы данных снимаю - невнимательно читал LANGREF, там это есть.

Запрос был такой:

Alex Truhin, спасибо. Я наивно полагал, что раз архив при распаковке предлагает по дефолту каталог назначения Program Files, значит, он требует инсталляции. Щас распаковал на флэшку, с неё запустился без проблем.

Кстати, а Вы не в курсе, пишет ли IBExpert что-то в реестр (HKLM) или в Common Appdata, запись в которые по умолчанию доступна только юзерам-админам?

авторЧем докажешь? Все признаки указывают, что оно задавалось как VARCHAR(20).

Немного углублюсь в историю. Когда я только создавал базу (уже больше года как), у меня это поле было CHAR(20). Потом (месяца два назад) я сделал альтер в VARCHAR(255), всё работало нормально. Ну а сегодня вдруг проявился этот глюк. Посмотрел на своём редакторе запросов - RDB$FIELD_TYPE=14, RDB$FIELD_LENGTH=80. Потому и написал сюда.

Самое интересное - щас перезапустил машину, и глюк исчез - всё пишется как надо.

Всем спасибо, прошу прощения за беспокойство.

авторесли бы ты сделал действительно alter, то оно было бы как надо. А так ты похоже сделал или изменение длины напрямую через системные таблицы, или, что аналогично, редактированием домена (столбца) в IBExpert.

В том-то и дело, что делал через alter, ибо прекрасно знаю, чем мне, относительному новичку, чревата запись напрямую в системные таблицы. IBExpert - вещь хорошая, но я пользуюсь им очень редко, ибо мне вполне хватает самопального редактора запросов - это уже дело привычки.

Решил на всякий случай сделать базе backup/restore - думаю, не повредит.

авторb/r не перекомпилирует метаданные.

Спасибо за информацию. Тогда, пожалуй, проще пересоздать и скопировать базу через скрипт с коррекцией соответствующего CREATE TABLE

авторПопробуй заглянуть, например, в таблицу RDB$TYPES

Спасибо, я уже нашёл эту информацию в LANGREF.