> Le 6 avr. 2016 ? 11:44, Rail Jon Rogut a
> ?crit :
>
> I'm not at liberty to do that without their permission.. but I can tell you
> that it's only 4 functions and 4 names -- none of which conflict with mine.
...
OK, thanks, I only wanted to check their DLL was not explicitly exporting from
> Le 6 avr. 2016 ? 03:11, Rail Jon Rogut a
> ?crit :
>
> So I statically compile Sqlite3 version 3.8.7.2 into my DLL using /MT
>
> I use
>
> #define SQLITE_THREADSAFE 1
>
> #define HAVE_USLEEP 1
>
> When I use my DLL it works perfectly fine? However...
>
> If I add a 3rd party LIB which
On 6 Apr 2016, at 9:58am, Rail Jon Rogut wrote:
> That I can demonstrate all day long.. but I'd have to show that the issue is
> their library causing the issue, so I'd need to demonstrate the shell
> executing the commands okay without their library attached.
Okay, I misunderstood. I
On 6 Apr 2016, at 9:41am, Rail Jon Rogut wrote:
> I'll have to figure out a method to use the Shell Tools inside my program -
> with the 3rd party DLL linked and running.
I don't mean for production work. I mean you should use it to reproduce your
problem situation. Just use it to open the
QLITE_IOERR_ACCESS with 3rd party DLL
>
> Hi Simon,
>
> Thanks for replying.
>
> To clarify -- if I run this configuration with the 3rd party LIB I get the
> error. If I run my program (DLL) without the 3rd party LIB my database
> works perfectly fine -- so the disk isn't c
On 6 Apr 2016, at 3:28am, Rail Jon Rogut wrote:
> You'll notice I don't get an error at sqlite3_exec() in the open method...
That PRAGMA does not require any file access so the file is still not being
opened. If you want to force file access you could do something like
SELECT rowid FROM
ers-
>> bounces at mailinglists.sqlite.org] On Behalf Of Rail Jon Rogut
>> Sent: Tuesday, 5 April, 2016 21:55
>> To: SQLite mailing list
>> Subject: Re: [sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL
>>
>> Hi Simon,
>>
>> Thanks for replying.
>
On 6 Apr 2016, at 2:59am, Rail Jon Rogut wrote:
> Oh -- and the database opens fine -- it only fails when I try and call
> sqlite3_prepare_v2() to check if a table exists in the database
The sqlite3_open() routines don't actually do any file access at all (most of
the time). They just set
On 6 Apr 2016, at 2:54am, Rail Jon Rogut wrote:
> Yes - these are completely separate databases -- the 3rd party DLL is
> creating a database while it's running. My database is only trying to read
> and failing. The two Sqlite processes 'should' be completely separate -- and
> neither
My DLL dump:
Dump of file C:\yyy\MyVstPlugin.dll
File Type: DLL
Section contains the following exports for MyVstPlugin.dll
characteristics
57043A6D time date stamp Tue Apr 05 15:21:33 2016
0.00 version
1 ordinal base
4 number of functions
No, their library is compiled right into my DLL and when my code is run their
runs simultaneously using their statically linked Sqlite3 code.. while my code
inside the same process (DLL) is attempting to use my statically liked Sqlite3
code at the same time. I cannot use their Sqlite3 code and
I'm not at liberty to do that without their permission.. but I can tell you
that it's only 4 functions and 4 names -- none of which conflict with mine.
Basically it looks something like:
Dump of file C:\Users\admin\Documents\xxx\DevTool.dll
File Type: DLL
Section contains the following
On 6 Apr 2016, at 2:11am, Rail Jon Rogut wrote:
> sql = pragma table_info('mytablename');
> Sqlite3 log: 3338 Err: os_win.c:37516: (0)
> winAccess(C:\MyAppPath\Databases\mydatabase.db-journal) - The operation
> completed successfully.
> Sqlite3 log: 3338 Err: disk I/O error
Presumably you
That I can demonstrate all day long.. but I'd have to show that the issue is
their library causing the issue, so I'd need to demonstrate the shell executing
the commands okay without their library attached.. and then failing with it
attached. For instance if I have my program running with
Thanks.
I should point out that this issue only happens on Windows -- on OSX it's not
an issue.
I'll have to figure out a method to use the Shell Tools inside my program -
with the 3rd party DLL linked and running.
Unfortunately the 3rd party DLL is part of a development tool we have to have
My code is pretty straight forward.. it simply opens the database and tries to
see if a table exists? m_bdbIsOpen and m_bInMemory are both false (so the db
is opened okay). You'll notice I don't get an error at sqlite3_exec() in the
open method...
bool CDatabase::doesTableExist (const
Oh -- and the database opens fine -- it only fails when I try and call
sqlite3_prepare_v2() to check if a table exists in the database
sql = pragma table_info('mytablename');
... it returns with the SQLITE_IOERR_ACCESS error.
So the file exists and is good. If I recompile without the 3rd
Hi Simon,
Thanks for replying.
To clarify -- if I run this configuration with the 3rd party LIB I get the
error. If I run my program (DLL) without the 3rd party LIB my database works
perfectly fine -- so the disk isn't corrupted and the database itself is fine.
It's only while running my
So I statically compile Sqlite3 version 3.8.7.2 into my DLL using /MT
I use
#define SQLITE_THREADSAFE 1
#define HAVE_USLEEP 1
When I use my DLL it works perfectly fine? However...
If I add a 3rd party LIB which also has Sqlite3 version 3.6.23.1 (I believe)
statically linked into it (also
19 matches
Mail list logo
