Subject Re: [IBO] Using a different port to 3050
Author Helen Borrie
At 01:11 AM 10/02/2009, you wrote:
>I'm having difficulty connecting my app to Firebird using a different
>port than 3050.
>I usually don't specify any port when using IBO to connect to a
>Firebird 1.5x database, but a customer is having problems when using
>the default ports. They (and I) have edited Firebird.conf on the
>server to use 3085/3086 as the Service and Aux port respectively. I
>can see firebird listening on 3085, fine so far.
>For my client app, I again edit Firebird.conf which is located in the
>same dir as my app and expect IBO to use those ports, but alas it
>still tries to use 3050.

Add the port to the Server property of your connection object, e.g. where you now have


change it to myhost/3085.

Don't change the Path property nor any alias you have for it in aliases.conf.

>Does IBO make use of the Firebird.conf settings

Of course not. IBO is an interface for client applications. Client apps can't read files on the server. If there's a non-default port configured in firebird.conf, the server will listen that port and the client will have to make sure it attaches through that port.

IB didn't have a default port - in the days of IB and early Firebirds, an entry would be installed in the Services file of the server to map gds_db (the port) as 3050. When deploying clients, you had to put the same entry in the Services file of each client. That was OK in 1985...

For Fb, the service port was defaulted to 3050 at v.1.5, with reconfiguration made available in firebird.conf, to avoid the problem of conflicting with IB or another Firebird service. Read chapter 9 of the v.1.5 release notes.

*** To get this somewhat on-topic for the IBO list *** An improvement for IBO could be to make the port number a defaulted property in the connection object and look for a non-default entry when it constructs the connection string to pass across the API as a parameter for isc_attach_database() . Such a property would not map to the entire parameter (as indeed Server and Path do not: the parameter is a conglomerate of pieces) but it would give a simple way for developers to assign the port statically or, if needed, dynamically via the login dialog or by a late assignment of the DatabasePath property.

BTW, it's not a great idea to use low-numbered ports such as 3085. As a rule, they have long ago been allocated to specific applications (there's a register somewhere) and you have no way to know whether your clients or servers already have those apps in the environment. Chose numbers > 10000, e.g. 13050. The entire range is pretty crowded these days, so be prepared to choose a different number if your deployment tests show that it's already in use (an ISC error 335544365 and/or one or more of inet errors 11004, 10051, 10054, 10061 in the error stack).