Hi!
I was thinkin ......
There is a starting point as far as I understand it.
It's gds32.dll on windows and gds shared object on linux.

Using these as starting point saves us some guesswork since
the API calls are documented. I am looking at the API guide right
now together with code like IB_connection.cpp from the cvs.
This code use standard API calls to do the job.

So this is one approach, BUT we would like to loose
the gds api altogether and THAT requires some more info I think.

On the other hand, eliminating interserver and just using a new "interclient"
that speaks to 3050 directly may be good enough.

One source of errors less.

Speaking "3050" using the api guide looks pretty straight forward
and like a "normal" development task.

I don't know........ideas?

//OLAS

Ken Richard wrote:

> I started poking around at a driver that uses GDS32.DLL and it didn't look
> too bad until I got to the SQLDA stuff. I was going to look at the
> possibility of using port 3050, but I am having trouble getting interbase to
> compile so I can use the debugger to figure out how the GDS stuff works. I
> couldn't find any documentation on the protocol other than the code.
>
> -----Original Message-----
> From: David Jencks [mailto:davidjencks@...]
> Sent: Wednesday, April 18, 2001 9:00 AM
> To: IB-Java@yahoogroups.com
> Subject: Re: [IB-Java] Re: Dying connections with interclient
>
> Hi,
> I think you start by figuring out the Firebird C client to server
> communication protocol and writing a java client using it. You can then
> figure out how to make the jdbc calls map to Firebird api calls (this is
> much of what interserver does). Then you can figure out a way to handle
> the DatabaseMetaData stuff (this is most of the rest of what interserver
> does).
>
> ...
>
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/