Commented by: @aafemt

Engine name instead of common prefix would be more useful if several engines co-exist.

Commented by: Sean Leyne (seanleyne)

Why is this required at all?

If you currently use embedded engine/client and try to connect to "C:\db\ mydb.fdb" you will be using the embedded engine, period.

If you specify a host ("localhost:C:\db\ mydb.fdb") or protocol "wnet:C:\db\ mydb.fdb" (does that really work? I have never used) the client will use a remote connection (not the embedded engine).

Commented by: @AlexPeshkoff

wnet://C:\db\mydb.fdb should work

Explicit specification of embedded connection makes sense. In SS mode only one process can attach database (i.e. db file is not shared), and in a case when database is already opened by SS default attachment form (C:\db\mydb.fdb) will be redirected to SS and xnet protocol will be used. If that's not what one wants we must provide explicit embedded attachments.

And yes, Dimitry's suggestion re multiple engines also makes sense in a case when we have some more engines ready to open database (like replication engine for example).

Commented by: @hvlad

> And yes, Dimitry's suggestion re multiple engines also makes sense
It requires application to know exact engine name, which is not possible in many cases.
It is engine's task to know if it could open given database, not app's.

Commented by: @abzalov

Embedded should not be the default protocol - since this is not at all obvious and is fraught with.
What for if on the same host there is a high-grade server?