Dear Igor,
Thank you _so_ much for comforting hat part of the idea I have in mind. I have another related question and I hope you or some other guru can point me towards a solution. I use SQLite from some interpreted script language under XP (yes I know). Today's PCs are fast enough to allow even significantly large apps to be written this way. I need to make use of some extension, like user-defined collating functions and things like that. I can write and debug it, compile it as a dll, register it within the SQLite dll and use it from my scripting language. So far so good. But now I face a problem when I want my users to employ a third-party SQLite manager to do something useful with my base (except basic SELECTs), just because the third-party application is unaware of my specific extension(s). Either the third-party manager has to come up with some way of allowing my users to issue C calls (geez!) to SQLite dll in order to invoke sqlite3_auto_extension() under the hood so that every db connection in this session will use my extension(s). Either _users_ will have to invoke "select sqlite3_load_extension(...)" for _each_ extension individually and repeat this for _each_ DB connection in the session! Both solutions are irrealistic, horribly tedious and particularly error-prone. I'm not even sure that sqlite3_auto_extension is able to register dll entry point(s): the docs mentions "statically linked extension". I'm not complaining, because SQLite is a very "nice, small, fast, reliable, free: choose any five" software, but it should consider the situation of applications that are not compiled with the SQLite code, i.e. not able to invoke C calls as they would like to. Third-party SQLite managers are a good exemple. So what is the solution in such case? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
