0

I have a vague recollection that Firebird's isql utility will in some situations make an exclusive connection to the database, meaning that any other connection attempts will be refused.

I fail to find information about this.

Can anyone explain in which situations this happens, and in particular how I can make sure it does NOT happen?

My intended usage is to execute some commands/queries in a scheduled task, and I don't want to run the risk of blocking other database work while this task is executing.

From a few simple tests it seems like I get an exclusive connection, i.e. no other connections are allowed, when there are no other connections present. Conversely, if there are other connections when isql connects, isql's connection doesn't block other connections.

I tested this with Firebird 3.0.4 in superserver mode and FlameRobin, using the same database alias for both isql and FlameRobin connections. The alias is defined with an absolute local file path.

Should I include host and port to ensure that isql always connects through the superserver (allowing other connections) rather than opening the file directly (blocking other connections)?

1
  • It should be noted that what actually happens is that isql connects to the database in embedded mode if no host/port is specified and the file is not locked by another process. If isql fails to open the database in embedded mode, it tries a network connection and ends up with e.g. a superserver connection. – Kjell Rilbe Jan 30 '20 at 6:54
1

OK, so further testing seems to indicate that what happens is this:

If the database specified for isql's connection is just a local file path (possibly indirectly via an alias), isql will first attempt to connect by opening the file directly. This would be the kind of connection used for classic (and supeclassic?) mode. So it's not exclusive per se, but incompatible with superserver. If the file is already locked, as would be the case if the superserver has a connection to it, isql will try to connect via the superserver. In this case, the connection will obviously not block any other connections in any way.

So, to make sure other (superserver) connections are never blocked when using isql, isql's command line should specify a TCP/IP connection string, something like this:

isql -u usr -p pwd localhost/3050:MyDBAlias

If a connection string like that is used, other (superserver) connections work just fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.