On the original topic of this post, I don't know of any support for Telnet
protocol for Firebird or InterBase. The options on Windows are TCP/IP or
Named Pipes.

At 10:04 AM 5/08/2004 +1000, Nigel Weeks wrote:

>It appears you're doing a direct file access to the DB - I hope it's on the
>machine you're trying to do this from!
>
>You should always put the server name in the connection string:
>isql -u USER -p PASS "servername:c:/progra...etc.etc.../pos.fdb"
>
>If you mix direct file access, and TCP/IP via servername/path/to/db, you
>will wreck databases!
>
>(Unless things have changed in the last two years...)

It's not so, and never was.

The "Windows path string bug" corrupted databases (and still does with
InterBase and Firebird 1.5 Classic). The conditions where it causes
problems are in the "path" part of the connection string, viz. Windows
recognises both of the following as valid paths:

a) C:data\mydb.fdb
b) C:\data\mydb.fdb

If one connection is made with a path element like a) and another like b),
the InterBase server, or fb_inet_server, doesn't know that they are the
same database, so record versions get managed independently of one another
and irreparable corruption results.

In Firebird 1 the bug was addressed by making the first connection open the
database file with exclusive access. Thereafter, other clients can connect
using the same path element, e.g. a) but clients trying to connect with b)
will be denied access.

In Firebird 1.5, you can still use this method to corrupt databases if
you're using the Classic version.

In all cases, you can have both network and "Windoze-local" (aka IPServer)
connections simultaneously if the path elements match, so e.g. you can run
isql, gbak, gstat etc. locally while remote users are connected, using
matching path elements.

IPServer is handy during development and (to a limited extent) for
knowledgeable SYSDBAs and server-based maintenance services in the
field; and, of course, it's currently the only route for connecting to an
embedded server. As a rule, though, don't treat IPServer as a viable way to
deploy stand-alone end-user applications with Superserver, since it's not
thread-safe and it doesn't support events. Win32 Classic doesn't accept
IPServer connections at all.

/heLen