Скачал снапшот, распаковал, запустил "gsec -add SYSDBA -pw masterkey -admin yes" из папки FB
Пытаюсь создать из клиентского приложения базу, через API. Строка подключения вида 'd:\db\data.fdb'.
Получаю отлуп:
---------
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
---------
Это FB 2.5 откликнулся. Хорошо ещё что у него пароль другой, а то бы сейчас наработал :)
Стопаю его. Опять запускаю приложение с попыткой создания базы.
Получаю отлуп:
---------
Could not find acceptable ICU library
---------
1.Можно ли запретить клиенту пытаться коннектиться к установленному серверу?

2.Ошибка с ненахождением ICU связана с тем, что Firebird находится не в папке приложения:


Если раскомментировать строку 2, и скопировать содержимое "Firebird\3.0.0.30728\" в папку с exe-шником, то всё ok, база создаётся.
Но дальше... комментирую эту строчку обратно, и всё работает... подтягивается ICU library, только не та что надо (почему-то подтягивается та, что рядом с exe-шником). Хорошо что этой ICU у меня в PATH нет, тогда бы вообще получили загрузку неизвестно чего неизвестно откуда :)
Можно ли сделать так, чтобы ядро не пыталось грузить что-то за пределами своей папки? И чтобы ICU library таки подтягивалась из правильного места? :) Мне кажется что код, который грузит этут библиотеку, мог бы грузить её по полному пути, и искать её для начала рядом c firebird.dll :)

Dimitry SibiryakovNickDee1.Можно ли запретить клиенту пытаться коннектиться к установленному серверу?

Убери из конфига провайдеры Remote и Loopback.

Оказалось достаточно убрать Remote.

А теперь если у меня приложение должно работать и с базой на другом компе, и локально в embedded-mode, то как тут быть? Конфиг ведь один. И при этом я не хочу, чтобы embedded-коннект вдруг пошёл к неизвестному мне локальному серверу. Кстати в 2.5 была исключена сама возможность коннекта к постороннему локальному серверу, если работать через embedded и использовать пути типа 'c:\db\data.fdb'. Теперь же есть такой неожиданный side-effect.

Может передавать управление в следующий провайдер только тогда, когда строка коннекта не подпадает под правила провайдера?
Ну т.е. если например отлуп у указанного первым Engine12 произошёл по причине того, что путь не найден (при том, что сама строка корректна), то нужно вернуть ошибку пользователю, а не передавать управление на следующий провайдер. Если же сама строка некорректна (не может быть обработана провайдером в любом случае, т.е. пролетает уже по своему формату), то только в этом случае пробовать следующий провайдер.

Dimitry SibiryakovNickDeeА теперь если у меня приложение должно работать и с базой на другом компе, и
локально в embedded-mode, то как тут быть?
Верни обратно Remote и убери-таки Loopback.

При "Providers = Remote,Engine12":
- коннект к 'c:\db\data.fdb', при остановленном локальном сервере, идёт в embedded-режиме, и валится с ошибкой:
"Could not find acceptable ICU library".
- коннект к 'c:\db\data.fdb', при запущенном локальном сервере, идёт к этому серверу , и валится с ошибкой:
"Your user name and password are not defined. Ask your database administrator to set up a firebird login."
- коннект к 'www.ru:c:\db\data.fdb', идёт в remote-режиме, и валится с ошибкой:
----------
Unable to complete network request to host "www.ru".
Failed to establish a connection.
Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.
----------
Т.е. "Providers = Remote,Engine12" - не подходит категорически (из-за side-effect с локальным сервером).


При "Providers = Engine12,Remote":
- коннект к 'c:\db\data.fdb' идёт в embedded-режиме, и валится с ошибкой:
"Could not find acceptable ICU library" (и не важно, запущен ли локальный сервер).
- коннект к 'www.ru:c:\db\data.fdb' идёт к www.ru, обламывается, и валится с ложным описанием ошибки :
------------
I/O error during "CreateFile (create)" operation for file "www.ru:c:\db\data.fdb"
Error while trying to create file
Синтаксическая ошибка в имени файла, имени папки или метке тома.
------------
Т.е. "Providers = Engine12,Remote" - подходит, если текст ошибки будет правильным :)

hvlad'inet://www.ru:c:\db\data.fdb''
При "Providers = Engine12,Remote":
------------
I/O error during "CreateFile (create)" operation for file "inet://www.ru:c:\db\data.fdb"
Error while trying to create file
Синтаксическая ошибка в имени файла, имени папки или метке тома.
------------

Но идея нравится :)

hvlad'inet://www.ru:c:\db\data.fdb''
А просто при "Providers = Remote" всё странным образом зависит от наличия запущенного локального сервера:
- если локальный сервер запущен, то: "unavailable database", причём на www.ru даже коннектиться не пытается.
- если остановлен, то:
------
Unable to complete network request to host "localhost".
Failed to establish a connection.
Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.
------
Почему localhost?

А при "Providers = Remote" и 'www.ru:c:\db\data.fdb' - всё хорошо, ошибка правильная
Т.е. с "inet://" что-то не так...

dimitrэто бага, на днях Алекс исправлял
Понятно.
А то что ICU не грузится - это всё-таки бага? Или я что-то не правильно делаю?

dimitrЗЫ. могу сразу сказать, что искать ICU только в пределах своих папок ФБ не будет. В общем случае, ее можно считать системной библиотекой. Так что делай ее доступной или явно или через PATH.
Но хоть можно сделать так, чтобы UCI искалась для начала рядом с firebird.dll? Это ведь всяко безопасней, чем загрузить ICU (возможно бажный) какой-нибудь левой программы, которая прописала себя в PATH. Это прям очень похоже на грабли, на которые наступила microsoft с msvcrt-либами.

Dimitry SibiryakovNickDeeЭто ведь всяко безопасней, чем загрузить ICU (возможно бажный) какой-нибудь
левой программы, которая прописала себя в PATH.
Ты всерьёз предлагаешь всем извращаться, только для того чтобы криворукие авторы могли и
дальше распространять свои левые программы, не исправляя их?.. ICU это вполне официальная
софтина от IBM, её баги это проблемы IBM, не Firebird.

Вот поставишь ты себе программу, и словишь трудноуловимые баги. А т.к. ты продвинутый, ты сможешь понять в чём бага. И после выяснений с разработчиками окажется, что бага совсем не в том что firebird подгрузил левую (бажную) ICU, а в том что баги левой ICU - это проблемы IBM :)

Например если у меня программа использует сразу две версии Firebird (2.5 и 3.0), которые естественно размещены в разных папках и имеют разные версии ICU, то я (как разработчик) ожидаю что ядро FB каждой версии будет использовать свою ICU, а не какую найдёт...
И ожидаю что я могу в одном процессе подгрузить эти две версии, одновременно и без лишних танцев с бубном, и работать с ними одновременно (например переливать данные из одного в другой).
И ожидаю что у клиента всё пройдёт точно так же (без side-effects), независимо от того, какие программы у него установлены.

Чувствую что нужно будет погонять тесты на совместимость двух различных FB-ядер при работе в одном процессе, при многопоточной нагрузке (особенно при загрузке/выгрузке dll и коннектах) :) Это примерно сценарий IIS, который грузит скрипты (в виде dll), которые в свою очередь могут грузить разные версии FB. И причём каждая такая dll может неожиданно поменять переменную PATH, или переменную FIREBIRD (которую нужно устанавливать перед самым первым коннектом после загрузки firebird.dll, для указания пути к правильному fb-конфигу), или может изменить рабочий каталог :) По-моему это будет fail. Во всяком случае с переменной FIREBIRD - точно fail, т.к. синхронизировать это никак не получится (в одном потоке мы установим значение переменной FIREBIRD, а другой (из другой dll) имеет возможность его тут же поменять).
Переменные окружения - они ведь глобальные. И если в рамках одного кода использование переменной можно обложить критическими секциями, то в рамках двух dll в одном процессе (и без исходников) - это уже на совести разработчиков dll к IIS. Причём если разработчики различных dll не договорятся как это синхронизировать (а разработчики часто даже не знают о существовании друг-друга), то получатся потенциальные трудноуловимые баги.
Глобальные переменные - зло, а несинхронизируемые - это зло вдвойне :)

Dimitry SibiryakovNickDeeНапример если у меня программа использует сразу две версии Firebird (2.5 и
3.0), которые естественно размещены в разных папках и имеют разные версии ICU, то я (как
разработчик) ожидаю что ядро FB каждой версии будет использовать свою ICU, а не какую
найдёт...
У меня программа использует сразу Interbase, Firebird, Oracle и практически любой ODBC
источник. Следуя твоей логике в её дистрибутив должны входить Firebird, Interbase и Oracle
"правильных" версий. Оно мне надо? Ублажать системные требования софта - работа его
пользователя. На нём лежит обязанность настройки окружения, на мне - гарантия того, что я
это окружение не испорчу изменением того, что мне не принадлежит.

Тебе не надо, потому что это на совести пользователя (установка и настройка FB-серверов, слежение за программным окружением). А мне надо, потому что всё на моей совести :)

А как ты указываешь разным fb/ib-клиентам путь к их firebird.msg? Ты ведь наверняка указываешь, а не полагаешься на тот, который прописан в реестре, ведь он там может быть левым, или вообще отсутствовать.
У тебя fb-коннекты разных fb-клиентов работают впараллель?

kdvNickDeeИ ожидаю что я могу в одном процессе подгрузить эти две версии, одновременно и без лишних танцев с бубном
imho, ожидание не вполне естественное, с учетом что две разных dll в свою очередь грузят сторонние, но одинаковые dll.
мне кажется, ты описываешь проблему, которая вполне известна в отношении разных версий рантаймов MSVC.

NickDeeНо хоть можно сделать так, чтобы UCI искалась для начала рядом с firebird.dll?
а оно разве не через LoadLibrary грузится?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Если стоит вызов просто LoadLibrary('icu*.dll'), то dll будет искаться в разных папках, и вот в каком порядке (при WindowsXP SP2 и выше):
1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.

Поэтому тут совершенно не понятно, что в конечном итоге загрузится...
Разработчик имхо точно не ожидает, что будет подгружена какая-то левая либа какой-то мутной не оттестированной с FB сборки :)

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

Dimitry SibiryakovNickDeeА как ты указываешь разным fb/ib-клиентам путь к их firebird.msg? Ты ведь
наверняка указываешь, а не полагаешься на тот, который прописан в реестре, ведь он там
может быть левым, или вообще отсутствовать.
Конечно же не указываю. Поскольку, как ты и сказал, правильная установка клиентов - на
пользователе.

Понятно. Т.е. если я сейчас поставлю дистриб твоей программы, то при ошибке скорей всего огребу левое сообщение? :) А после правильной настройки окружения мне придётся считаться с тем фактом, что это окружение уже прибито гвоздями. Т.е. я уже не смогу, как раньше, снести один firebird, поставить другой, без боязни повредить работоспособности твоей программы Т.е. я потеряю былую свободу на своём же компе :) Если всё именно так, то это конечно да, никакой заботы обо мне и о моей свободе :)

Dimitry SibiryakovNickDeeя уже не смогу, как раньше, снести один firebird, поставить другой, без
боязни повредить работоспособности твоей программы
Просто удивительно, как я её тестирую и отлаживаю с установленными всеми версиями Firebird
одновременно...

У тебя ведь репликатор наверняка работает как сервис. И наверняка умеет реплицировать из FB 2.1 в FB 2.5 и обратно. И наверняка ты предоставляешь пользователю возможность указать конкретную либу.
Вот куплю я твою прогу, и как ты мне посоветуешь настроить окружение, чтобы клиентская либа от FB 2.1 брала свои firebird.conf и firebird.msg, а либа от 2.5 - свои? :)

Dimitry SibiryakovNickDeeИ наверняка ты предоставляешь пользователю возможность указать конкретную
либу.
Разумеется нет. Я же сказал, что использую ровно одну клиентскую библиотеку для каждой
СУБД - ту, которая находится стандартным LoadLibrary. Совместимость клиента с сервером на
совести разработчиков этой СУБД.

Было бы круто, если бы IBExpert пошёл по такому же пути, и перестал давать пользователю возможность указывать либу :) Типа пусть пользователи заботятся об окружении :)

А почему ты не сделал для пользователя возможность указывать клиентскую либу и клиентский конфиг? Какие были доводы?

kdvNickDeeчтобы клиентская либа от FB 2.1 брала свои firebird.conf и firebird.msg, а либа от 2.5 - свои? :)
а зачем в этом случае использовать клиентскую либу от 2.1? Ты сценарий нарисуй, а то не очень понятно.
Даже если все взгромоздить на один комп - и репликатор, и фб 2.5, и фб 2.1, то репликатору достаточно клиентской либы от 2.5.
И тут сразу два ограничения:
1. Мы запрещаем пользователю пользоваться клиентом 2.1
2. Мы запрещаем на этом компе сносить и устанавливать fb-сервера (т.к. при этом клиентская либа может меняться в любую сторону).
Зачем? Зачем программа накладывает на пользователя дополнительные ограничения? Что, нельзя без них? Можно конечно.
Вот ты поставь себе на машину такой репликатор, сразу почувствуешь ограничение свободы действий :)

Dimitry SibiryakovКлиенты Firebird при правильном использовании совместимы с
серверами всех версий.
Если это так, тогда да. Но только если это на самом деле так :)
А клиентский конфиг? Почему ты не даёшь возможность его указывать?
А firebird.msg от 2.5 нормально отработает при сервере 1.0?

kdvNickDee1. Мы запрещаем пользователю пользоваться клиентом 2.1
с чего бы это?

У нас по условию два коннекта - один к 2.1, второй к 2.5. Т.е. либо мы к обоим серверам будем коннектиться с либой от 2.5, либо к обоим с либой 2.1.
С либой 2.1 к серверу 2.5 - это тоже ok?

kdvNickDee2. Мы запрещаем на этом компе сносить и устанавливать fb-сервера
опять же, кто запрещает?

После сноса 2.5 и установки 1.5, репликатор станет коннектиться к 2.1 и к 2.5 либой от 1.5 (и использовать firebird.msg от 1.5).
А мы такого не можем себе позволить. Поэтому устанавливать софт, который может "вдруг" изменить нашу клиентскую либу до несовместимой версии, мы устанавливать (или сносить) не можем.
В этом ограничение.
Конечно можно положить либу от 2.5 рядом с exe-шником, но firebird.msg при этом всё-равно будет браться от 1.5.

Изолированностью от окружения тут похоже мало кто так заморачивается :)

Dimitry SibiryakovНикто не мешает проверять версию загруженного клиента и выдавать вменяемую диагностику.

а то что firebird.msg используется от старой версии? Это как обходишь?

miwaonlineА задавать в своем приложении переменные окружения FIREBIRD и FIREBIRD_MSG с нужными путями уже не модно в этом сезоне?
Почитай про сценарий с IIS и переменной FIREBIRD: 15144742 . И посоветуй хорошее решение :)
Вот если бы в параметрах коннекта можно было указывать путь к конфигу, и к firebird.msg - это было бы решением.
И ещё бы функцию у firebird.dll, типа: DisableEnvironmentVariable('FIREBIRD'), чтобы не цеплялось ничего левого от окружения :) И DisableDefaultClientConfig, чтобы не лазило в реестр на предмет уже установленного (кем-то) клиента.
Я в своей проге хотел бы иметь возможность отгородиться от окружения неизвестного качества настроенности :) Думаю сама возможность отгородиться должна быть, а уж воспользуется ли ей разработчик, или пожелает оставаться в зависимости от окружения, или вообще сделает это опциональным для пользователя - это уже ему решать :)

Dimitry SibiryakovNickDeeсама возможность отгородиться должна быть
Единственная возможность хорошо отгородиться это работать в полностью виртуальном
окружении. И воспользоваться этой возможностью разработчик может всегда безотносительно от
Firebird.

Мне прям очень-очень странно, что ты не видишь тут косяка :)