If you really wanted to have stored procedures and did not mind calling them
using a function syntax, you could write your own stored procedure extension.
You'd store them in their own table, write a custom function that evaluates
them and call them something like this: sp("name", param1, param2,...). A
simple recursive-decent parser would likely do the trick to parse and evaluate
the procedures. Depending on your needs, the "stored procedures" could be as
simple as a series of SQL statements to execute, with parameter substitutions,
which would be almost trivial to write. If you were so inclined.
There are good reasons to have stored procedures other than reducing connection
latency - developers like to encapsulate logic that is associated entirely with
the database in the database, use them to do extended checking, to populate
denormalized or derived data, or to provide a level of abstraction, for
instance. Although this code could be put in the client side you may want to be
able to maintain the database independently of the application or you may have
multiple client applications and want to avoid duplicating code in multiple
code bases, for instance.
> On Apr 15, 2017, at 3:57 PM, Manoj Sengottuvel <[email protected]> wrote:
>
> Hi Richard,
>
> Is it possible to create the Stored Procedure (SP) in Sqlite?
>
> if not , is there any alternate way for SP?
>
>
> regards
> Manoj
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
