Hello, Nick!

Thursday, April 11, 2013, 4:06:22 PM, you wrote:

NU> all programs that access the database use the same path component as either
NU> "localhost:/db/mydb.fdb" - if running on the server and
NU> "myhost:/db/mydb.fdb" - if accessing it from elsewhere

no difference.

NU> possible new setup:

NU> all programs that access the database use the same path component as either
NU> "/db/mydb.fdb" - if running on the server and "myhost:/db/mydb.fdb" - if
NU> accessing it from elsewhere

mmm, why ? why to use local protocol? Yes, you can mix connection
strings, but here is another point - what if you will need to move
your applications from server? Will reconfigure connection string for
all of them?

NU> Dmitry has suggested that I should get significant performance improvement
NU> by avoiding the tcp stack but I recall (perhaps wrongly) there being issues
NU> with this approach.

you missed the point that I said about different gbak behavior.

1. gbak -b -g localhost:c:\db\db.fdb localfile.fbk
here backup transfers data from server to localfile via tcp

2. gbak -b -g -se localhost:service_mgr c:\db\db.fdb localfile.fbk
here gbak sends COMMAND to the server (via tcp) to make backup by
itself.
And localfile.fbk - is local to the server, not to gbak.

For better understanding I can add that if you kill gbak
with the first command line, the backup will stop, because gbak did it.

With the second command line backup will still continue, because
after gbak sent command via -se, it only waits for output from the
server, not for the data of the database. And the server does backup,
not gbak.

And, switching protocol for your local
server apps will not give you any visible performance improvement.
Gbak is another thing, it reads (without -se) the whole database.
So, for gbak speed protocol matters.

--
Dmitry Kuzmenko, www.ib-aid.com