Обновил только что версию IBExpert на 2018.6.7.1

Для любой системной таблицы при переходе на вкладку "Данные" выдает

Error Message:
----------------------------------------
List index out of bounds (0)

[0041D381] Classes.TStringList.GetObject (Line 3381, "Classes.pas" + 1) + $13
[0041D381] Classes.TStringList.GetObject (Line 3381, "Classes.pas" + 1) + $13
[00E029B3] TblViewF.TTableViewForm.RefreshData (Line 550, "TblViewF.pas" + 10) + $13
[00E03616] TblViewF.TTableViewForm.aRefreshExecute (Line 855, "TblViewF.pas" + 31) + $2

Вкладка, соответственно, после ничего не отображает.

С обычными таблицами работает нормально.

Firebird 3.0.2.

Запустил 2018.6.8.1, работает.

Спасибо!

И спасибо за отличный инструмент!

Никогда такого не было, и вот опять!

Firebird 4.0
IBExpert 2021.10.14.1

Что характерно, сбой наблюдается на Windows 7 SP1 64 и на Windows Server 2012 R2 64.
В Windows 10 64 работает чисто.

Эта гипотеза неверна. На всех компьютерах лежит

fbclient.dll 4.0.0.2496 от 31.05.2021,

и находится она в

C:\Windows\SysWOW64 ,

откуда её и грузит в себя IBExpert. Проверено электроникой.

Скопировал все icu*.dll из инсталляционного пакета Firebire-4.0-Win32 в системную папку. Помогло, спасибо, работает.

Но, ёлки-палки, как об этом можно было догадаться самостоятельно? При обновлении версии сервера просто кидал fbclient.dll из 32-разрядного параллельного пакета в системную папку. В пакете есть утилита instclient.exe, но она делает ровно то же самое. Оказалось, этого мало, нужны еще новые icu*.dll, а то, может, и еще какие. И хоть бы кто при загрузке вякнул, мол, чего-то не хватает.

Процесс IBExpert грузил в себя, и продолжает грузить icudt30.dll и icuuc30.dll из IBExpert\IBEUDB, и продолжает грузить, но это, я понимаю, только для поддержки собственной embedded UserDB (FB 2.5). А вот ныне загруженных icudt63.dll и icuin63.dll у него не было, и ничего, молча работал. Или молча не работал, когда нужда доходила. Ну, может, так и правильно.

Симонов Денис,

Я уж понял, спасибо. Я к тому, что хорошо бы, если нет ICU, сказать, что нет ICU, функциональность будет ограничена, не обессудьте. Это сказать (вернуть код ошибки), наверное, мог бы fbclient, уж коли ему этот icu нужен. А программа, использующая клиента, могла бы донести сей печальный факт до пользователя. А тот бы уже думал, что это еще за icu такая, и ведь додумал бы.

Так и занятых людей на форуме пришлось бы меньше отвлекать.

hvlad,

Ну, а на моих Win7 и Win2012 было так, как на картинке. Рад бы еще помочь, но не знаю, как. Посмотрите, не загрузил ли у вас процесс IBExpert в себя icu*.dll из какого-нибудь другого места. Может, они и в вашей системе уже есть.

У меня IBExpert вообще не хочет грузить клиента не из системной папки.

Клиент 32-разрядный, зуб даю.

hvlad,

Сделал. isql без ICU возвращает

2021-10-21 14:52:34.9560 GMT*

а с ICU

2021-10-21 17:52:35.1280 Europe/Moscow

То есть проблема не в fbcient.dll, ладно, это радует. А в чем тогда? IBExpert без ICU продолжает себя плохо вести.

Во всех "базах", т.е. в параметрах коннектов прописана просто fbclient.dll без пути. Ну, понятно, что произошло: если fbclient.dll не нашлась в системной папке, то она и нигде не нашлась, несмотря на Environment Options/Default Client Library . Ладно, это легко обходимо, когда знаешь.

Но вот основная проблема остается открытой. В случае отсутствия библиотек ICU isql.exe выполняет select * from mon$attachements корректно, возвращая зону GMT*, а IBExpert налетает на исключение в Firebird.IUtil.decodeTimeStampTz .

Почему брр? Клиент всегда последний и соответствующий серверу, в данном случае firebird.dll 4.0.1.2631 32 (поставил отладочный снапшот). С чуть более ранним 4.0.0.2496 та же история. Неважно, где он лежит, обычно в системной папке, но пробовал в разных других местах, место ни на что не влияет. Всегда проверяю Process Explorer'ом, какой реально клиент загружен.

Кстати, был несказанно удивлен, увидев, что одновременно в процесс загружены несколько одноименных fbclient.dll. Я еще думал - как это так сделано, разные коннекты с разными клиентами?


Я догадываюсь. ISQL тоже ничего про неё не знает. Однако ISQL на том же компьютере и с тем же клиентом без ICU почему-то принимает зонные даты, ставя им GMT*, а IBExpert налетает на исключение. Вопрос скорее любопытства, чем практический, потому что теперь, зная про важность ICU, надо просто про нее не забывать.