[sqlite] Compiling SQLite dll 64 bits in MSVS

Strange. Runs fine here (also Win 7 Pro x64). But version 2.1 may have problems with post-XP OS. Try V2.2 from here: http://www.heise.de/download/dependency-walker.html (German site, but downloads should be easy to spot). But if I remember this right, you need to include the sqlite3.def file

[sqlite] Compiling SQLite dll 64 bits in MSVS

Well, last time I built sqlite3.dll myself was some years ago... I don't remember why we used the .def J Decker schrieb am 05.04.2016 um 23:05: > def files are obsolete. > the instructions include setting SQLITE_API to __declspec(dllexport) > which should do the job... unless there was a typeo >

[sqlite] FOREIGN KEY constraint failed

On 2016/04/05 11:15 PM, Keith Medcalf wrote: > Are we confusing immediate constraints (checked per statement) with DEFERRED > constraints (checked at COMMIT time) again? > We might be - though I assume the OP implicated only deferred constraints - since immediate constraints will fail on

[sqlite] Compiling SQLite dll 64 bits in MSVS

Haven't I got that here: > Additional Options: > > sqlite3.c /Gz -DSQLITE_API=__declspec(dllexport) Or should I leave the D off before SQLITE_API ? RBS On Tue, Apr 5, 2016 at 11:04 PM, J Decker wrote: > On Tue, Apr 5, 2016 at 2:09 PM, Bart Smissaert > wrote: > > I am not using .def

[sqlite] sqldiff nowadays

On 23 March 2016 at 15:53, Alek Paunov wrote: > Hi MM, > > Sorry for the late replay - I usually manage to check the list only once a > day :-(. > > On 2016-03-22 16:05, MM wrote: > ... > > If, by chance, you are on something Fedora based, I could give you some >>> hints how to help our lead

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

Recently, I am reading the source code of SQLite. I found that on OS level, SQLite use file lock to solve multi-processes problem and use VFS to solve multi-threads problem. But all of them might failed with racing and SQLite will return a SQLITE_BUSY result code to make it sleep-and-retry. I

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

On 6 Apr 2016, at 5:03am, sanhua.zh wrote: > I found that on OS level, SQLite use file lock to solve multi-processes > problem and use VFS to solve multi-threads problem. But all of them might > failed with racing and SQLite will return a SQLITE_BUSY result code to make > it sleep-and-retry.

[sqlite] Compiling SQLite dll 64 bits in MSVS

The top right pane shows which entry points are actually imported by the importing module. Since the top level module is not imported by anything the "imports" Pane is empty. About name decoration please see https://msdn.microsoft.com/en-us/library/56h2zst2.aspx Bart Smissaert schrieb am

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

You are hopefully aware of the fact that SQLite associates type with the actual values and not the containers(columns) used to hold these values? This means that a data object of any type may be held/returned in a column, irrespective of the declared type (which, for expressions, is NULL).

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

sanhua.zh wrote: > in the unixLock, we can use F_SETLKW instead of F_SETLK, so that code > will return immediatly when file unlocked. We have not need to sleep- > and-retry, which may waste our running time. But then SQLite would have no control over the waiting time. It would never do to wait

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

You don?t understand what I mean. busy_timeout is also not the best solution. It can not know the exactly time when other handles unhold the lock. But lock and wait until other handles unhold the lock, it will restart immediatly. I just wonder why SQLite do so. ???:Simon

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

SQLite solves well with deadlock. I don?t think it will let it wait infinitely. Can you give me an example how they could be a deadlock. ???:Clemens Ladischclemens at ladisch.de ???:sqlite-userssqlite-users at mailinglists.sqlite.org :2016?4?6?(??)?14:35 ??:Re: [sqlite] Why SQLite use

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

sanhua.zh wrote: > Can you give me an example how they could be a deadlock. If you want to use F_SETLKW, you have to prove that it never deadlocks. Anyway, to can get the same effect with another transaction that never commits. Regards, Clemens

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On 2016-04-05 10:19 AM, Richard Hipp wrote: > This could easily be considered a bug fix rather than a regression. > Please explain why you think it is important to know the "type" of a > column in a view? One should be able to treat a view the same as a base table, not even having to know

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

On 2016/04/06 6:03 AM, sanhua.zh wrote: > Recently, I am reading the source code of SQLite. > I found that on OS level, SQLite use file lock to solve multi-processes > problem and use VFS to solve multi-threads problem. But all of them might > failed with racing and SQLite will return a

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] Compiling SQLite dll 64 bits in MSVS

> About name decoration please see https://msdn.microsoft.com/en-us/library/56h2zst2.aspx Thanks, that was helpful. In the above it says: Note that in a 64-bit environment, functions are not decorated. Not sure what that exactly means as I know that in VBA 64 bits decorated names are used in

[sqlite] FOREIGN KEY constraint failed

On Tue Apr 05, 2016 at 11:56:53PM +0200, R Smith wrote: > > On 2016/04/05 11:15 PM, Keith Medcalf wrote: > >Are we confusing immediate constraints (checked per statement) with > >DEFERRED constraints (checked at COMMIT time) again? > > > > We might be - though I assume the OP implicated only

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

> 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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] Why SQLite use busy-retry but not lock-and-wait?

Thanks for your answering. Actually, I am not trying to do lock-and-wait on file lock level. In my app, all operation is done on single process but different threads. I just want to simulate this using thread lock. So it may not cost too much time to do thread-switching. And thread lock have a

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

> 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

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

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

[sqlite] sqlite error 25 during bind

Hi I am getting following error in this piece of code.. Any idea what could be wrong ? *(25) SQLITE_RANGE* The SQLITE_RANGE error indices that the parameter number argument to one of the sqlite3_bind routines or the column number in one of the

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

Does this mean that you are trying to link the LIB with the OTHER COPY of sqlite into the same application tht is using the DLL, because this sure sounds like what you are doing. In which case the versions are NOT independant processes soince they are both linked to the same process, or to

[sqlite] help with query

Here are my tables specified as... tbl_nm | col1, col2... std_nms | id, nm raw_nms | id, nm nm_pairs | id, std_nms_id, raw_nms_id I'm wondering how to supply a single std_nms.nm and get back a list of pairs i.e. std_nm.nm, raw_nms.nm that reflect each record in nm_pairs with a std_nms_id =

[sqlite] sqlite error 25 during bind

On 6 April 2016 at 12:16, Kumar Suraj wrote: > Hi . . . > Here is table definition and insert statement which is causing this > > #define CREATE_TABLE_DNINDEX "CREATE TABLE IF NOT EXISTS TBL (dn BLOB, > pclassid INTEGER, pkey INTEGER, kindex INTEGER PRIMARY KEY ASC)" > > #define INSERT_DN

[sqlite] help with my query...cracked it!

Orig question Here are my tables specified as... tbl_nm | col1, col2... std_nms | id, nm raw_nms | id, nm nm_pairs | id, std_nms_id, raw_nms_id I'm wondering how to supply a single std_nms.nm and get back a list of pairs i.e. std_nm.nm, raw_nms.nm that reflect each record in nm_pairs with a

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

I have my DLL with my copy of the Sqlite3 source code.. and I compile it and it works fine. I now link in a 3rd party LIB which happens to include it's own copy of Sqlite3 code inside the LIB which isn't exported. So yes -- they're both in the same process (I used the word should in quotes)

[sqlite] help with query

On 6 April 2016 at 12:22, e-mail mgbg25171 wrote: > Here are my tables specified as... tbl_nm | col1, col2... > std_nms | id, nm > raw_nms | id, nm > nm_pairs | id, std_nms_id, raw_nms_id > > I'm wondering how to supply a single std_nms.nm and get back a list of pairs > i.e. std_nm.nm,

[sqlite] help with query

Simon... Yes I forgot the "where sn.nm='std1';" restriction and... also see you've used 2 inner joins. Thank you very much for your thoroughness. It's very much appreciated. > > On 06 April 2016 at 12:41 Simon Davies > wrote: > > > On 6 April 2016 at 12:22, e-mail mgbg25171 >

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

Hello, On 2016-04-06 09:43, Darren Duncan wrote: > On 2016-04-05 10:19 AM, Richard Hipp wrote: >> It seems to me that the most consistent answer is that the "type" of >> columns in a VIEW should always be an empty string. > That's only consistent if you do the same thing with base tables.

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On 04/06/2016 02:13 AM, Hick Gunter wrote: > You are hopefully aware of the fact that SQLite associates type with the > actual values and not the containers(columns) used to hold these values? This > means that a data object of any type may be held/returned in a column, > irrespective of the

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

Hi, Am 06.04.2016 um 15:00 schrieb Cezary H. Noweta: > Hello, > > On 2016-04-06 09:43, Darren Duncan wrote: >> On 2016-04-05 10:19 AM, Richard Hipp wrote: > >>> It seems to me that the most consistent answer is that the "type" of >>> columns in a VIEW should always be an empty string. > >>

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On 4/4/16, Mike Bayer wrote: > The "type" column in PRAGMA table_info() is now a blank string when the > target object is a view in 3.12.0. In 3.11.0 and prior versions, the > typing information is returned, > I think the problem is fixed by this checkin:

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

+1 for INFORMATION SCHEMA ! > Wed Apr 06 2016 04:18:10 PM CEST from "Michael Schlenker" > Subject: Re: [sqlite] regression in 3.12.0 vs. >3.11.0,column type information in PRAGMA missing > > > btw. would be nice to have an INFORMATION SCHEMA style view for this > info instead of a pragma. >

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

Hello, On 2016-04-06 16:33, Richard Hipp wrote: > On 4/4/16, Mike Bayer wrote: >> The "type" column in PRAGMA table_info() is now a blank string when the >> target object is a view in 3.12.0. In 3.11.0 and prior versions, the >> typing information is returned, > I think the problem is fixed by

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On 2016-04-06 6:00 AM, Cezary H. Noweta wrote: > On 2016-04-06 09:43, Darren Duncan wrote: >> On 2016-04-05 10:19 AM, Richard Hipp wrote: > >>> It seems to me that the most consistent answer is that the "type" of >>> columns in a VIEW should always be an empty string. > >> That's only consistent

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On Tue, 5 Apr 2016 13:19:50 -0400 Richard Hipp wrote: > CREATE TABLE t2(w SHORT INT, x DECIMAL, y BIGINT, z REAL); > CREATE VIEW v3 AS SELECT w+x+y+z FROM t2; > > What should "PRAGMA table_info('v3')" report as the column type? It should report it as for a table, with values consistent

[sqlite] regression in 3.12.0 vs. 3.11.0, column type information in PRAGMA missing

On Wed, 6 Apr 2016 06:13:01 + Hick Gunter wrote: > You are hopefully aware of the fact that SQLite associates type with > the actual values and not the containers(columns) used to hold these > values? This means that a data object of any type may be > held/returned in a column, irrespective

[sqlite] Possible bug in SQLite in sqlite3VdbeSorterInit for PMA sorter size

I am using the option to set the main cache size *PRAGMA **schema.**cache_size = -**kibibytes**;* In function sqlite3VdbeSorterInit it seems that the calculation of mxCache does not take into account the above alternate way to set cache_size that uses the *-**kibibytes* option.