[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: KDatabase for KOffice
From: Mike Richardson <mike () quaking ! demon ! co ! uk>
Date: 2001-11-02 12:26:46
[Download RAW message or body]
On Thursday 01 November 2001 2:20 pm, Shawn Gordon wrote:
> At 03:50 AM 11/1/2001, you wrote:
> >So you will stick with KDB even with Qt3.0 ?
>
> I'm telling you, we really really tried to use QtSQL, it just doesn't cut
> it.
This is really true. We (theKompany) went round the loop several times on
this, and you just can't write a general-purpose database front end on top of
QT-SQL.
Note "general purpose". If you are designing the app and the database
back-end at the same time, so that the app "knows" everything about the
back-end (in the sense of the table definitions and what-not), the QT-SQL is
probably OK, if rather limiting.
For a "general purpose" front-end (like say Rekall or - cough - Access(tm))
it just won't do. Basically, QT-SQL just does not tell you enough about the
back end. If you think we're wrong, here is a challenge:
Write a program which can be pointed at an arbitrary table in an arbitrary
database (OK for which there is a QT-SQL driver), which can insert a new row
into the table and - this is the important bit - retrieve and then update
that row. Make this work whether or not the table has a primary key or not,
whether or not it has "serial" (eg MySQL auto-increment) columns, and whether
or not there are row insertion triggers in the database which can modify
inserted values.
Mike
aka Mr. Rekall
--
mike@quaking.demon.co.uk
http://www.quaking.demon.co.uk
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic