Hello Philip !
There was this attempt https://www.sqliteconcepts.org/PL_index.html and
I tried to adapt to sqlite3 but the change on the sqlite3 vm compared to
sqlite2 made it a lot harder.
The vm of sqlite3 is not well documented and is changing all the time.
But I also agreed with you if we could have "@variables" at connection
level, query level, trigger level and also be able to write triggers in
"C" (or another glue language), simple stored procedures (queries with
parameters at sql level) life would be a bit easier.
Cheers !
On 19/04/17 08:34, Philip Warner wrote:
There is another reason to have stored procedures: encapsulating logic
across apps/clients.
A great deal can be done in triggers, but not much in terms of queries
or complex parameterized updates.
It would be great, imo, if triggers could have durable local storage
(ie. variables) and if this were built upon to allow stored
procedures, life would be much more fun.
Parameterized multi-query SQL statements returning event just a single
row set would be fine.
On 16/04/2017 2:18 AM, Richard Hipp wrote:
On 4/15/17, Manoj Sengottuvel <smanoj...@gmail.com> wrote:
Hi Richard,
Is it possible to create the Stored Procedure (SP) in Sqlite?
if not , is there any alternate way for SP?
Short answer: No.
Longer answer: With SQLite, your application is the stored procedure.
In a traditional client/server database like PostgreSQL or Oracle or
SQL Server, every SQL statement involves a round-trip to the server.
So there is a lot of latency with each command. The way applications
overcome this latency is to put many queries into a stored procedure,
so that only the stored procedure invocation needs to travel over the
wire and latency is reduced to a single server round-trip.
But with SQLite, each statement is just a procedure call. There is no
network traffic, not IPC, and hence very little latency. Applications
that use SQLite can be very "chatty" with the database and that is not
a problem. For example, the SQLite website is backed by SQLite (duh!)
and a typical page request involves 200 to 300 separate queries. That
would be a performance killer with a client/server database, but with
SQLite it is not a problem and the pages render in about 5
milliseconds.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
