[sqlite] Problem with sqlite3_db_filename

2015-10-07 Thread Bart Smissaert
As I understand it this should produce a filepointer to the filepath of the
attached database, given the database handle of file the other database was
attached to and the database name of the attached database. I checked all
the return values and also did a select involving tables in both
databases and all goes fine, so I can be sure that the other database is
attached OK.
All I get from sqlite3_db_filename is zero, so no valid file pointer. No
error messages though.

I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
in VBA here.

Any suggestions what could be the problem?

I am running 3.8.11.1

RBS


[sqlite] Problem with sqlite3_db_filename

2015-10-08 Thread Dan Kennedy
On 10/08/2015 03:51 AM, Bart Smissaert wrote:
> As I understand it this should produce a filepointer to the filepath of the
> attached database, given the database handle of file the other database was
> attached to and the database name of the attached database. I checked all
> the return values and also did a select involving tables in both
> databases and all goes fine, so I can be sure that the other database is
> attached OK.
> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
> error messages though.
>
> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
> in VBA here.
>
> Any suggestions what could be the problem?
>
> I am running 3.8.11.1
>

The program below works here.

I'm seeing full paths for databases "main" and "aux", and a zero-length 
nul-terminated string for "next" (the in-memory database).

Dan

-



#include 
#include 
#include 

int main(int argc, char **argv){
   int rc;
   sqlite3 *db;

   rc = sqlite3_open("test.db", &db);
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));

   return 0;
}



[sqlite] Problem with sqlite3_db_filename

2015-10-08 Thread Bart Smissaert
OK, thanks, at least I know that the function works fine then in
sqlite3.dll.
Problem must be on my side then.

This is the code in the Std_Call dll:

SQLITE3_STDCALL_API const char * __stdcall sqlite3_stdcall_db_filename(sqlite3
*pDb, const char *zDbName)
{
return sqlite3_db_filename(pDb, zDbName);
}

And this is the Declare in VBA:

Public Declare Function sqlite3_stdcall_db_filename Lib "SQLite3_StdCall"
Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
lPtrAttachedDBName As Long) As Long

Anything wrong with either of these?


RBS




On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy  wrote:

> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
>
>> As I understand it this should produce a filepointer to the filepath of
>> the
>> attached database, given the database handle of file the other database
>> was
>> attached to and the database name of the attached database. I checked all
>> the return values and also did a select involving tables in both
>> databases and all goes fine, so I can be sure that the other database is
>> attached OK.
>> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
>> error messages though.
>>
>> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
>> in VBA here.
>>
>> Any suggestions what could be the problem?
>>
>> I am running 3.8.11.1
>>
>>
> The program below works here.
>
> I'm seeing full paths for databases "main" and "aux", and a zero-length
> nul-terminated string for "next" (the in-memory database).
>
> Dan
>
> -
>
>
>
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv){
>   int rc;
>   sqlite3 *db;
>
>   rc = sqlite3_open("test.db", &db);
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
>
>   return 0;
> }
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


[sqlite] Problem with sqlite3_db_filename

2015-10-08 Thread Bart Smissaert
Ignore this as I know what the problem was.
I was passing a pointer to the Unicode string, but should be pointer to
8bit ASCII string.

RBS

On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert 
wrote:

> OK, thanks, at least I know that the function works fine then in
> sqlite3.dll.
> Problem must be on my side then.
>
> This is the code in the Std_Call dll:
>
> SQLITE3_STDCALL_API const char * __stdcall sqlite3_stdcall_db_filename(sqlite3
> *pDb, const char *zDbName)
> {
> return sqlite3_db_filename(pDb, zDbName);
> }
>
> And this is the Declare in VBA:
>
> Public Declare Function sqlite3_stdcall_db_filename Lib "SQLite3_StdCall"
> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
> lPtrAttachedDBName As Long) As Long
>
> Anything wrong with either of these?
>
>
> RBS
>
>
>
>
> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy  wrote:
>
>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
>>
>>> As I understand it this should produce a filepointer to the filepath of
>>> the
>>> attached database, given the database handle of file the other database
>>> was
>>> attached to and the database name of the attached database. I checked all
>>> the return values and also did a select involving tables in both
>>> databases and all goes fine, so I can be sure that the other database is
>>> attached OK.
>>> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
>>> error messages though.
>>>
>>> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
>>> in VBA here.
>>>
>>> Any suggestions what could be the problem?
>>>
>>> I am running 3.8.11.1
>>>
>>>
>> The program below works here.
>>
>> I'm seeing full paths for databases "main" and "aux", and a zero-length
>> nul-terminated string for "next" (the in-memory database).
>>
>> Dan
>>
>> -
>>
>>
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char **argv){
>>   int rc;
>>   sqlite3 *db;
>>
>>   rc = sqlite3_open("test.db", &db);
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
>>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
>>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
>>
>>   return 0;
>> }
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>


[sqlite] Problem with sqlite3_db_filename

2015-10-09 Thread Bart Smissaert
All working fine now, but noticed that for the attached database I get not
just the file path of the attached database, but also the journal
file path and wal file path:

C:\Test\NewDB2.db3C:\Test\NewDB2.db3-journalC:\Test\NewDB2.db3-wal

There is actually no journal file or wal file that I can see in that folder.

For main I only get the file path of that main database.

Is this behaviour as expected?
Is it documented somewhere?


RBS



On Thu, Oct 8, 2015 at 5:18 PM, Bart Smissaert 
wrote:

> Ignore this as I know what the problem was.
> I was passing a pointer to the Unicode string, but should be pointer to
> 8bit ASCII string.
>
> RBS
>
> On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert 
> wrote:
>
>> OK, thanks, at least I know that the function works fine then in
>> sqlite3.dll.
>> Problem must be on my side then.
>>
>> This is the code in the Std_Call dll:
>>
>> SQLITE3_STDCALL_API const char * __stdcall 
>> sqlite3_stdcall_db_filename(sqlite3
>> *pDb, const char *zDbName)
>> {
>> return sqlite3_db_filename(pDb, zDbName);
>> }
>>
>> And this is the Declare in VBA:
>>
>> Public Declare Function sqlite3_stdcall_db_filename Lib "SQLite3_StdCall"
>> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
>> lPtrAttachedDBName As Long) As Long
>>
>> Anything wrong with either of these?
>>
>>
>> RBS
>>
>>
>>
>>
>> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy 
>> wrote:
>>
>>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
>>>
 As I understand it this should produce a filepointer to the filepath of
 the
 attached database, given the database handle of file the other database
 was
 attached to and the database name of the attached database. I checked
 all
 the return values and also did a select involving tables in both
 databases and all goes fine, so I can be sure that the other database is
 attached OK.
 All I get from sqlite3_db_filename is zero, so no valid file pointer. No
 error messages though.

 I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am
 working
 in VBA here.

 Any suggestions what could be the problem?

 I am running 3.8.11.1


>>> The program below works here.
>>>
>>> I'm seeing full paths for databases "main" and "aux", and a zero-length
>>> nul-terminated string for "next" (the in-memory database).
>>>
>>> Dan
>>>
>>> -
>>>
>>>
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main(int argc, char **argv){
>>>   int rc;
>>>   sqlite3 *db;
>>>
>>>   rc = sqlite3_open("test.db", &db);
>>>   if( rc!=SQLITE_OK ){
>>> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
>>> exit(1);
>>>   }
>>>
>>>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
>>>   if( rc!=SQLITE_OK ){
>>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>>> exit(1);
>>>   }
>>>
>>>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
>>>   if( rc!=SQLITE_OK ){
>>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>>> exit(1);
>>>   }
>>>
>>>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
>>>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
>>>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
>>>
>>>   return 0;
>>> }
>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users at mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>
>>
>


[sqlite] Problem with sqlite3_db_filename

2015-10-09 Thread Rowan Worth
Suspect you are running into more VBA<->C issues. The db path, journal path
and wal path are stored sequentially in memory, so if you were to skip the
NUL terminators you'd see all three paths.

But I'm not exactly sure how that might happen without resulting in a
segfault, so I could be missing something.

-Rowan

On 9 October 2015 at 16:18, Bart Smissaert  wrote:

> All working fine now, but noticed that for the attached database I get not
> just the file path of the attached database, but also the journal
> file path and wal file path:
>
> C:\Test\NewDB2.db3C:\Test\NewDB2.db3-journalC:\Test\NewDB2.db3-wal
>
> There is actually no journal file or wal file that I can see in that
> folder.
>
> For main I only get the file path of that main database.
>
> Is this behaviour as expected?
> Is it documented somewhere?
>
>
> RBS
>
>
>
> On Thu, Oct 8, 2015 at 5:18 PM, Bart Smissaert 
> wrote:
>
> > Ignore this as I know what the problem was.
> > I was passing a pointer to the Unicode string, but should be pointer to
> > 8bit ASCII string.
> >
> > RBS
> >
> > On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert  >
> > wrote:
> >
> >> OK, thanks, at least I know that the function works fine then in
> >> sqlite3.dll.
> >> Problem must be on my side then.
> >>
> >> This is the code in the Std_Call dll:
> >>
> >> SQLITE3_STDCALL_API const char * __stdcall
> sqlite3_stdcall_db_filename(sqlite3
> >> *pDb, const char *zDbName)
> >> {
> >> return sqlite3_db_filename(pDb, zDbName);
> >> }
> >>
> >> And this is the Declare in VBA:
> >>
> >> Public Declare Function sqlite3_stdcall_db_filename Lib
> "SQLite3_StdCall"
> >> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
> >> lPtrAttachedDBName As Long) As Long
> >>
> >> Anything wrong with either of these?
> >>
> >>
> >> RBS
> >>
> >>
> >>
> >>
> >> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy 
> >> wrote:
> >>
> >>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
> >>>
>  As I understand it this should produce a filepointer to the filepath
> of
>  the
>  attached database, given the database handle of file the other
> database
>  was
>  attached to and the database name of the attached database. I checked
>  all
>  the return values and also did a select involving tables in both
>  databases and all goes fine, so I can be sure that the other database
> is
>  attached OK.
>  All I get from sqlite3_db_filename is zero, so no valid file pointer.
> No
>  error messages though.
> 
>  I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am
>  working
>  in VBA here.
> 
>  Any suggestions what could be the problem?
> 
>  I am running 3.8.11.1
> 
> 
> >>> The program below works here.
> >>>
> >>> I'm seeing full paths for databases "main" and "aux", and a zero-length
> >>> nul-terminated string for "next" (the in-memory database).
> >>>
> >>> Dan
> >>>
> >>> -
> >>>
> >>>
> >>>
> >>> #include 
> >>> #include 
> >>> #include 
> >>>
> >>> int main(int argc, char **argv){
> >>>   int rc;
> >>>   sqlite3 *db;
> >>>
> >>>   rc = sqlite3_open("test.db", &db);
> >>>   if( rc!=SQLITE_OK ){
> >>> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
> >>> exit(1);
> >>>   }
> >>>
> >>>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
> >>>   if( rc!=SQLITE_OK ){
> >>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> >>> exit(1);
> >>>   }
> >>>
> >>>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
> >>>   if( rc!=SQLITE_OK ){
> >>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> >>> exit(1);
> >>>   }
> >>>
> >>>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
> >>>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
> >>>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
> >>>
> >>>   return 0;
> >>> }
> >>>
> >>> ___
> >>> sqlite-users mailing list
> >>> sqlite-users at mailinglists.sqlite.org
> >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>>
> >>
> >>
> >
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


[sqlite] Problem with sqlite3_db_filename

2015-10-09 Thread Graham Holden


[sqlite] Problem with sqlite3_db_filename

2015-10-09 Thread Bart Smissaert
Thanks for that. Must indeed be a C > VBA problem and will sort this out.

RBS

On Fri, Oct 9, 2015 at 9:52 AM, Rowan Worth  wrote:

> Suspect you are running into more VBA<->C issues. The db path, journal path
> and wal path are stored sequentially in memory, so if you were to skip the
> NUL terminators you'd see all three paths.
>
> But I'm not exactly sure how that might happen without resulting in a
> segfault, so I could be missing something.
>
> -Rowan
>
> On 9 October 2015 at 16:18, Bart Smissaert 
> wrote:
>
> > All working fine now, but noticed that for the attached database I get
> not
> > just the file path of the attached database, but also the journal
> > file path and wal file path:
> >
> > C:\Test\NewDB2.db3C:\Test\NewDB2.db3-journalC:\Test\NewDB2.db3-wal
> >
> > There is actually no journal file or wal file that I can see in that
> > folder.
> >
> > For main I only get the file path of that main database.
> >
> > Is this behaviour as expected?
> > Is it documented somewhere?
> >
> >
> > RBS
> >
> >
> >
> > On Thu, Oct 8, 2015 at 5:18 PM, Bart Smissaert  >
> > wrote:
> >
> > > Ignore this as I know what the problem was.
> > > I was passing a pointer to the Unicode string, but should be pointer to
> > > 8bit ASCII string.
> > >
> > > RBS
> > >
> > > On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert <
> bart.smissaert at gmail.com
> > >
> > > wrote:
> > >
> > >> OK, thanks, at least I know that the function works fine then in
> > >> sqlite3.dll.
> > >> Problem must be on my side then.
> > >>
> > >> This is the code in the Std_Call dll:
> > >>
> > >> SQLITE3_STDCALL_API const char * __stdcall
> > sqlite3_stdcall_db_filename(sqlite3
> > >> *pDb, const char *zDbName)
> > >> {
> > >> return sqlite3_db_filename(pDb, zDbName);
> > >> }
> > >>
> > >> And this is the Declare in VBA:
> > >>
> > >> Public Declare Function sqlite3_stdcall_db_filename Lib
> > "SQLite3_StdCall"
> > >> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long,
> ByVal
> > >> lPtrAttachedDBName As Long) As Long
> > >>
> > >> Anything wrong with either of these?
> > >>
> > >>
> > >> RBS
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy 
> > >> wrote:
> > >>
> > >>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
> > >>>
> >  As I understand it this should produce a filepointer to the filepath
> > of
> >  the
> >  attached database, given the database handle of file the other
> > database
> >  was
> >  attached to and the database name of the attached database. I
> checked
> >  all
> >  the return values and also did a select involving tables in both
> >  databases and all goes fine, so I can be sure that the other
> database
> > is
> >  attached OK.
> >  All I get from sqlite3_db_filename is zero, so no valid file
> pointer.
> > No
> >  error messages though.
> > 
> >  I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am
> >  working
> >  in VBA here.
> > 
> >  Any suggestions what could be the problem?
> > 
> >  I am running 3.8.11.1
> > 
> > 
> > >>> The program below works here.
> > >>>
> > >>> I'm seeing full paths for databases "main" and "aux", and a
> zero-length
> > >>> nul-terminated string for "next" (the in-memory database).
> > >>>
> > >>> Dan
> > >>>
> > >>> -
> > >>>
> > >>>
> > >>>
> > >>> #include 
> > >>> #include 
> > >>> #include 
> > >>>
> > >>> int main(int argc, char **argv){
> > >>>   int rc;
> > >>>   sqlite3 *db;
> > >>>
> > >>>   rc = sqlite3_open("test.db", &db);
> > >>>   if( rc!=SQLITE_OK ){
> > >>> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
> > >>> exit(1);
> > >>>   }
> > >>>
> > >>>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
> > >>>   if( rc!=SQLITE_OK ){
> > >>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> > >>> exit(1);
> > >>>   }
> > >>>
> > >>>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
> > >>>   if( rc!=SQLITE_OK ){
> > >>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> > >>> exit(1);
> > >>>   }
> > >>>
> > >>>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
> > >>>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
> > >>>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
> > >>>
> > >>>   return 0;
> > >>> }
> > >>>
> > >>> ___
> > >>> sqlite-users mailing list
> > >>> sqlite-users at mailinglists.sqlite.org
> > >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >>>
> > >>
> > >>
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users at mai

[sqlite] Problem with sqlite3_db_filename

2015-10-09 Thread Bart Smissaert
Thanks, will sort this out.

RBS

On Fri, Oct 9, 2015 at 10:16 AM, Graham Holden 
wrote:

> From memory of VB6, a string returned from a DLL call doesn't have its
> length set - you ideally need the call to return the length and do x$ =
> left$( x$, xlength ) before continuing. If the length isn't available, you
> might be able to search for a zero-byte in VB(A), or you may have to write
> your own C wrapper that returns strlen() of the string.
>
> Graham.
>
>
> Sent from Samsung Mobile
>
>  Original message 
> From: Rowan Worth 
> Date: 09/10/2015  09:52  (GMT+00:00)
> To: General Discussion of SQLite Database <
> sqlite-users at mailinglists.sqlite.org>
> Subject: Re: [sqlite] Problem with sqlite3_db_filename
>
> Suspect you are running into more VBA<->C issues. The db path, journal path
> and wal path are stored sequentially in memory, so if you were to skip the
> NUL terminators you'd see all three paths.
>
> But I'm not exactly sure how that might happen without resulting in a
> segfault, so I could be missing something.
>
> -Rowan
>
> On 9 October 2015 at 16:18, Bart Smissaert 
> wrote:
>
> > All working fine now, but noticed that for the attached database I get
> not
> > just the file path of the attached database, but also the journal
> > file path and wal file path:
> >
> > C:\Test\NewDB2.db3C:\Test\NewDB2.db3-journalC:\Test\NewDB2.db3-wal
> >
> > There is actually no journal file or wal file that I can see in that
> > folder.
> >
> > For main I only get the file path of that main database.
> >
> > Is this behaviour as expected?
> > Is it documented somewhere?
> >
> >
> > RBS
> >
> >
> >
> > On Thu, Oct 8, 2015 at 5:18 PM, Bart Smissaert  >
> > wrote:
> >
> > > Ignore this as I know what the problem was.
> > > I was passing a pointer to the Unicode string, but should be pointer to
> > > 8bit ASCII string.
> > >
> > > RBS
> > >
> > > On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert <
> bart.smissaert at gmail.com
> > >
> > > wrote:
> > >
> > >> OK, thanks, at least I know that the function works fine then in
> > >> sqlite3.dll.
> > >> Problem must be on my side then.
> > >>
> > >> This is the code in the Std_Call dll:
> > >>
> > >> SQLITE3_STDCALL_API const char * __stdcall
> > sqlite3_stdcall_db_filename(sqlite3
> > >> *pDb, const char *zDbName)
> > >> {
> > >> return sqlite3_db_filename(pDb, zDbName);
> > >> }
> > >>
> > >> And this is the Declare in VBA:
> > >>
> > >> Public Declare Function sqlite3_stdcall_db_filename Lib
> > "SQLite3_StdCall"
> > >> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long,
> ByVal
> > >> lPtrAttachedDBName As Long) As Long
> > >>
> > >> Anything wrong with either of these?
> > >>
> > >>
> > >> RBS
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy 
> > >> wrote:
> > >>
> > >>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
> > >>>
> > >>>> As I understand it this should produce a filepointer to the filepath
> > of
> > >>>> the
> > >>>> attached database, given the database handle of file the other
> > database
> > >>>> was
> > >>>> attached to and the database name of the attached database. I
> checked
> > >>>> all
> > >>>> the return values and also did a select involving tables in both
> > >>>> databases and all goes fine, so I can be sure that the other
> database
> > is
> > >>>> attached OK.
> > >>>> All I get from sqlite3_db_filename is zero, so no valid file
> pointer.
> > No
> > >>>> error messages though.
> > >>>>
> > >>>> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am
> > >>>> working
> > >>>> in VBA here.
> > >>>>
> > >>>> Any suggestions what could be the problem?
> > >>>>
> > >>>> I am running 3.8.11.1
> > >>>>
> > >>>>
> > >>> The program below works here.
> > >>>
&g