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 <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? > > > regards > Manoj > _______________________________________________ > 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