[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]