Just to let you know that I have this all sorted now and that the problem was the fact that sqlite3.dll (the Windows dll) is compiled with the cdecl convention, which is a problem with callbacks back to a VB6 ActiveX dll as that expects std_call convention. Once I compiled sqlite3.dll with std_call convention all was fine. Only one line of code needed to be changed in the amalgation and that was to do with the declaration of fts3CompareElemByTerm. Probably a dumb question but why is that Windows dll not compiled with the std_call convention?
RBS On Wed, Nov 4, 2015 at 7:42 PM, Richard Hipp <drh at sqlite.org> wrote: > On 11/4/15, Bart Smissaert <bart.smissaert at gmail.com> wrote: > > Been trying to get to the bottom of this, but no success. > > Note that with one UDF in the statement all runs perfectly fine. > > Could somebody confirm that they can run 2 UDF's (I have mainly tried > with > > the 2 the same UDF's) in the same SQL and that all > > runs as how it should? Just to make sure there is nothing wrong here with > > SQLite itself. > > > > SQLite does not really distinguish between application-defined > functions and built-in functions. They both work by exactly the same > mechanism. There are probably millions of SQLite queries with > multiple functions running at any given moment in time. > > There are probably thousands of test cases in the SQLite test suite of > queries that use two or more application-defined functions - real > application-defined functions, not built-ins. > > In particular, there are many many test cases of application-defined > functions doing hard things like invoking SQLite recursively. > > -- > D. Richard Hipp > drh at sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >