Add a UDP listener daemon that runs on the database server, where it
listens for broadcasts and responds with a list of supported
applications and supported databases (kind of like a cross between an
inverse PING and a crippled DNS for your app).

On start up, your app broadcasts on x.x.x.255 (x.x.x is the client
machine's subnet) a message that says, essentially, "Hey, I'm looking
for a Firebird server that supports this app". The firebird server
hardware, running your daemon as well as the Firebird DBMS, responds
with a message that means essentially "Yo bud, I'm over here".

At this point, you have the IP address of the server that supports your
database, based on a real-time positive identification. You could go a
bit further and keep tabs on whether or not Firebird is running, and
essentially report any thing about the server health that you wanted to
before the application even connects.

In Delphi, you could write this readily using the TWSocket components
(twsocket@...) - I would guess about 2 days work for
fundamentals, and another couple of days to make it production ready
(docs, dUnit testing, contingency testing, etc).

In java, most of what you need is encompassed in the core sockets
classes and some textbook examples of less than 100 lines each. I would
guess about 1 day's work for the fundamentals and another couple of days
to make it production ready.


My C skills are a bit rusty, so you're on your own if you're at a C
shop.

On Thu, 2005-04-21 at 17:18 -0700, Chris M wrote:
>
> Adam wrote:
> >
> > Hi Chris,
> >
> > It seems like a lot of work for such a simple problem. This is how we
> > do it, it is practical for us but may or may not be for you.
> >
> > We install in the applications folder an ini file called client.ini
> >
> > It looks something like this:
> >
> > [Firebird Connection]
> > HostName=
> > DatabaseAlias=MyProduct
> > UserName=
> > Password=
> >
> > We tell the customer they need to put the computer name or IP address
> > of their server in the HostName setting.
> >
> > We have a custom Database Connection component that we basically
> > override the create event, and load the hostname and database name
> > into the connection string. If the hostname is empty, we replace it
> > with localhost. If the Alias is empty, we use our standard name. If
> > the username and password are empty, we prompt for it.
> >
> > The other thing that helps is some sort of connection diagnostic
> > program, that uses your ini file and attempts to connect. Based on
> > any exception it received, it can say something like
> >
> > The server "MyServer" was found, but a connection was refused, check
> > the firewall settings allow a connection to port 3050 from this host.
> >
> > or
> >
> > The server "MyServer" did not respond. Please check the host ....
> >
> > etc.
> >
> > Then they can argue with your connection diagnostic program rather
> > than you.
> >
> > I suppose you could use the dns entry to avoid having to do any
> > configuration on the client, but it has never been too much work to
> > copy a simple ini file to the workstation (particularily if it is in
> > the installer).
> >
> > Adam
> >
>
> I am currently using an INI very similar to yours, but they still seem
> to not get the info right, Either the host name is not valid for
> everyone or the IP address is not valid for everyone or something. I
> was just trying to come up with a universal catch all type of thing.
>
> I kind of wish, sometimes, Firebird could broadcast out and say hey i'm
> the firebird server, yoo hoo over here. and then just give it the alias
> name. I still have so much trouble with people typing or putting the
> path in wrong. Its getting better though, this was just a thought.
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>