[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE DB
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-04-11 20:58:52
[Download RAW message or body]

On Sun, 11 Apr 1999, you wrote:
> Bavo De Ridder wrote:
> 
> > Hello,
> > 
> > I am currently working on a KDE DB idl definition. As the name suggests it is
> > based on OLE DB but I have adapted the OLE DB way of doing things to the
> > Unix/Corba way of doing things. It is also based on the Property service.
> > 
> > I will post the first version (very bare and a minimum, designing something like
> > KDE DB is a very complex) in a few days.
> > 
> > In the meantime: are there some developers who would want to get involved in
> > this project? Is there already such a project? What about al those ODBC based
> > projects?
> > 
> 
> Bavo,
> 
> Please have a look at http://orcane.net/freeodbc++ and get in contact with Manush
> about the lib. Though he's in vacation right now i expect him to return these days.
> A CORBA version of this lib is planned and making a wrapper from already existing
> classes is much easier. The libodbc++ is intented to become _the_ ODBC C++ library
> for KDE. There are still frictions with the driver manager and the drivers but \
> we'll surely roll out the stuff within the next month. I want ODBC to be fully \
> integrated into KDE asap. 
> You might like to subscribe the freeodbc mail list also (see \
> http://users.ids.net/~bjepson/freeODBC/index.html) and announce your plans there. \
> I'll leave for a two week vacation on tuesday so i'll be around for discussion of \
> the topic first after my return. 

I do wonder why people keep mixing OLE DB and ODBC. Although both technologies
deal with databases and datasources, there approach is very different.

I myself consider ODBC an old technologie. In the past years, data resided in
one big database. Data outside this database was either duplicated into the
database or not reachable at all. Nowadays, data is seperated in several,
different databases. User information can be found in directory services (or my
customer database is in LDAP). My sales are in a regular sql database and my
correspondance is in a mailbox. How does ODBC deal with these different
datasources? In the beginning, ODBC was only for sql databases. Off course, you
can make a driver look like an sql driver although, in reality, it is a text
file driver. This opens ODBC to these new datasources. But... ODBC wasn't made
to do this. It is hard to implement a very simple address book driver for ODBC.
What if you want to offer users a very lightweight driver, just the
functionality needed for a text driver ? ODBC can't really solve these problems.

What is OLE DB all about? Technically speaking: OLE DB is all about interfaces.
A Session implementation implements a few required interfaces. Besides those,
it can also implement some optional interfaces for extended or more complex
functions. To use these extra functionality (querying for instance), you just
query for the right interface.

Can you build a text file ODBC driver, implementing only 7 functions, and no
querying at all... 


Bavo De Ridder

> Lars


[prev in list] [next in list] [prev in thread] [next in thread]