Hi Nico,
Thank you for your answer.
>It's obvious from the function prototype (no DLL/DSO file name
>argument).
Yes, of course. I'm not confusing a string holding a filename and a
function pointer!
>However, you can use sqlite3_load_extension() instead per-DB connection,
>OR, you can even do the dlopen(DSO)/dlsym(handle,
>"sqlite3_extension_init")
>(or Windows equivalent) yourself to get the xEntryPoint argument for
>sqlite3_auto_extension().
Here's what I'm doing from within my extension. First, remember that
my problem is having extensions loaded for use with a 3rd-party
manager. I can't modify the code of this program, the only code I can
act upon is the .dll extension itself. sqlite3_auto_extension gets
called indirectly thru a select statement to have the default entry
point (sqlite3_extension_init) called.
select load_extension('filename.dll');
Here's a snippet of my code:
// my registration code
DLL_EXPORT int jcdext_init(sqlite3 *db){
...
// register functions with sqlite3_create_function(...)
}
DLL_EXPORT int sqlite3_extension_init(
sqlite3 *db,
char **pzErrMsg,
const sqlite3_api_routines *pApi
){
SQLITE_EXTENSION_INIT2(pApi)
return sqlite3_auto_extension((void*)jcdext_init);
}
At first I thought that the registration code wasn't invoked but it is.
The catch is that SQLite is still executing a SELECT statement; that
must be the reason why, when overloading existing functions (like,
upper, lower, nocase, ...), I receive a return code = SQLITE_BUSY.
New (proprietary) functions register without problem but only for the
current DB connection: they remain invisible to new connections
(althought having been registered using auto_extension).
What should I try next?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
