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