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

[Cezary H. Noweta]

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 this checkin:
> https://www.sqlite.org/src/info/fb555c3c2af7f5e6

Perfunctory test showed that it works fine with plain 3.12.0 ([e9bb4cf4] 
Version 3.12.0 (user: drh, tags: trunk, release, version-3.12.0)) --- 
does not require intermediate check--ins.

It goes even farther then 3.11.x because it keeps column's declared type 
when view's column name has changed (CREATE VIEW v(newname) ...). Thank you.

-- best regards

Cezary H. Noweta

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

[sanhua.zh]

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 timeout.
I will do some testing to check whether it isefficient. Thanks for 
youransweringagain.





???:R Smithrsmith at rsweb.co.za
???:sqlite-userssqlite-users at mailinglists.sqlite.org
:2016?4?6?(??)?15:45
??:Re: [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_BUSY result code 
to make it sleep-and-retry.I get confused of this code. Why SQLite use 
lock-and-wait? For example, 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.So I think it 
might be a kind oftrick, but I don?t why SQLite do so. I already find out the 
www.sqlite.org, but it tells nothing about this. Does anybody know why SQLite 
design it so? SQLite is platform independent - i.e. it works on all systems and 
has to make do with what is available everywhere. F_SETLKW is not available on 
all platforms and can't be a standard way for SQLite to interface. You can 
however make your own VFS for SQLite that implements it on Unix systems, if you 
like. This is quite easy. Does F_SETLKW have a timeout? what must SQLite do if 
the file still doesn't become available after a long time? How would this be 
better than the current way? You probably know this already, but the 
lock-checking mechanism is quite efficient, and a locked file gets re-checked 
(if a timeout is specified) very quick, then successively longer and longer 
intervals until the timeout expires. I doubt you will see a great increase in 
lock-situation performance using the file-lock wait cycle - but if you do make 
that VFS, perhaps we could do some testing of the hypothesis. Cheers, Ryan 
___ sqlite-users mailing list 
sqlite-users at mailinglists.sqlite.org 
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[James K. Lowden]

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 of the declared type (which,
> for expressions, is NULL).

Yes, but some of us are careful to include CHECK constraints to enforce
type-checking.  Even when not that careful, many follow the practice of
restricting each column to a single type.  

> What would your date routine do with the string 12.17.9.17.15?

It would never see it.  Problem solved by prevention: 

sqlite> create table T(t TEXT not NULL 
check (strftime('%m', t) is not  NULL)); 

sqlite> insert into  T values ('2016-04-06');
sqlite> insert into  T values ('2016-14-06');
Error: CHECK constraint failed: T
sqlite> insert into  T values ('12.17.9.17.15');
Error: CHECK constraint failed: T

--jkl

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

[James K. Lowden]

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 with how
SQLite will treat the column.  

A fundamental rule for views is that -- for purposes of SELECT -- they
*are* tables.  The fact that tables have physical representation in the
database and views are derived is, er, immaterial to the relational
algebra implemented by the DBMS.  

--jkl

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

[Domingo Alvarez Duarte]

+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.
> 
> Michael
>
>

[sqlite] sqlite error 25 during bind

[Kumar Suraj]

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 sqlite3_column
routines is out of range.

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 "INSERT INTO TBL (dn,pclassid,pkey) VALUES (?,?,?);"

 rv = sqlite3_bind_int(newStmt, 2 , aInClassId);

if (rv != SQLITE_OK)

{

fprintf(stderr, "Error Insert : sqlite3_bind_int, Error code :
%d\n", rv);

sqlite3_finalize(newStmt);

return rv;

}

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

[Michael Schlenker]

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.
> 
>> That's only consistent if you do the same thing with base tables.
> 
> Non--consistency:
[snip]
> 
> Column's affinity is still propagated:
> 
> sqlite> CREATE TABLE b2 AS SELECT * FROM bv;
> sqlite> PRAGMA table_info(b2);
> 0|a|NUM|0||0
> 
> so the point is that ``PRAGMA table_info'' stopped displaying column's
> affinity in case of views.
> 
> On the other side, views are not tables so a consistency does not
> require to preserve that info. In 3.11.x ``PRAGMA table_info'' was not
> displaying an affinity in case of expressions, too:
> 
> === SHELL 3.11.x ===
> sqlite> CREATE VIEW av2 AS SELECT CAST(+a AS NUMERIC) FROM a;
> sqlite> PRAGMA table_info(av2);
> 0|CAST(+a AS NUMERIC)||0||0
> 
> so the decision was to remove that view's info at all.

we have been bitten by this case, e.g. aggregate and expression not
giving any meaningful info for views.

But this change to PRAGMA table_info() throws out the child with the
bathwater in a way.

E.g. we currently try to find the types for a view in a multistage process:

1. Inspect PRAGMA table_info()
2. Look in a special hint table that states the type explicitly via
configuration (e.g. for views with aggregate functions)
3. Select a row with LIMIT 1 and look at the result (fails if the view
is empty).

With the old behaviour, the case 1 would find a reliable result 99% of
the time (for our schema). Now we either have to add additional
configuration just for SQLite (because similar code works fine for
Oracle and MS SQL Server), or hope that case 3 works.

btw. would be nice to have an INFORMATION SCHEMA style view for this
info instead of a pragma.

Michael

-- 
Michael Schlenker
Senior Software Engineer

CONTACT Software GmbH   Tel.:   +49 (421) 20153-80
Wiener Stra?e 1-3   Fax:+49 (421) 20153-41
28359 Bremen
E-Mail: michael.schlenker at contact-software.com
http://www.contact-software.com/

Registered office: Bremen, Germany
Managing directors: Karl Heinz Zachries, Ralf Holtgrefe
Court of register: Amtsgericht Bremen HRB 1321

-- 
Michael Schlenker
Senior Software Engineer

CONTACT Software GmbH   Tel.:   +49 (421) 20153-80
Wiener Stra?e 1-3   Fax:+49 (421) 20153-41
28359 Bremen
E-Mail: michael.schlenker at contact-software.com
http://www.contact-software.com/

Registered office: Bremen, Germany
Managing directors: Karl Heinz Zachries, Ralf Holtgrefe
Court of register: Amtsgericht Bremen HRB 1321

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

[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.

> That's only consistent if you do the same thing with base tables.

Non--consistency:

sqlite> CREATE TABLE a (a DECIMAL(10));
sqlite> CREATE TABLE b AS SELECT * FROM a;
sqlite> CREATE VIEW bv AS SELECT * FROM a;
sqlite> PRAGMA table_info(b);
0|a|NUM|0||0
sqlite> PRAGMA table_info(bv);
0|a||0||0

Info on column's affinity (besides if it is a declared one --- DECIMAL, 
FLOAT --- or a real one --- NUMERIC, REAL) is still useful, when 
comparison is made.

Column's affinity is still propagated:

sqlite> CREATE TABLE b2 AS SELECT * FROM bv;
sqlite> PRAGMA table_info(b2);
0|a|NUM|0||0

so the point is that ``PRAGMA table_info'' stopped displaying column's 
affinity in case of views.

On the other side, views are not tables so a consistency does not 
require to preserve that info. In 3.11.x ``PRAGMA table_info'' was not 
displaying an affinity in case of expressions, too:

=== SHELL 3.11.x ===
sqlite> CREATE VIEW av2 AS SELECT CAST(+a AS NUMERIC) FROM a;
sqlite> PRAGMA table_info(av2);
0|CAST(+a AS NUMERIC)||0||0

so the decision was to remove that view's info at all.

Now, we know that this behavior was changed by an arbitrary, intentional 
decision. We can debate about correctitude of that decision (there are 
pros and cons), however more important thing is to describe the fact in 
the documentation: http://sqlite.org/pragma.html#pragma_table_info: 
``The table named in the table_info pragma can also be a view.'' --- in 
case of views only column's id and name are displayed.

> Alternately, you can exploit the explicit column list that is optional
> in a CREATE VIEW:
>
>CREATE VIEW v3 (foo NUMERIC) AS SELECT w+x+y+z AS foo FROM t2;

Syntax error. Did you mean:

CREATE VIEW v3 (foo) AS SELECT CAST(w+x+y+z AS NUMERIC) FROM t2;

-- best regards

Cezary H. Noweta

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

[sanhua.zh]

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 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 infinitely long in 
case of a deadlock. Regards, Clemens 
___ sqlite-users mailing list 
sqlite-users at mailinglists.sqlite.org 
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[sanhua.zh]

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 Slavinslavins at bigfraud.org
???:SQLite mailing listsqlite-users at mailinglists.sqlite.org
:2016?4?6?(??)?13:31
??:Re: [sqlite] Why SQLite use busy-retry but not lock-and-wait?


On 6 Apr 2016, at 5:03am, sanhua.zh sanhua.zh at foxmail.com 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. 
Use this call https://www.sqlite.org/c3ref/busy_timeout.html To tell SQLite to 
handle backoff-and-retry itself. Simon. 
___ sqlite-users mailing list 
sqlite-users at mailinglists.sqlite.org 
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Andrew Cunningham]

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.



 mxCache = db->aDb[0].pSchema->cache_size;
  if( mxCache<(int)szPma ) mxCache = (int)szPma;
  pSorter->mxPmaSize = MIN((i64)mxCache*pgsz, SQLITE_MAX_PMASZ);

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

[Darren Duncan]

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 if you do the same thing with base tables.
>
> Non--consistency:
>
> sqlite> CREATE TABLE a (a DECIMAL(10));
> sqlite> CREATE TABLE b AS SELECT * FROM a;
> sqlite> CREATE VIEW bv AS SELECT * FROM a;
> sqlite> PRAGMA table_info(b);
> 0|a|NUM|0||0
> sqlite> PRAGMA table_info(bv);
> 0|a||0||0
>
> Info on column's affinity (besides if it is a declared one --- DECIMAL, FLOAT
> --- or a real one --- NUMERIC, REAL) is still useful, when comparison is made.
>
> Column's affinity is still propagated:
>
> sqlite> CREATE TABLE b2 AS SELECT * FROM bv;
> sqlite> PRAGMA table_info(b2);
> 0|a|NUM|0||0
>
> so the point is that ``PRAGMA table_info'' stopped displaying column's 
> affinity
> in case of views.

I agree with you in the sense that CREATE TABLE AS SELECT and CREATE VIEW AS 
SELECT with the same SELECT should produce results with identical type info.

> 
>
>> Alternately, you can exploit the explicit column list that is optional
>> in a CREATE VIEW:
>>
>>CREATE VIEW v3 (foo NUMERIC) AS SELECT w+x+y+z AS foo FROM t2;
>
> Syntax error. Did you mean:
>
> CREATE VIEW v3 (foo) AS SELECT CAST(w+x+y+z AS NUMERIC) FROM t2;

I actually meant what I said, wherein the column list is declared using the 
same 
syntax as one would use for a CREATE TABLE, meaning with types.

However, your use of explicit CAST syntax is possibly a better solution in one 
sense, in that the SELECT itself is completely unambiguous to human readers 
what 
the result type is.  It also fits right in with what I think is the best 
solution, that column type info just is derived from the SELECT expression.

-- Darren Duncan

[sqlite] help with query

[e-mail mgbg25171]

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 
> 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, raw_nms.nm
> > that reflect each record in nm_pairs with a std_nms_id = std_nms.id
> 
> SQLite version 3.8.11.1 2015-07-29 20:00:57
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite>
> sqlite> create table std_nms( id integer, nm text );
> sqlite> create table raw_nms( id integer, nm text );
> sqlite>
> sqlite> create table nm_pairs( id integer, std_nms_id integer,
> raw_nms_id integer );
> sqlite>
> sqlite> insert into std_nms( id, nm ) values( 1, 'std1' ),( 2, 'std2'
> ),( 3, 'std3' );
> sqlite> insert into raw_nms( id, nm ) values( 1, 'raw1' ),( 2, 'raw2'
> ),( 3, 'raw3' );
> sqlite>
> sqlite> insert into nm_pairs( id, std_nms_id, raw_nms_id ) values( 1,
> 1, 1 ),( 2, 2, 2 ),( 3, 3, 3 ),( 4, 1, 3 );
> 
> 
> sqlite> select sn.nm, rn.nm
> from std_nms sn
> inner join nm_pairs nmp on nmp.std_nms_id=sn.id
> inner join raw_nms rn on nmp.raw_nms_id=rn.id
> where sn.nm='std1';
> std1|raw1
> std1|raw3
> 
> Regards,
> Simon
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> 

[sqlite] help with query

[Simon Davies]

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, raw_nms.nm
> that reflect each record in nm_pairs with a std_nms_id = std_nms.id

SQLite version 3.8.11.1 2015-07-29 20:00:57
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>
sqlite> create table std_nms( id integer, nm text );
sqlite> create table raw_nms( id integer, nm text );
sqlite>
sqlite> create table nm_pairs( id integer, std_nms_id integer,
raw_nms_id integer );
sqlite>
sqlite> insert into std_nms( id, nm ) values( 1, 'std1' ),( 2, 'std2'
),( 3, 'std3' );
sqlite> insert into raw_nms( id, nm ) values( 1, 'raw1' ),( 2, 'raw2'
),( 3, 'raw3' );
sqlite>
sqlite> insert into nm_pairs( id,  std_nms_id, raw_nms_id ) values( 1,
1, 1 ),( 2, 2, 2 ),( 3, 3, 3 ),( 4, 1, 3 );


sqlite> select sn.nm, rn.nm
   from std_nms sn
   inner join nm_pairs nmp on nmp.std_nms_id=sn.id
   inner join raw_nms rn on nmp.raw_nms_id=rn.id
   where sn.nm='std1';
std1|raw1
std1|raw3

Regards,
Simon

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

[e-mail mgbg25171]

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 std_nms_id = std_nms.id

(of the record containing the supplied single std_nms.nm).
Thank you in anticipation.


and here's what I came up with...


select std_nms.nm, raw_nms.nm from std_nms,raw_nms
inner join nm_pairs on std_nms.id = nm_pairs.std_nms_id and raw_nms.id =
nm_pairs.raw_nms_id

[sqlite] sqlite error 25 during bind

[Simon Davies]

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 "INSERT INTO TBL (dn,pclassid,pkey) VALUES (?,?,?);"
>
>  rv = sqlite3_bind_int(newStmt, 2 , aInClassId);
>
> if (rv != SQLITE_OK)
>
> {
>
> fprintf(stderr, "Error Insert : sqlite3_bind_int, Error code :
> %d\n", rv);
>
> sqlite3_finalize(newStmt);
>
> return rv;
>
> }

Are you calling sqlite3_prepare_v2 before your call to sqlite3_bind_int?

Regards,
Simon

[sqlite] help with query

[e-mail mgbg25171]

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 = std_nms.id

(of the record containing the supplied single std_nms.nm).
Thank you in anticipation.

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

[sanhua.zh]

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 get confused of this code. Why SQLite use lock-and-wait? For example, 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.


So I think it might be a kind oftrick, but I don?t why SQLite do so. I already 
find out the www.sqlite.org, but it tells nothing about this. Does anybody know 
why SQLite design it so?

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Olivier Mascia]

> 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 itself. Looks fine.

What about your app and DLL? You said it's your DLL which contains the SQLite 
code (compiling sqlite.c amalgamation file). What about your application use of 
those SQLite APIs? Purely local from your DLL or code from your executable also 
calls SQLite APIs (which would be exported from your DLL)? Sorry for asking the 
next obvious question, but your executable is not *also* dynamically linking 
yet another SQLite DLL?

My first thought about your issue was some unexpected shared data structures 
between their SQLite and yours, but I don't clearly see how, for now.

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Olivier Mascia]

> 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 also has Sqlite3 version 3.6.23.1 (I believe) 
> statically linked into it (also using /MT) -- this library opens a database 
> and writes to it while my DLL is running.  While this is happening, I can 
> open my database but I get an SQLITE_IOERR_ACCESS error returned if I call 
> sqlite3_prepare_v2().
> 
> I have an error log callback which generates:
> 
> 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
> 
> The database I'm using is separate from the database running in the 3rd party 
> lib.
> 
> Anyone have any ideas on how to deal with the conflict?
> 
> Thanks,
> 
>   Rail

Could you show the exports of 'their' DLL (using depends.exe for instance)?

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om

[sqlite] FOREIGN KEY constraint failed

[no...@null.net]

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 deferred
> constraints - since immediate constraints will fail on contact, and
> as such, no mystery surrounds their origins.  My assumption might be
> wrong.

There is plenty of mystery around immediate constraints when triggers
are involved. I often have an issue with statements failing with the
generic foreign key message where the actual issue is three or four
trigger levels deep. So I can only add my +1 to the "this is an issue"
position as well as a +1 to "please can we have *some* kind of help."

What I usually end up doing is re-executing the statement with foreign
keys turned off, and then run the foreign_key_check pragma. But it
doesn't always work because if the problem trigger/statement doesn't
fail then later statements sometimes mask the original problem.

So my suggestion would be a development pragma to request that SQLite
does this itself before the transaction gets rolled back, adding the
results of the foreign_key_check to the error message.

Mark
-- 
Mark Lawrence

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

[Richard Hipp]

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:
https://www.sqlite.org/src/info/fb555c3c2af7f5e6

Please confirm.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 thought that you were writing one program calling the 
SQLite API directly, and that it was running at the same time as another 
program you had no control over.  I had meant that the SQLite Shell Tool as the 
'other' program.

So instead, to test this keep your program as it is and use the shell tool to 
have the database open, and having done a SELECT command or something to ensure 
that it really does have the database file open.

Then run your program including the amalgamation source code and have it call 
the SQLite API directly.  That should work.  Then replace the amalgamation 
source code with the 3rd party DLL you've been told to use and see if that 
introduces problems.  If it does you have a small easily-reproduced problem.  
And the code you included in an earlier post is small enough that if they think 
you're doing something wrong they should be able to tell you what they think 
you're doing wrong.

Simon.

[sqlite] Compiling SQLite dll 64 bits in MSVS

[Bart Smissaert]

> 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 declarations
to access functions in a 64 bit dll. I will try the /FAs option to have a
look and see if there are decorated names.


RBS

On Wed, Apr 6, 2016 at 7:06 AM, GB  wrote:

> 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 05.04.2016 um 23:42:
>
>> I said that wrong, even in the old 32 bits Dependency Walker there is nil
>> in the top right pane.
>> Still, there are no decorated function names in the 64 bit dll to see.
>> Is this normal or do I have to alter my command line parameters?
>>
>> RBS
>>
>> On Tue, Apr 5, 2016 at 10:23 PM, Bart Smissaert > >
>> wrote:
>>
>>
>>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 file and execute a SELECT or INSERT 
or something.  If it crashes with 'disk IO error' you've demonstrated the 
problem to the 3rd party developers.  If it doesn't crash you know there's 
something wrong with your own code.

Though it is scriptable from the command line so you /could/ perhaps use it for 
useful things.

Simon.

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

[R Smith]

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_BUSY result code to make 
> it sleep-and-retry.
>
>
> I get confused of this code. Why SQLite use lock-and-wait? For example, 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.
>
>
> So I think it might be a kind oftrick, but I don?t why SQLite do so. I 
> already find out the www.sqlite.org, but it tells nothing about this. Does 
> anybody know why SQLite design it so?

SQLite is platform independent - i.e. it works on all systems and has to 
make do with what is available everywhere. F_SETLKW is not available on 
all platforms and can't be a standard way for SQLite to interface. You 
can however make your own VFS for SQLite that implements it on Unix 
systems, if you like. This is quite easy.

Does F_SETLKW have a timeout? what must SQLite do if the file still 
doesn't become available after a long time? How would this be better 
than the current way?

You probably know this already, but the lock-checking mechanism is quite 
efficient, and a locked file gets re-checked (if a timeout is specified) 
very quick, then successively longer and longer intervals until the 
timeout expires. I doubt you will see a great increase in lock-situation 
performance using the file-lock wait cycle - but if you do make that 
VFS, perhaps we could do some testing of the hypothesis.

Cheers,
Ryan

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

[Mike Bayer]

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 declared type (which, for expressions, is NULL).
>
> What would your date routine do with the string 12.17.9.17.15?


it would raise an exception on the invalid date format, not any 
different from the string->date converters that take effect when you 
enter a date on a web form.

Even though SQLite allows any kind of data to be stored in any row 
regardless of type affinity, in practice, applications typically remain 
faithful to the type of data they plan to store within columns. That is, 
even though SQLite has a dynamic per-row typing model, most of the world 
very much wants it to behave as a drop-in for MySQL or Postgresql and 
their applications assume schemas have fixed datatypes just like all 
other relational databases.



>
> -Urspr?ngliche Nachricht-
> Von: sqlite-users-bounces at mailinglists.sqlite.org 
> [mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Mike 
> Bayer
> Gesendet: Dienstag, 05. April 2016 21:46
> An: sqlite-users at mailinglists.sqlite.org
> Betreff: Re: [sqlite] regression in 3.12.0 vs. 3.11.0, column type 
> information in PRAGMA missing
>
>
>
> On 04/05/2016 01:19 PM, 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,
>>>
>>
>> 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?
>
> As others have noted, in the application space we often use these names as 
> suggestions for how data from such a column is to be handled once
> transmitted outside of the SQLite layer.   The most prominent example is
> date values, where we apply converters on both sides of the data to convert 
> between language-specific date objects and a string representation on the 
> SQLite side.
>
> For example, here is the Python standard library SQLite database adapter:
>
> https://docs.python.org/2/library/sqlite3.html#converting-sqlite-values-to-custom-python-types
>
> In this example, we see the use of the constant sqlite3.PARSE_DECLTYPES, 
> which indicates "parse the name of the declared type delivered by SQLite 
> within a result set, in order to apply a converter".  This specific 
> implementation is parsing the type affinity as delivered in the result set, 
> so is not impacted by this change.  However, other database abstraction 
> systems rely upon the use of so-called "table metadata"
> gathered up front about tables and views in order to know about the datatypes 
> that are expected from particular column names; on SQLite this
> relies upon "pragma table_info()" to collect that information.If
> it's no longer present, such systems would require the user to explicitly 
> state datatypes in the case of views on the application side, or to be 
> modified to rely upon typing information when a result set is received rather 
> than based on the schema of the constructs themselves.
>But like in so many other cases, database-agnostic systems are designed 
> around the way all other relational databases behave, which in this area is 
> that of the "fixed type per-column" model where there's never been an issue 
> knowing the types that will be received from a table or view.  That SQLite 
> also delivers these fields via "pragma table_info()" just made it that much 
> more possible for abstraction layers to emulate similar behavior in SQLite.
>
>
>
>>
>> There are further inconsistencies here.  Example:
>>
>>   CREATE TABLE t1(x INTEGER);
>>   CREATE VIEW v1 AS SELECT x FROM t1;
>>   CREATE VIEW v2(x) AS SELECT x FROM t1;
>>   PRAGMA table_info('v1');
>>   PRAGMA table_info('v2');
>>
>> As of version 3.12.0, the two pragma's give the same answer. but in
>> version 3.11.0, they were different.  Which of the two answers
>> returned by 3.11.0 is correct?
>
> Looking from the perspective of the consuming application, ultimately the 
> INTEGER affinity value is what's delivered so in an ideal world people would 
> expect the answer to be INTEGER.
>
> However I would reiterate the point of my original email, which is that if 
> this change in behavior is intentional, it should be documented in the change 
> notes at http://sqlite.org/releaselog/3_12_0.html ; I've looked through every 
> line item and see none that suggest a change in how PRAGMA behaves with 
> regards to views.  I also notice that there's now a category of change called 
> "Potentially Disruptive Change"; I hope to illustrate here that whether or 
> not the 3.11 or 3.12 behavior is chosen, this 

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

[Clemens Ladisch]

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] Why SQLite use busy-retry but not lock-and-wait?

[Clemens Ladisch]

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 infinitely long in case of a deadlock.


Regards,
Clemens

[sqlite] Compiling SQLite dll 64 bits in MSVS

[GB]

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 05.04.2016 um 23:42:
> I said that wrong, even in the old 32 bits Dependency Walker there is nil
> in the top right pane.
> Still, there are no decorated function names in the 64 bit dll to see.
> Is this normal or do I have to alter my command line parameters?
>
> RBS
>
> On Tue, Apr 5, 2016 at 10:23 PM, Bart Smissaert 
> wrote:
>
>

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Keith Medcalf]

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 both processes.

> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> 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.
> 
> 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 program with the 3rd party DLL
> sqlite database open that I get the error.
> 
> 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 cares about the other so no trying to share code
> or data at all.
> 
> So to summarize...  there's no disk corruption and the databases are fine.
> 
> Thanks,
> 
>   Rail
> -
> 
> On Apr 5, 2016, at 6:43 PM, Simon Slavin  wrote:
> 
> >
> > 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 mean that if you try the same thing and the other program
> isn't running, you get no problem.  And that the problem does occur
> without fail when the other program is running.
> >
> > Also, just because it's so unusual I just want you to restate that these
> two programs are trying to open different databases.  At least that's what
> I understood from your post.
> >
> > Please can you run whatever tools your OS provides for checking disk
> formatting and directory structure, just to ensure that your problem is
> not caused by a corrupt disk.
> >
> > Can you write some code which tries to open the database file(s) just
> using plain file commands (presumably fopen() or something like that) ?
> Does this code also get 'disk I/O error' ?
> >
> > Another thing to try would be to download the SQLite shell tool and try
> using that to open the database instead.  Do you get the same problem ?
> >
> > Simon.
> > ___
> > 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] Why SQLite use busy-retry but not lock-and-wait?

[Simon Slavin]

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.

Use this call



To tell SQLite to handle backoff-and-retry itself.

Simon.

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 myTable LIMIT 1

> The 3rd party are trying to imply it's my code at fault -- but I can't see 
> anything I'm doing wrong.

Instead of using your own code to access the database, download and use the 
SQLite shell tool to execute the same SQL commands.  Just open the file and 
type the commands in.  The shell tool was written by the same team which wrote 
SQLite itself.  It is the canonical demonstration of the right way to do things.

If you can make the shell tool crash report 'disk IO error', you can tell them 
that they're now blaming the SQLite team for doing it wrong, and they will have 
something to investigate which can't be blamed on any code you wrote.

> So you're saying I'm basically screwed :)

Only if you insist on using that 3rd party thing.

Simon.

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

[Hick Gunter]

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).

What would your date routine do with the string 12.17.9.17.15?

-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Mike 
Bayer
Gesendet: Dienstag, 05. April 2016 21:46
An: sqlite-users at mailinglists.sqlite.org
Betreff: Re: [sqlite] regression in 3.12.0 vs. 3.11.0, column type information 
in PRAGMA missing



On 04/05/2016 01:19 PM, 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,
>>
>
> 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?

As others have noted, in the application space we often use these names as 
suggestions for how data from such a column is to be handled once
transmitted outside of the SQLite layer.   The most prominent example is
date values, where we apply converters on both sides of the data to convert 
between language-specific date objects and a string representation on the 
SQLite side.

For example, here is the Python standard library SQLite database adapter:

https://docs.python.org/2/library/sqlite3.html#converting-sqlite-values-to-custom-python-types

In this example, we see the use of the constant sqlite3.PARSE_DECLTYPES, which 
indicates "parse the name of the declared type delivered by SQLite within a 
result set, in order to apply a converter".  This specific implementation is 
parsing the type affinity as delivered in the result set, so is not impacted by 
this change.  However, other database abstraction systems rely upon the use of 
so-called "table metadata"
gathered up front about tables and views in order to know about the datatypes 
that are expected from particular column names; on SQLite this
relies upon "pragma table_info()" to collect that information.If
it's no longer present, such systems would require the user to explicitly state 
datatypes in the case of views on the application side, or to be modified to 
rely upon typing information when a result set is received rather than based on 
the schema of the constructs themselves.
  But like in so many other cases, database-agnostic systems are designed 
around the way all other relational databases behave, which in this area is 
that of the "fixed type per-column" model where there's never been an issue 
knowing the types that will be received from a table or view.  That SQLite also 
delivers these fields via "pragma table_info()" just made it that much more 
possible for abstraction layers to emulate similar behavior in SQLite.



>
> There are further inconsistencies here.  Example:
>
>  CREATE TABLE t1(x INTEGER);
>  CREATE VIEW v1 AS SELECT x FROM t1;
>  CREATE VIEW v2(x) AS SELECT x FROM t1;
>  PRAGMA table_info('v1');
>  PRAGMA table_info('v2');
>
> As of version 3.12.0, the two pragma's give the same answer. but in
> version 3.11.0, they were different.  Which of the two answers
> returned by 3.11.0 is correct?

Looking from the perspective of the consuming application, ultimately the 
INTEGER affinity value is what's delivered so in an ideal world people would 
expect the answer to be INTEGER.

However I would reiterate the point of my original email, which is that if this 
change in behavior is intentional, it should be documented in the change notes 
at http://sqlite.org/releaselog/3_12_0.html ; I've looked through every line 
item and see none that suggest a change in how PRAGMA behaves with regards to 
views.  I also notice that there's now a category of change called "Potentially 
Disruptive Change"; I hope to illustrate here that whether or not the 3.11 or 
3.12 behavior is chosen, this change is definitely "potentially disruptive" and 
should be noted
as such.Or even that this area of behavior could be explicitly
described at http://sqlite.org/datatype3.html ("type affinities do not transfer 
to views at the view definition level").


>
> Or, consider this situation:
>
>  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?

In the case of views propagating type affinities at the definition level, 
ideally we'd take the summation of the type affinities themselves assuming each 
column is populated with a type-compliant data value and return that, which in 
this case would be NUMERIC, since all math operators coerce their values to 
NUMERIC first.


>
> It 

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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) 
but each Sqlite3 block of code is separate.. and there's obviously a conflict 
-- the question is how to address it.  Because they're both in the same process 
is the issue because of static functions and variables.. or something else?  On 
OSX there's no conflict, but on Windows there is.

According to 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.85).aspx 

"The scope of static variables is limited to the block in which the static 
variables are declared. As a result, each process has its own instance of the 
DLL global and static variables by default."

Cheers,

Rail
-

On Apr 6, 2016, at 4:18 AM, "Keith Medcalf"  wrote:

> 
> 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 
> both processes.
> 
>> -Original Message-
>> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
>> 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.
>> 
>> 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 program with the 3rd party DLL
>> sqlite database open that I get the error.
>> 
>> 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 cares about the other so no trying to share code
>> or data at all.
>> 
>> So to summarize...  there's no disk corruption and the databases are fine.
>> 
>> Thanks,
>> 
>>  Rail
>> -

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 up some structures in memory.  The file is actually 
opened by the first SQLite call which needs to read or write them.  So that's 
when you get the access errors.

I consider this a bug but have been told that there's no appropriate way to fix 
it until SQLite4 comes along.

Simon.

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 cares about the other so no trying to share code or data at all.

Then there is a bug.  Either in the 3rd party DLL or in the code which is using 
it.

Simon.

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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
   4 number of names

ordinal hint RVA  name

  10 00761A90 ExitDll
  21 00761370 GetPluginFactory
  32 00761AA0 InitDll
  43 0075EC50 VSTPluginMain

  Summary

   63000 .data
   68000 .pdata
  513000 .rdata
   18000 .reloc
1000 .rsrc
  815000 .text
1000 .tls
3000 _RDATA


As you can see it's a VST DLL.  My DLL only uses the statically linked SQLite 
API's -- the host which runs my DLL doesn't use the Sqlite API's.  I'm not 
linking in any other DLL's or libraries.

Thanks,

Rail
-

On Apr 6, 2016, at 2:57 AM, Olivier Mascia  wrote:

>> 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 itself. Looks fine.
> 
> What about your app and DLL? You said it's your DLL which contains the SQLite 
> code (compiling sqlite.c amalgamation file). What about your application use 
> of those SQLite APIs? Purely local from your DLL or code from your executable 
> also calls SQLite APIs (which would be exported from your DLL)? Sorry for 
> asking the next obvious question, but your executable is not *also* 
> dynamically linking yet another SQLite DLL?
> 
> My first thought about your issue was some unexpected shared data structures 
> between their SQLite and yours, but I don't clearly see how, for now.
> 
> -- 
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om
> 
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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 they can't use mine.

Because they're in the same process -- I suspect the issue is with the static 
variables and functions inside the Sqlite3 code.

Thanks,

Rail
-

On Apr 6, 2016, at 2:20 AM, Simon Slavin  wrote:

> 
> 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 thought that you were writing one program calling 
> the SQLite API directly, and that it was running at the same time as another 
> program you had no control over.  I had meant that the SQLite Shell Tool as 
> the 'other' program.
> 
> So instead, to test this keep your program as it is and use the shell tool to 
> have the database open, and having done a SELECT command or something to 
> ensure that it really does have the database file open.
> 
> Then run your program including the amalgamation source code and have it call 
> the SQLite API directly.  That should work.  Then replace the amalgamation 
> source code with the 3rd party DLL you've been told to use and see if that 
> introduces problems.  If it does you have a small easily-reproduced problem.  
> And the code you included in an earlier post is small enough that if they 
> think you're doing something wrong they should be able to tell you what they 
> think you're doing wrong.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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 exports for DevTool.dll

 characteristics
55B600AC time date stamp Mon Jul 27 02:58:04 2015
0.00 version
   1 ordinal base
   4 number of functions
   4 number of names

ordinal hint RVA  name

  10 000ABC00 DevTool_Function1
  21 000ABCE0 DevTool_Function2
  32 000ABC30 DevTool_Function3
  43 000ABCF0 DevTool_Function4

**

Names and RVA's have been changed for legal reasons.

Thanks,

Rail
-

On Apr 6, 2016, at 2:11 AM, Olivier Mascia  wrote:

>> 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 also has Sqlite3 version 3.6.23.1 (I believe) 
>> statically linked into it (also using /MT) -- this library opens a database 
>> and writes to it while my DLL is running.  While this is happening, I can 
>> open my database but I get an SQLITE_IOERR_ACCESS error returned if I call 
>> sqlite3_prepare_v2().
>> 
>> I have an error log callback which generates:
>> 
>> 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
>> 
>> The database I'm using is separate from the database running in the 3rd 
>> party lib.
>> 
>> Anyone have any ideas on how to deal with the conflict?
>> 
>> Thanks,
>> 
>>  Rail
> 
> Could you show the exports of 'their' DLL (using depends.exe for instance)?
> 
> -- 
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om
> 
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Simon Slavin]

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 mean that if you try the same thing and the other program isn't 
running, you get no problem.  And that the problem does occur without fail when 
the other program is running.

Also, just because it's so unusual I just want you to restate that these two 
programs are trying to open different databases.  At least that's what I 
understood from your post.

Please can you run whatever tools your OS provides for checking disk formatting 
and directory structure, just to ensure that your problem is not caused by a 
corrupt disk.

Can you write some code which tries to open the database file(s) just using 
plain file commands (presumably fopen() or something like that) ?  Does this 
code also get 'disk I/O error' ?

Another thing to try would be to download the SQLite shell tool and try using 
that to open the database instead.  Do you get the same problem ?

Simon.

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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 their library 
attached and it fails.. and I run SQLiteStudio at the same time which is in a 
separate process.. SQLiteStudio can read my database fine.

Their argument was that it's related to my DLL's exported symbols (which I 
checked out and they look fine)?  My gut feeling is that one of us has to 
rename all Sqlite3 static function names and variables to avoid conflicts and 
recompile.  Since they make the library which should work with their users 
using stock Sqlite3 code.. they should do that :^)

Thanks,

Rail
-

On Apr 6, 2016, at 1:48 AM, Simon Slavin  wrote:

> 
> 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 file and execute a SELECT or 
> INSERT or something.  If it crashes with 'disk IO error' you've demonstrated 
> the problem to the 3rd party developers.  If it doesn't crash you know 
> there's something wrong with your own code.
> 
> Though it is scriptable from the command line so you /could/ perhaps use it 
> for useful things.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLITE_IOERR_ACCESS with 3rd party DLL

[Rail Jon Rogut]

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 
work - it's not included in the release build.

Cheers,

Rail
-

On Apr 5, 2016, at 10:29 PM, Simon Slavin  wrote:

> 
> 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 myTable LIMIT 1
> 
>> The 3rd party are trying to imply it's my code at fault -- but I can't see 
>> anything I'm doing wrong.
> 
> Instead of using your own code to access the database, download and use the 
> SQLite shell tool to execute the same SQL commands.  Just open the file and 
> type the commands in.  The shell tool was written by the same team which 
> wrote SQLite itself.  It is the canonical demonstration of the right way to 
> do things.
> 
> If you can make the shell tool crash report 'disk IO error', you can tell 
> them that they're now blaming the SQLite team for doing it wrong, and they 
> will have something to investigate which can't be blamed on any code you 
> wrote.
> 
>> So you're saying I'm basically screwed :)
> 
> Only if you insist on using that 3rd party thing.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

[Darren Duncan]

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 whether a table is one type or the other, when it doesn't matter.  Type 
information should be as readily available, or not, for a view as a base table.

> Or, consider this situation:
>
>  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?

The answer to that question is, the same type as the type that "+" results in 
given those arguments.  Either the result of that summation is of some 
particular data type, eg NUMERIC, in which case use that, or summing different 
numeric types is illegal, in which case trying to use the view would fail.

> 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.

Alternately, you can exploit the explicit column list that is optional in a 
CREATE VIEW:

   CREATE VIEW v3 (foo NUMERIC) AS SELECT w+x+y+z AS foo FROM t2;

So if a VIEW definition uses that syntax, that's what the returned column type 
is; otherwise the returned column type is the empty string.

Personally, I think using the expression value type is the best though, and 
works without any schema changes.

-- Darren Duncan

[sqlite] sqldiff nowadays

[MM]

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 maintainer - Jan Stanek with the package
>>> enhancement myself.
>>>
>>
> ...
>
>
>> Indeed, I am using fedora 23. I have the following rpms installed (though
>> we are getting a bit out of scope for this list I suppose):
>>
>
> Great - Let's try to sort the issue out then!
>
> Definitely it is not out of scope - At least with the goal of offloading
> the core sqlite team in mind, we should explain how the Linux distributions
> works, so future _packaging_ issues to be addressed to appropriate bug
> trackers instead of bothering upstream directly (i.e. this list).
>
>
>> sqlite-libs-3.11.0-3.fc23.x86_64
>> sqlite-3.11.0-3.fc23.x86_64
>> sqlite-analyzer-3.11.0-3.fc23.x86_64
>> sqlite-doc-3.11.0-3.fc23.noarch
>> sqlite-devel-3.11.0-3.fc23.x86_64
>>
>> none of them has sqldiff.
>>
>>
> I am aware of that - I have tried to make a remark above that we (the
> interested sqlite/fedora users) should try to assist our package maintainer
> (Jan Stanek) with the inclusion of the tool.
>
> As first step, I prepared a test package set with added sqldiff - To test
> you could try:
>
> dnf -y copr enable decalek/sqlite.tools
> dnf -y install sqlite-tools
>
> If it works for you, I will try to enumerate the tasks need to be done, so
> the tool to be included in the main Fedora package repositories.
>
>
> Regards,
> Alek
>
After a very long delay,   I installed sqlite-tools and tested it on a db I
had. It works great.
I tested both with the --schema option and without. The SQL generated is
correct.

A litte note is a suffix of the RPM package:  sqldiff.1

>> rpm -qa | grep sqlite
sqlite-libs-3.11.0-3.fc23.x86_64
sqlite-3.11.0-3.fc23.x86_64
sqlitebrowser-3.8.0-1.fc23.x86_64
sqlite-analyzer-3.11.0-3.fc23.x86_64
sqlite-doc-3.11.0-3.fc23.noarch
sqlite-tools-3.11.0-3.0.sqldiff.1.fc23.x86_64
sqlite-devel-3.11.0-3.fc23.x86_64

Thanks,

[sqlite] FOREIGN KEY constraint failed

[R Smith]

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 contact, and as 
such, no mystery surrounds their origins.
My assumption might be wrong.

[sqlite] Compiling SQLite dll 64 bits in MSVS

[Bart Smissaert]

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 files, but use commandline settings from VS:
> >
> > All options:
> >
> > /GS /TC /W3 /Zc:wchar_t /Zi /Gm- /O2 /Fd"x64\Release\vc120.pdb"
> /fp:precise
> > /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D
> > "SQLITE3_STDCALL_EXPORTS" /D "_WINDLL" /errorReport:prompt /WX-
> > /Zc:forScope /Gz /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\"
> > /Fp"x64\Release\SQLite3_StdCall.pch"
> >
> > Additional Options:
> >
> > sqlite3.c /Gz -DSQLITE_API=__declspec(dllexport) -O2
> > -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_SYSTEM_MALLOC=1
> > -DSQLITE_THREADSAFE=0 -DSQLITE_ENABLE_EXPLAIN_COMMENTS=1
> > -DSQLITE_SQLITE_ENABLE_RTREE=1-DSQLITE_ENABLE_FTS4=1 -link -dll
> > -out:SQLite3_StdCall.dll
> >
> >
>
> add
>
> SQLITE_API=__declspec(dllexport)
>
> from like line 12...
>
>
> http://pavel.cernohorsky.name/blog/2015/09/sqlite_64-bit_binaries_for_windows_and_how_to_build_them_with_visual_studio_2015.php
>
> You missed the important part :)
>
> > RBS
> >
> > On Tue, Apr 5, 2016 at 10:05 PM, J Decker  wrote:
> >
> >> def files are obsolete.
> >> the instructions include setting SQLITE_API to __declspec(dllexport)
> >> which should do the job... unless there was a typeo
> >>
> >> On Tue, Apr 5, 2016 at 2:03 PM, GB  wrote:
> >> > 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
> >> from
> >> > the binary dll-package into your project to create the exports.
> >> Depending on
> >> > your build flags you may need to comment out some exports.
> >> >
> >> >
> >> >
> >> > Bart Smissaert schrieb am 05.04.2016 um 22:01:
> >> >>
> >> >> I downloaded the 64 bit version of DependencyWalker from here:
> >> >> https://support.microsoft.com/en-us/kb/256872
> >> >> but it didn't run on my machine although it is Win 7 Pro 64 bits.
> >> >> Will have a look on the MSVS 2013 installation disc.
> >> >>
> >> >> RBS
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Apr 5, 2016 at 8:17 PM, GB  wrote:
> >> >>
> >> >>> Dependency Walker comes in two different flavors, one for x86 and
> one
> >> for
> >> >>> x64. You need to use the appropriate one for your DLL.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Bart Smissaert schrieb am 05.04.2016 um 09:50:
> >> >>>
> >>  Trying to compile SQLite 64 bits in MSVS 2013 from the amalgation.
> >>  Using instructions from:
> >> 
> >> 
> >> 
> >> 
> >>
> http://pavel.cernohorsky.name/blog/2015/09/sqlite_64-bit_binaries_for_windows_and_how_to_build_them_with_visual_studio_2015.php
> >> 
> >>  All compiles well, so no warnings and get a dll of about 700 kB.
> >>  Nil shows however in Dependency Walker, so it looks nil is
> exported.
> >> 
> >>  Do I need to change anything in the amalgation source to compile 64
> >> bits
> >>  or
> >>  could it be that Dependency Walker doesn't work well with 64 bit
> >> dll's?
> >>  The machine is Win 7 64 bits.
> >>  I have problem at all compiling 32 bits.
> >>  Thanks for any advice.
> >> 
> >>  RBS
> >>  ___
> >>  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 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 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 mailinglists.sqlite.org
> 

[sqlite] Compiling SQLite dll 64 bits in MSVS

[GB]

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] Compiling SQLite dll 64 bits in MSVS

[GB]

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 
from the binary dll-package into your project to create the exports. 
Depending on your build flags you may need to comment out some exports.


Bart Smissaert schrieb am 05.04.2016 um 22:01:
> I downloaded the 64 bit version of DependencyWalker from here:
> https://support.microsoft.com/en-us/kb/256872
> but it didn't run on my machine although it is Win 7 Pro 64 bits.
> Will have a look on the MSVS 2013 installation disc.
>
> RBS
>
>
>
> On Tue, Apr 5, 2016 at 8:17 PM, GB  wrote:
>
>> Dependency Walker comes in two different flavors, one for x86 and one for
>> x64. You need to use the appropriate one for your DLL.
>>
>>
>>
>> Bart Smissaert schrieb am 05.04.2016 um 09:50:
>>
>>> Trying to compile SQLite 64 bits in MSVS 2013 from the amalgation.
>>> Using instructions from:
>>>
>>>
>>> http://pavel.cernohorsky.name/blog/2015/09/sqlite_64-bit_binaries_for_windows_and_how_to_build_them_with_visual_studio_2015.php
>>>
>>> All compiles well, so no warnings and get a dll of about 700 kB.
>>> Nil shows however in Dependency Walker, so it looks nil is exported.
>>>
>>> Do I need to change anything in the amalgation source to compile 64 bits
>>> or
>>> could it be that Dependency Walker doesn't work well with 64 bit dll's?
>>> The machine is Win 7 64 bits.
>>> I have problem at all compiling 32 bits.
>>> Thanks for any advice.
>>>
>>> RBS
>>> ___
>>> 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 mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>