1) Для чего сделали порядок провайдеров таким, чтобы без указания протокола, устанавливалось Embedded соединение?
#Providers = Remote,Engine12,Loopback

Мне кажется, более логичным было бы:
Providers = Remote,Loopback,Engine12

В чем смысл приоритетного использования Embedded без указания протокола, если:
- он медленнее
- Engine12.dll поставляется только той разрядности, что и сервер => клиенты отличной разрядности не смогут соединиться
- для использования других протоколов нет никаких ограничений
- так было раньше
- и т.д.

2) Сейчас, если использовать параметр по умолчанию, то установить соединение, может приложение (на этом же хосте, что и сервер) только соответствующей серверу разрядности.




3) Читаю README.providers.html
When database name does not contain network protocol (just dbname) Remote provider rejects it and Engine12 provider comes to stage. It tries to open dbname – and in case of success we get embedded connection to the database. Pay attention – we do not need special embedded library to have embedded connection, standard client loads appropriate provider and becomes embedded server .

Но ведь это не так?

So after failure of Engine12 to access database Loopback provider is attempted for an attach .

Но ведь это не так - до Loopback дело не доходит.


Зачем так сделали? Или я упустил какой-то тайный смысл?

Симонов Денисзачем ты всё это написал?
Чтобы поговорить об этом, может еще не все потеряно.

авторЧто сложно нужный протокол указать префиксом в coonection string или конфигурацию под свои нужды поменять?
Мне-то не сложно, но должны же быть хоть какие-то аргументы для поставки конфигурации, которая будет работать в 50% случаев.

hvladКакую реальную проблему ты не можешь решить ?

Все конечно, проходимо...

Dimitry SibiryakovИли всё проще и это единственный порядок при котором сервер не входит в бесконечный цикл
подключения к самому себе.

Не понял, как при таком порядке (Remote,Loopback,Engine12) можно уйти в бесконечный цикл?

hvladКакую реальную проблему ты не можешь решить ?

Проблема не столько у меня, как у пользователей, особенно не очень разбирающихся, что лежит за прикладным софтом.

Может имеет смысл включать в поставку Engine12.dll не только той разрядности, что и сервер (по аналогии с клиентской частью)?
Тогда, хотя бы, в любом случае удастся установить соединение.

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

Чтобы прикладной софт ставил СУБД, и тем более, чтобы патчил его конфиг - мягко говоря, так себе решение.

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

Ваш ход мыслей - не единственно верный. Надеюсь, вы с этим не будете спорить?

Речь не об Embedded, и наличие админа никто не гарантирует.

Dimitry SibiryakovКлиентская библиотека должна соответствовать разрядности приложения.

При установке сервера - ставятся обе версии (разрядности) клиентских библиотек. Для того, чтобы на этом хосте могли работать приложения обоих разрядностей.
Почему так же не поступать с Engine12.dll?

Т.е. Engine12.dll тянет за собой другие серверные файлы (соответствующей разрядности)? И в таком случае установщику придется ставить 2 инкарнации сервера?

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

Очевидно, для того, чтобы 2 версии клиентов могли работать с сервером (на этом же хосте), который, вообще-то у нас под боком, но почему-то кто-то решил, что лучше заиспользовать Embedded.

Симонов ДенисЕсли ваше приложение хочет встроенную версию сервера

Да, в том-то и дело, что не нужна встроенная версия сервера, при наличии на этом же хосте полноценного сервера.
Я даже не могу представить себе ситуации когда это может понадобится.

Когда приложению нужна встроенная версия - оно само об этом позаботится, и разложит его рядышком - никому не мешая.