• Welcome to SQLitening Support Forum.
 

News:

Welcome to the SQLitening support forums!

Main Menu

slRunProc

Started by cj, December 07, 2017, 11:55:27 AM

Previous topic - Next topic

cj

http://sqlitening.com/support/index.php?topic=9690.msg25917#msg25917

Does each function have to be registered?
Are all functions unloaded at once with a single call?
If client crashes does this cause the server to need to be restarted  (see note at bottom of slRunProc in docs.)
slRunProc (rsProcName String, blParm1 Long, blParm2 Long, bsParm3 String, bsParm4 String, [rsModChars String]) Long
Are all the parameters explained somewhere?  The first and last is in slRunProc

Bern Ertl

slRunProc can call server side procedures.  This allows you to write client code that tells the server to do stuff.

I have two libraries for my app:  SQLiteningProcsT.DLL and SQLiteningProcsP.DLL.  The "T" is my "temporary" library.  I call functions in it as needed and do not use the "u" modchar.  The "P" is my "permanent" library.  I load this library at program start and unload it at program end (using "u" and "U" modchars).

Functions in the "T" library can be called with slRunProc as needed.  SQLitening loads, executes and unloads the library.

Functions in the "P" library can be called as needed.  SQLitening just executes the functions (the library is already loaded)

I have a special function in my "P" library ("ICF") to initialize "SQLite custom functions".  SQLite custom functions are functions that can be used within SQL statements (as long as the underlying function for the custom code is available - ie. loaded).  So, client app needs to load the "P" library and keep it loaded (using "u" or "L" modchars) so the underlying code for the SQLite custom functions are available.  I provided a full example of a "P" library with the time stamp code here (substitute "P" for "[letter]":  http://sqlitening.com/support/index.php?topic=3539.msg18054#msg18054

~~~

Does each function have to be registered?

Functions in "T" libraries, that are called with slRunProc in client code do not need to be registered.  SQLite custom functions that are used in SQL statements must be "registered" with sqlite3_create_function().  I created a single function in my "P" library to "register" all my SQLite custom functions, but you could use separate registration functions if you wanted to.  Either way, the "P" library needs be loaded when you attempt to execute an SQL statement that uses one of your SQLite custom functions.

Are all functions unloaded at once with a single call?

You don't really "unload functions".  You unload the ("P") library.  All SQLite custom functions defined with the library that you unload will then not work any more (SQL statement failures so have fun debugging your SQL code if you weren't expecting it).

If client crashes does this cause the server to need to be restarted  (see note at bottom of slRunProc in docs.)

As I understand it, if client app perma loads a "P" library and then crashes, the server won't unload the library.  This doesn't really hurt anything AFAIK.  Maybe it causes the server to tie up whatever resources are used when it loads and maintains a linked (DLL) library, but if your "P" library only contains functions/code that really need to be "permanent", it should be a pretty small footprint.

slRunProc (rsProcName String, blParm1 Long, blParm2 Long, bsParm3 String, bsParm4 String, [rsModChars String]) Long
Are all the parameters explained somewhere?  The first and last is in slRunProc


blParm1, blParm2, bsParm3 and bsParm4 are for you to use and define as needed.  They are passed on to your function in the "P" or "T" library.


cj

That really, really helped.
Thank you!