Re: Writing a new driver - Mailing list pgsql-odbc

Atanas Atanasov wrote:

> Deat Shachar Shemesh,
>
> I have got all the stuff from Microsoft i.e. Visual Studio 6.0, 2003
> .NET, 2005 .NET, MSDN, Platform SDK for XP SP2 and 2003 Server.
> Actually I am not really sure whether I need an ODBC driver exactly or
> not. My aim is this. I have a not very popular DBMS which doesn't
> support any king of external interface except its own integrated language.
>
Is it an SQL one? Does it support things such as updateable cursors?

> Actually there is a DLL which can be used but the programming with it
> id not very easy, i.e. it resembles more an API (like ODBC API) but
> not the modern toold like ADO etc.
>
ADO contains no direct database interactions. It's just a wrapper around
ODBC or OLE DB. Either technologies will give you ADO support.

> So it is possible to program with it but it takes quite, some time. My
> aim is to create a sort of bridge between this dll ot the dbms
> directly, so that it will allow me to use it with ADO from ASP and
> Visual Basic.
>
That's exactly what the existing drivers for Postgres do. In ODBC the
backend API is directly implemented, while in PgOleDb libpq is used, but
either way, they are pretty much just adapting layers between what
PostgreSQL can do and what the driver is expected to know how to do.

> I am not sure whether I need exactly an ODBC driver. It might be
> something else but the end result should be an simplified interfacing
> model through ADO (or could be DAO as well, but preferably ASP).
>
Either ODBC or OLE DB will give you that (ADO, DAO and ASP). There are
some considerations as to what's preferable, but those no one can help
you without knowing a little more on what you're trying to do.

> So regarding the driver itself, I read that it should, kind of,
> redefine a set of standard functions in a DLL and that all tha info I
> have. All I need is a very simple driver which read from text files
> from example. I saw the many open source drivers available, but at
> this stage they are of no use, due to a number of reasons. First they
> are definitely involved with the internal structure of the sql server
> (mysql, psql, msql etc), and secondlt the source is for multiplatform.
> So all I am seeing is a lot of source without any logical connection
> or at least sort of explanation from where to start from. I need loke
> a step by step tutorial in creatin ga driver.
>
There should be examples in the MS site. In any case, what's the DBMS?
Is it open source?

> If you think that the problem is solvable otherwise, please suggest
> something.
>
No, a driver is what you need. I think, though, you are expecting it to
be easy. Don't. Figuring out what the APIs mean is a non-trivial task. I
tend to think that it's less trivial for OLE DB than for ODBC, but maybe
it's just because I am doing the former and haven't tried the later
beyond shallow maintaining. There are other differences, performance
being a major one. OLE DB is expected to return all the results at once,
yielding slightly better performance. Still, if you are going to go for
developing this on your own, pick whatever works best for you.

I don't think that the existing drivers are too multi-platform. They are
built around the particular databases' semantics, because that's what a
driver is. Still, they should prove a fairly good starting point,
ASSUMING THE LICENSE IS RIGHT. I can't stress this point enough. If you
can't afford for the resulting driver to be open source, don't use any
of the open source drivers. At least PostgreSQL's and MySQL's are under
a copyleft license, which means you are not allowed to use them without
releasing the resulting code as open source yourself. Don't be a
copyright violator. If you can't open source the resulting code, don't
use anything that is GPL or LGPL.

One last word of advice. If you need this for a commercial reason,
consider hiring someone who's already been there. Driver development
takes a lot of patience and reading through docs trying to understand
the semantics of the API. Much more so than writing code that uses that
very same API. You are seeing this already - the docs we pointed you to
are the docs we work by. There is nothing more. It will usually be much
simpler, probably cheaper, definitely faster, to use a commercial body
to develop it for you. Pick someone who has already done this sort of
development in the past. Like I said earlier, Lingnu is good candidate
for OLE DB drivers, but we won't do an ODBC one. Haven't before, and
there are others who'll probably do it better.

          Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/