On Fri, 2 Dec 2005, Luiz Americo Pereira Camara wrote:

> Em Sex, 2005-12-02 às 18:26 +0100, Michael Van Canneyt escreveu:
> >
> > On Fri, 2 Dec 2005, Luiz Americo wrote:
> >
> > >  > De: Michael Van Canneyt <[EMAIL PROTECTED]>
> > >
> > >  >> How about sqliteds?
> > >  >
> > >  > I'm still working on that; I'm using the components for an article,
> > >  > so you can be sure that.
> > >
> > > Fixing it's easy. I can do that.
> > >
> > >  > But there were some more problems with
> > >  > sqliteds. It doesn't recognize VARCHAR fields, for instance.
> > >
> > > This issue was discussed ealier in this list.
> > > See http://article.gmane.org/gmane.comp.ide.lazarus.general/1401
> > >
> > > Anyway i'd like to know your thoughs
> >
> > Well, I have the following SQL
> >
> > CREATE TABLE PUPIL (
> >   PU_ID INTEGER NOT NULL,
> >   PU_FIRSTNAME VARCHAR(50) NOT NULL,
> >   PU_LASTNAME VARCHAR(50) NOT NULL,
> >   CONSTRAINT PUPIL_PK PRIMARY KEY (PU_ID)
> > );
> >
> > And TSQliteDataset doesn't eat
> >
> > SELECT * FROM PUPIL;
> >
> > I fixed TSQLIteDataset already so it works with this and with
> > CHAR(10) definitions as well.
>
> How did you do that?

Check for VARCHAR at the beginning of the type name, and then extract
the declared length.

> I think we can do that, letting the developers aware of the
> inconsistencies i mentioned in the previous post.

You mean that SQLite doesn't actually check the field types against
declaration when inserting/updating, allowing to store 50 characters
in a 10 length field?
This is a problem, and the main reason why I wouldn't use SQLite.

(I'm actually surprised that the SQLite team describes this as a 'feature' !)

>
> To allow this construct is easy. Just do like before, if it does not
> recognizes the field type then treat as a String field, it's safe and
> the code continues simple and clear.

Nono, just recognize all allowed fields. declaring something like
  MyField VarChar
(no length) Is not generally valid SQL.

> As an extension i could rename the field aliases to the most used in SQL
> language. For example, today the alias to a Float field is the string
> FLOAT, but the most used, it seems, is NUMERIC.  The same for MEMO and
> TEXT. This would break existing datafiles but since sqliteds is in early
> development it's acceptable and the tool i wrote could convert easily to
> the new layout.

Why would you want to do that ? I don't see the advantage ?

I mean, I would add support for all field type declarations
that we know SQLite supports, but I wouldn't give any preferred
treatment to any of them.

Michael.

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to