Re: [sqlite] Strange Corruption Issue

2018-06-18 Thread Keith Medcalf

After almost a year I am at 18 TBW on my system/data SSD and that includes 
several re-installs of Windows plus a bunch of VM updates of the Windows 
"Insider" previews, so getting to 1200 TBW would be quite a task ... (Note, 
defrag does not run on SSDs since it is useless, but I have forced that more 
than once as just to see how it worked).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Rowan Worth
>Sent: Monday, 18 June, 2018 22:42
>To: SQLite mailing list
>Subject: Re: [sqlite] Strange Corruption Issue
>
>Between updates, automatic maintenance, registry churn, event logs,
>and
>background "optimisations" I reckon windows could give 400G/day a run
>for
>its money :P
>
>-Rowan
>
>On 19 June 2018 at 12:37, Keith Medcalf  wrote:
>
>>
>> The new "consumer" SSDs from Samsung carry a 1200 TBW/8 year
>warranty on a
>> 4 TB device.  That is a lot of writing for a "consumer desktop"
>computer
>> ... that is about 400 GB written per DAY every day for 8 years!
>>
>> ---
>> The fact that there's a Highway to Hell but only a Stairway to
>Heaven says
>> a lot about anticipated traffic volume.
>>
>>
>> >-Original Message-
>> >From: sqlite-users [mailto:sqlite-users-
>> >boun...@mailinglists.sqlite.org] On Behalf Of Scott Doctor
>> >Sent: Monday, 18 June, 2018 22:27
>> >To: sqlite-users@mailinglists.sqlite.org
>> >Subject: Re: [sqlite] Strange Corruption Issue
>> >
>> >SSD's have a limited number of write cycles. You may have a
>> >failing SSD. Those are still, IMO, another 5-10 years before
>> >they solve the write lifetime reliabilty issue.
>> >
>> >-
>> >Scott Doctor
>> >sc...@scottdoctor.com
>> >-
>> >
>> >On 6/18/2018 20:15, Patrick Herbst wrote:
>> >> I'm using sqlite in an embedded application, running on SSD.
>> >>
>> >> journal_mode=persist
>> >> so that it is more resilient to loss of power.
>> >>
>> >> I'm seeing corruption.  I'm using sqlite to log events on the
>> >system,
>> >> and the corruption is well in the middle of a power session; not
>at
>> >> the tail end of log when a power loss might occur.
>> >>
>> >> What i'm seeing is just a few pages corrupted with random bits
>> >being
>> >> flipped.  looking in a hex editor I can see the corrupted data,
>and
>> >> where I can tell what values it SHOULD be, I see that they're
>> >wrong,
>> >> but only by a single bit flip in random bytes here and
>there.
>> >for
>> >> example a "A" is "a", or a "E" is "A".  These are all changes of
>a
>> >> single bit.  there are far more examples... but in pretty much
>> >every
>> >> case (even when RowID's are wrong) its just off by a bit.
>> >>
>> >> I'm using sqlite 3.7 (i know, old, but this this system is old).
>> >Has
>> >> anyone else seen random bit flips?  Any idea what could be
>causing
>> >it?
>> >> ___
>> >> sqlite-users mailing list
>> >> sqlite-users@mailinglists.sqlite.org
>> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>> >users
>> >
>> >___
>> >sqlite-users mailing list
>> >sqlite-users@mailinglists.sqlite.org
>> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Strange Corruption Issue

2018-06-18 Thread Scott Robison
On Mon, Jun 18, 2018 at 9:15 PM, Patrick Herbst  wrote:
> I'm using sqlite in an embedded application, running on SSD.
>
> journal_mode=persist
> so that it is more resilient to loss of power.
>
> I'm seeing corruption.  I'm using sqlite to log events on the system,
> and the corruption is well in the middle of a power session; not at
> the tail end of log when a power loss might occur.
>
> What i'm seeing is just a few pages corrupted with random bits being
> flipped.  looking in a hex editor I can see the corrupted data, and
> where I can tell what values it SHOULD be, I see that they're wrong,
> but only by a single bit flip in random bytes here and there.  for
> example a "A" is "a", or a "E" is "A".  These are all changes of a
> single bit.  there are far more examples... but in pretty much every
> case (even when RowID's are wrong) its just off by a bit.
>
> I'm using sqlite 3.7 (i know, old, but this this system is old).  Has
> anyone else seen random bit flips?  Any idea what could be causing it?

My first guess would be failing RAM chips.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Strange Corruption Issue

2018-06-18 Thread Rowan Worth
Between updates, automatic maintenance, registry churn, event logs, and
background "optimisations" I reckon windows could give 400G/day a run for
its money :P

-Rowan

On 19 June 2018 at 12:37, Keith Medcalf  wrote:

>
> The new "consumer" SSDs from Samsung carry a 1200 TBW/8 year warranty on a
> 4 TB device.  That is a lot of writing for a "consumer desktop" computer
> ... that is about 400 GB written per DAY every day for 8 years!
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
> >-Original Message-
> >From: sqlite-users [mailto:sqlite-users-
> >boun...@mailinglists.sqlite.org] On Behalf Of Scott Doctor
> >Sent: Monday, 18 June, 2018 22:27
> >To: sqlite-users@mailinglists.sqlite.org
> >Subject: Re: [sqlite] Strange Corruption Issue
> >
> >SSD's have a limited number of write cycles. You may have a
> >failing SSD. Those are still, IMO, another 5-10 years before
> >they solve the write lifetime reliabilty issue.
> >
> >-
> >Scott Doctor
> >sc...@scottdoctor.com
> >-
> >
> >On 6/18/2018 20:15, Patrick Herbst wrote:
> >> I'm using sqlite in an embedded application, running on SSD.
> >>
> >> journal_mode=persist
> >> so that it is more resilient to loss of power.
> >>
> >> I'm seeing corruption.  I'm using sqlite to log events on the
> >system,
> >> and the corruption is well in the middle of a power session; not at
> >> the tail end of log when a power loss might occur.
> >>
> >> What i'm seeing is just a few pages corrupted with random bits
> >being
> >> flipped.  looking in a hex editor I can see the corrupted data, and
> >> where I can tell what values it SHOULD be, I see that they're
> >wrong,
> >> but only by a single bit flip in random bytes here and there.
> >for
> >> example a "A" is "a", or a "E" is "A".  These are all changes of a
> >> single bit.  there are far more examples... but in pretty much
> >every
> >> case (even when RowID's are wrong) its just off by a bit.
> >>
> >> I'm using sqlite 3.7 (i know, old, but this this system is old).
> >Has
> >> anyone else seen random bit flips?  Any idea what could be causing
> >it?
> >> ___
> >> sqlite-users mailing list
> >> sqlite-users@mailinglists.sqlite.org
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
> >users
> >
> >___
> >sqlite-users mailing list
> >sqlite-users@mailinglists.sqlite.org
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Strange Corruption Issue

2018-06-18 Thread Keith Medcalf

The new "consumer" SSDs from Samsung carry a 1200 TBW/8 year warranty on a 4 TB 
device.  That is a lot of writing for a "consumer desktop" computer ... that is 
about 400 GB written per DAY every day for 8 years!

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Scott Doctor
>Sent: Monday, 18 June, 2018 22:27
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] Strange Corruption Issue
>
>SSD's have a limited number of write cycles. You may have a
>failing SSD. Those are still, IMO, another 5-10 years before
>they solve the write lifetime reliabilty issue.
>
>-
>Scott Doctor
>sc...@scottdoctor.com
>-
>
>On 6/18/2018 20:15, Patrick Herbst wrote:
>> I'm using sqlite in an embedded application, running on SSD.
>>
>> journal_mode=persist
>> so that it is more resilient to loss of power.
>>
>> I'm seeing corruption.  I'm using sqlite to log events on the
>system,
>> and the corruption is well in the middle of a power session; not at
>> the tail end of log when a power loss might occur.
>>
>> What i'm seeing is just a few pages corrupted with random bits
>being
>> flipped.  looking in a hex editor I can see the corrupted data, and
>> where I can tell what values it SHOULD be, I see that they're
>wrong,
>> but only by a single bit flip in random bytes here and there.
>for
>> example a "A" is "a", or a "E" is "A".  These are all changes of a
>> single bit.  there are far more examples... but in pretty much
>every
>> case (even when RowID's are wrong) its just off by a bit.
>>
>> I'm using sqlite 3.7 (i know, old, but this this system is old).
>Has
>> anyone else seen random bit flips?  Any idea what could be causing
>it?
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>users
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Strange Corruption Issue

2018-06-18 Thread Scott Doctor
SSD's have a limited number of write cycles. You may have a 
failing SSD. Those are still, IMO, another 5-10 years before 
they solve the write lifetime reliabilty issue.


-
Scott Doctor
sc...@scottdoctor.com
-

On 6/18/2018 20:15, Patrick Herbst wrote:

I'm using sqlite in an embedded application, running on SSD.

journal_mode=persist
so that it is more resilient to loss of power.

I'm seeing corruption.  I'm using sqlite to log events on the system,
and the corruption is well in the middle of a power session; not at
the tail end of log when a power loss might occur.

What i'm seeing is just a few pages corrupted with random bits being
flipped.  looking in a hex editor I can see the corrupted data, and
where I can tell what values it SHOULD be, I see that they're wrong,
but only by a single bit flip in random bytes here and there.  for
example a "A" is "a", or a "E" is "A".  These are all changes of a
single bit.  there are far more examples... but in pretty much every
case (even when RowID's are wrong) its just off by a bit.

I'm using sqlite 3.7 (i know, old, but this this system is old).  Has
anyone else seen random bit flips?  Any idea what could be causing it?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] Strange Corruption Issue

2018-06-18 Thread Patrick Herbst
I'm using sqlite in an embedded application, running on SSD.

journal_mode=persist
so that it is more resilient to loss of power.

I'm seeing corruption.  I'm using sqlite to log events on the system,
and the corruption is well in the middle of a power session; not at
the tail end of log when a power loss might occur.

What i'm seeing is just a few pages corrupted with random bits being
flipped.  looking in a hex editor I can see the corrupted data, and
where I can tell what values it SHOULD be, I see that they're wrong,
but only by a single bit flip in random bytes here and there.  for
example a "A" is "a", or a "E" is "A".  These are all changes of a
single bit.  there are far more examples... but in pretty much every
case (even when RowID's are wrong) its just off by a bit.

I'm using sqlite 3.7 (i know, old, but this this system is old).  Has
anyone else seen random bit flips?  Any idea what could be causing it?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Mailing list shutting down...

2018-06-18 Thread Jeffrey Schiller
Check out:

   http://c.qyv.net/mailmansrc/info/a6250b7ba075294c

This is a patch to mailman version 2.1.20 (the version deployed on
sqlite.org). It adds a three day waiting period between subscription
attempts. When applying this patch also be sure to edit Defaults.py (which
is generated at installation time from Defaults.py.in) to include the new
variable for controlling the subscription window.

You may also want to set SUBSCRIBE_FORM_SECRET to a secret string. This
will enable verification that a submitted form is both from the site and
filled out after 5 seconds (to thwart bots).

Enjoy.

-Jeff

On Thu, Jun 14, 2018 at 11:02 PM Jeffrey Schiller <
jeffrey.schil...@gmail.com> wrote:

> I am so offering...
>
> -Jeff
>
>
> On Wed, Jun 13, 2018 at 12:42 PM Richard Hipp  wrote:
>
>> On 6/13/18, Michael Tiernan  wrote:
>> > May I respectfully suggest to everyone that offering solutions, while
>> > valuable and helpful, may not be as valuable as the offer of assistance
>> > to our listmaster.
>>
>> +1  :-)
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Criteria to define two fields as Primary Key or Unique

2018-06-18 Thread Markos
Many thanks Simon, Keith and Richard for your attention and didactic 
explanations.



Em 17-06-2018 14:37, Keith Medcalf escreveu:

Also note that you probably want your application to store the password as a 
salted-hash, and not as a plain-text password.  Otherwise someone could look up 
the passwords with a text editor ...

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.



-Original Message-
From: sqlite-users [mailto:sqlite-users-
boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
Sent: Sunday, 17 June, 2018 11:30
To: SQLite mailing list
Subject: Re: [sqlite] Criteria to define two fields as Primary Key or
Unique

On 17 Jun 2018, at 5:55pm, Markos  wrote:


I want to avoid two administrators (admin_user) with the same login

but for this I am in doubt if I put the two fields as primary key or
as unique:

Your ideas both have different advantages, but are not the normal way
to do things.  Try this instead:

CREATE TABLE user (
id INTEGER PRIMARY KEY,
login text COLLATE NOCASE NOT NULL UNIQUE,
password text NOT NULL,
admin INTEGER DEFAULT 0,
admin_registration_date INTEGER NOT NULL);

The idea is that you have just one account table.  In that you have
everyone, whether they're superadmin, admin or mundane users.  You
just have a field saying what kind of account the row represents.
The 'UNIQUE' keyword for the 'login' field has SQLite create its own
private index so it can check for uniqueness, and if in other places
it needs to look up a login name it will use that index.

In the above I have just two values for the admin field.  users are
'0' admins are '1' (which SQLite interprets as meaning TRUE).

But you seem to have a superadmin status (presumably you).  So you
might prefer '0' for superadmin, '1' for admin, '2' for normal users.
Or some other system that suits you.  Maybe even store the words
'user', 'admin', 'superadmin'.

The use of the 'id' field as INTEGER PRIMARY KEY is a fundamental
part of the way SQL tables are often used.  Every row has an INTEGER
key, assigned by the SQL engine (you don't set it yourself,
automatically incrementing values are set for you).  You never change
those values.  And when you need to refer to that entry in other
tables (e.g. a foreign key) you use the correct 'id' value, not
someone's login name.

See FAQ number 1 in



Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] .timer

2018-06-18 Thread Keith Medcalf

The following pure python code does the same thing, memmapping the file when 
reading backwards ... works in Python 2 and 3, 32 and 64 bit.

Emulates what sqlite3 is doing as closely as I can manage.  As long as the mmap 
fits in memory it does not seem to affect performance.

---//---
from __future__ import absolute_import, print_function, division, 
unicode_literals

import random
import time
import os
import sys

if sys.version_info.major > 2:
xrange = range

blocksize = 4096
blocks = 1024 * 4096

buffer = []
for i in xrange(blocksize):
buffer.append(chr(random.randint(ord('A'), ord('z'
buffer = ''.join(buffer)

if sys.version_info.major > 2:
buffer = buffer.encode('utf_8')

if os.path.exists('junk.dat'):
print('Deleting junk.dat test file')
os.unlink('junk.dat')

if not os.path.exists('junk.dat'):
print('Creating 0 length junk.dat test file')
f = open('junk.dat', 'wb')
f.close()

f = open('junk.dat', 'rb+', buffering=0)

print('Writing File Forward', end=' ')
st = time.time()
for i in xrange(blocks):
f.seek(i * blocksize)
f.write(buffer)
f.flush()
os.fsync(f.fileno())
print(time.time() - st, 'seconds')
print()

def readforward():
print('Reading File Forward', end=' ')
st = time.time()
for i in xrange(blocks):
f.seek(i * blocksize)
f.read(blocksize)
f.flush()
os.fsync(f.fileno())
print(time.time() - st, 'seconds')
print()

def readbackwards():
print('Reading File Backward', end=' ')
st = time.time()
for i in xrange(blocks -1 ,-1, -1):
f.seek(i * blocksize)
f.read(blocksize)
f.flush()
os.fsync(f.fileno())
print(time.time() - st, 'seconds')
print()

readforward()
readbackwards()
readforward()
readbackwards()
readbackwards()
readforward()

f.close()
---//---


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of David Raymond
>Sent: Monday, 18 June, 2018 07:10
>To: SQLite mailing list
>Subject: Re: [sqlite] .timer
>
>I haven't grasped all the fancy memory talk that's been going on
>here, but I have one request. Would you try the slowdown tests with a
>SQLite version compiled with...
>SQLITE_DEFAULT_MMAP_SIZE=0
>SQLITE_MAX_MMAP_SIZE=0
>...and see if anything changes? I started compiling with those
>options after some similar speed issues "back when" and things seem
>to have cleared up since then. I'm curious if it's because I added
>that or if it's just a coincidence.
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] .timer

2018-06-18 Thread Keith Medcalf

These are with SQLITE3's memmap turned off (SQLITE_DEFAULT_MMAP_SIZE 0).  I set 
the MAX_SIZE to 0 as well and it made no difference.

Windows is memmapping the file by itself.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of David Raymond
>Sent: Monday, 18 June, 2018 07:10
>To: SQLite mailing list
>Subject: Re: [sqlite] .timer
>
>I haven't grasped all the fancy memory talk that's been going on
>here, but I have one request. Would you try the slowdown tests with a
>SQLite version compiled with...
>SQLITE_DEFAULT_MMAP_SIZE=0
>SQLITE_MAX_MMAP_SIZE=0
>...and see if anything changes? I started compiling with those
>options after some similar speed issues "back when" and things seem
>to have cleared up since then. I'm curious if it's because I added
>that or if it's just a coincidence.
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] .timer

2018-06-18 Thread David Raymond
I haven't grasped all the fancy memory talk that's been going on here, but I 
have one request. Would you try the slowdown tests with a SQLite version 
compiled with...
SQLITE_DEFAULT_MMAP_SIZE=0
SQLITE_MAX_MMAP_SIZE=0
...and see if anything changes? I started compiling with those options after 
some similar speed issues "back when" and things seem to have cleared up since 
then. I'm curious if it's because I added that or if it's just a coincidence.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] ___fixunsdfdi

2018-06-18 Thread x
Thanks Guy. After reading that I was wondering if it was maybe something to do 
with the code I’ve added to the end of the sqlite3.c file which includes 
several extentions. After commenting out the #include “csv.c” (& associated) 
code it linked OK.




From: sqlite-users  on behalf of 
Guy Harris 
Sent: Monday, June 18, 2018 11:45:38 AM
To: SQLite mailing list
Subject: Re: [sqlite] ___fixunsdfdi

On Jun 18, 2018, at 3:21 AM, x  wrote:

> I’m using c++ builder 10.2 Tokyo on windows 10 pro.
> In a console app I’m getting this error message
>
> [ilink32 Error] Error: Unresolved external '___fixunsdfdi' referenced from 
> C:\...\PROJECTS\WIN32\DEBUG\SQLITE3.OBJ
>
> I can’t find any mention of it in sqlite3.h or sqlite3.c.
>
> Anyone know anything about it?

It's a support routine to which some compilers generate calls.  The Intel 
System Studio documentation:

https://software.intel.com/en-us/node/704849

says

These functions convert a to an unsigned 64-bit integer rounding toward 
zero. If the integral value cannot be represented by the integer type, zero is 
returned.

The incremental linker is probably not linking with whatever library the 
compiler that built sqlite3.obj expects the program to be linked with.  You'd 
probably have to check the C++ Builder documentation to see what library that 
might be and how to ensure that it gets linked with that library.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] ___fixunsdfdi

2018-06-18 Thread Guy Harris
On Jun 18, 2018, at 3:21 AM, x  wrote:

> I’m using c++ builder 10.2 Tokyo on windows 10 pro.
> In a console app I’m getting this error message
> 
> [ilink32 Error] Error: Unresolved external '___fixunsdfdi' referenced from 
> C:\...\PROJECTS\WIN32\DEBUG\SQLITE3.OBJ
> 
> I can’t find any mention of it in sqlite3.h or sqlite3.c.
> 
> Anyone know anything about it?

It's a support routine to which some compilers generate calls.  The Intel 
System Studio documentation:

https://software.intel.com/en-us/node/704849

says

These functions convert a to an unsigned 64-bit integer rounding toward 
zero. If the integral value cannot be represented by the integer type, zero is 
returned.

The incremental linker is probably not linking with whatever library the 
compiler that built sqlite3.obj expects the program to be linked with.  You'd 
probably have to check the C++ Builder documentation to see what library that 
might be and how to ensure that it gets linked with that library.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Back on-line. Was: Mailing list shutting down...

2018-06-18 Thread Don V Nielsen
Any thought, comments, or observations of using Slack?

On Fri, Jun 15, 2018 at 1:25 PM J. King  wrote:

> On June 15, 2018 12:17:31 PM EDT, dmp 
> wrote:
> >> Mailing lists are now back on-line and once again accepting
> >> subscriptions.  I have implemented measures to block the subscription
> >> robots and to better log subscription activity to better detect
> >future
> >> mischief.
> >
> >> I consider this to be a stop-gap measure that will buy me some time
> >> to implement and test a better log-term solution. .
> >
> >> D. Richard Hipp
> >> d...@sqlite.org
> >
> >As a comment, again with past post with regard to Mailing List.
> >
> >This mailing list is a very informative, simple, and a conveniant
> >method to disperse information in a bulk format. A change to a web
> >interface, (forum, other), that requires a login each day is most
> >likely going to push me away.
> >
> >Hope a fix can be accomplished.
> >
> >danap.
> >
> >___
> >sqlite-users mailing list
> >sqlite-users@mailinglists.sqlite.org
> >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> Opinions on this have made the rounds here before, but I will reiterate
> that I feel the same. I would be especially sad to see this discussion list
> move to Discourse (as was suggested and apparently explored earlier this
> week), as I find that software very unresponsive and difficult to use on
> Firefox for Android, and I do much of my reading of this list on the go
> (like right now).
>
>
> --
> J. King
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] ___fixunsdfdi

2018-06-18 Thread x
I’m using c++ builder 10.2 Tokyo on windows 10 pro.
In a console app I’m getting this error message

[ilink32 Error] Error: Unresolved external '___fixunsdfdi' referenced from 
C:\...\PROJECTS\WIN32\DEBUG\SQLITE3.OBJ

I can’t find any mention of it in sqlite3.h or sqlite3.c.

Anyone know anything about it?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users