One reason might be that SQLite does not usually include anything that
can be just as well implemented externally.
I could be missing something, because I'm not really sure of the advantages
of stored procedures, but it seems to me that an implementation could be
created without modifying SQLite itself.
--- Lloyd Dupont <[EMAIL PROTECTED]> wrote:
> I'm not sure it's a real justification
> I believe that stored procedure are more than convenience to do avoid
> multiple client-serveur call
>
> For exemple lately I wanted to created to related table (kind of
> MASTER_TABLE, PROPERTY_TABLE)
> property should be destroyed/created with master record.
> I used trigger for that.
> But I read once that TRIGGER are evil. And I do feel it, when I write my
> INSERT in MASTER_TABLE, it's quite easy to forget that that a record is
> created as well in PROPERTY_TABLE (with some link ID updated in both table).
> Whereas a stored Procedure would have enable me to clearly look at the whole
> procedure as one single operation.
>
> ----- Original Message -----
> From: "Jay Sprenkle" <[EMAIL PROTECTED]>
> To: <sqlite-users@sqlite.org>
> Sent: Wednesday, June 15, 2005 12:40 AM
> Subject: Re: [sqlite] stored procedures
>
>
> >> BTW I wonder why SQLite doesn't support Stored Procedure.
> >> Through Trigger it does already support some similar functionality.
> >> Certainly, while writing trigger code it won't have been that much code
> >> to
> >> write stored procedure code as well.....
> >> That kind of puzzle me.. is there any rationale for the lack of stored
> >> procedure?
> >
> > Stored procedures are code run by the server. There isn't a server with
> > SQLite.
> > SQLite is a database file structure that uses SQL to access it.
> >
>
>
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
