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

List:       kde-devel
Subject:    Re: Next generation of KOrganizer / Call for help: (fwd)
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-05-04 17:24:31
[Download RAW message or body]

On Tue, 04 May 1999, Peter Harvey wrote:
>> I know what ODBC is, but could you please compile a small list of the
>> differences between standard ODBC and unixODBC, or are they identical. If yes,
>> I can think of several reasons why we should NOT use ODBC !
>>
>
>Yes. unixODBC is ODBC on UNIX/Linux. It even includes support for some MS extensions.
>
>> Regular ODBC is not flexible enough. It is very difficult to write a small
>> minimal driver since ODBC implementations have to implement all the
>> functionality the spec requires.
>>
>
>Not true. One can write a driver which supports a subset of the functionality in the
>ODBC spec (ie just a few funcs) and get by fine for the vast majority of uses. In
>fact, I do not know of a driver which implements all of the 3.5.1 spec (if they are
>out there then they are few and far between).
>

Well, I am not an ODBC expert... you're probably right. I was just pointing at
the modular approach of OLE DB.

>
>>
>> Today, with LDAP, mail-databases, .... the common functionality is much smaller
>> and more abstract as in ODBC.
>>
>
>Ok. But I can see an ODBC  Driver being created for LDAP but I can not see LDAP being
>used for all db type functions.
>
>>
>> Mapping those non-SQL databases to ODBC is sometimes difficult or impossible.
>
>You bet. Doing the Text File Driver, even to its current/preliminary stage was a big
>job. However, this is the first ODBC File Driver to be LGPL so the stage is almost
>ready for quick development of future file drivers. The final phase of the
>unixODBC Text File driver is to make it into an example of how to use the
>unixODBC infrastructure to create more file drivers (and, of course, server base
>drivers).
>
>

Indeed. ODBC is here, works, and has been used, tested and accepted by the
majority in the industry. So whatever happens, unless something new and working
appears (implemented off course) I think ODBC is the way to go. At least you
can't go really wrong when using ODBC.

I myself am a computer science student (last weeks :-) ) and mostly work in
theoretical computer science (subtyping, F-bounded subtyping, higher order
subtyping) this makes me very vulnerable to good theories, I am not always
interested in implementations. If it looks good on paper it is good for me.
That's way I would propose for a database interface to be a more generalized
object-oriented query service :-) Perhaps it is there when I wake op tomorrow
morning :-) That is if nato doesn't mis-launches some of it's missiles :-)


BDR 

>>
>
>Peter Harvey

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