skywind mailing lists wrote:
> Hi,
>
> according to the documentation this is a slow query for FTS tables:
>
> SELECT * FROM mail WHERE rowid BETWEEN 15 AND 20;
>
> while
>
> SELECT * FROM mail WHERE rowid=15;
>
> is fast.
> As far as I know both queries are fast on normal tables.
> Where is the
> I was very much right!
You are, but in my VB6 code the sqlite3* object is always represented as a
pointer (Long in VB6), so that pointer will then have to be passed ByVal.
> It will if you correct that signature.
Ah, OK, thanks.
> I strongly recommend doing one of those online courses about C.
> If your VB variable contains an sqlite3* then the item should be passed
ByVal.
Ah, yes, thanks for correcting that.
RBS
On Sun, Jan 24, 2016 at 10:18 PM, Keith Medcalf wrote:
>
> > >> I think that unless the argument is going to be altered I have to pass
> > them always ByVal.
> > That wasn'
I have a large table with ~350k records for which I'm in the process of
standardising data. The fields I'm most interested in standardising are
albumartist, artist, performer and composer. I'm dealing with one at a
time and the logic for each is the same. I'll state in advance that I'm a
SQL an
skywind mailing lists wrote:
> this is a slow query for FTS tables:
>
> SELECT * FROM mail WHERE rowid BETWEEN 15 AND 20;
>
> As far as I know both queries are fast on normal tables. Where is the
> difference / what is the reason for the performance difference?
Virtual table modules must implemen
http://www.cdecl.org/
It doesn't work though with complex arguments like this:
void (*xFunc)(sqlite3_context*,int,sqlite3_value**)
which is an argument of sqlite3_create_function_v2
RBS
On Sun, Jan 24, 2016 at 8:12 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>> I think that unless the argument is going to be altered I have to pass
them always ByVal.
That wasn't quite right, eg:
int sqlite3_close(sqlite3*);
sqlite3* is not going to be altered, but I can see that this should be
passed ByRef
> Your rule should be ByVal when there are no '*' and ByRef whe
Hi,
according to the documentation this is a slow query for FTS tables:
SELECT * FROM mail WHERE rowid BETWEEN 15 AND 20;
while
SELECT * FROM mail WHERE rowid=15;
is fast.
As far as I know both queries are fast on normal tables. Where is the
difference / what is the reason for the performanc
> http://www.cdecl.org/
>
> It doesn't work though with complex arguments like this:
> void (*xFunc)(sqlite3_context*,int,sqlite3_value**)
>
> which is an argument of sqlite3_create_function_v2
>
> RBS
It does not do anything at all. It is just a static page with an entry box.
>
> On Su
> >> I think that unless the argument is going to be altered I have to pass
> them always ByVal.
> That wasn't quite right, eg:
> int sqlite3_close(sqlite3*);
> sqlite3* is not going to be altered, but I can see that this should be
> passed ByRef
If your VB variable contains an sqlite3* then the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/01/16 13:12, Bart Smissaert wrote:
>>> I think that unless the argument is going to be altered I have
>>> to pass
> them always ByVal. That wasn't quite right, eg: int
> sqlite3_close(sqlite3*); sqlite3* is not going to be altered, but I
> can se
I have been here many times. As I recall the steps interfacing to COM/IDL
are:
1. Find out what ACTUAL types and ACTUAL calling convention were used by the
DLL you are targeting. The C header file declarations are not definitive:
you need to examine the options used to compile the DLL and often th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/01/16 02:19, Bart Smissaert wrote:
> You didn't mention it but how arguments are called from VB6 is also
> very important, that is ByVal or ByRef. I think that unless the
> argument is going to be altered I have to pass them always ByVal.
Sort o
> The commonest problem is the calling convention.
sqlite3.dll is compiled from the amalgation with std_call calling
convention (/Gz flag).
All the SQLite functions are called with _stdcall from the .tlb, so the IDL
source has that
for every function.
You didn't mention it but how arguments are ca
> That is where you confused me. C also has a long type!
Yes, that is why I said IDL long.
> File byte under "lucky" above.
OK, I can see that and replaced that with int.
What is different though about sqlite3_compileoption_get, so that long in
the IDL causes the mentioned
problems and int doesn
15 matches
Mail list logo
