[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