On 6/29/2016 6:13 AM, R Smith wrote:
Very happy this is sorted for you. Note that Synchronous=OFF should
only ever be used on a read-only DB (or at least one where writing
only happens when you the user/DB Admin actively makes changes via
queries. For anything that should run autonomously,
On 6/29/2016 1:04 AM, R Smith wrote:
These are the duplicate records. This index is associated with a
UNIQUE constraint on the original table. Is there a way to clean it up?
That means your DB is corrupted by some method. It's not bad yet, just
missing Index entries.
Make a copy of the
On 6/28/2016 4:52 PM, Simon Slavin wrote:
On 28 Jun 2016, at 11:22pm, Joe Pasquariello <j...@fenway.com> wrote:
select rowid, device, hex(device), localtime, udatetime
from eventlog where device like '%M14' and udatetime=1415000934
rowiddevicehex(device)localtimeuda
On 6/28/2016 3:05 PM, Simon Slavin wrote:
SELECT device,HEX(device) FROM myTable WHERE
Thanks, Simon. Now it's getting really strange. Two queries and their
results are shown below. The value of "device" seems to be the same in
both rows. One query includes the field "localtime" and the
14150009342456964.825625
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
--
Joe Pasquariello
Fenway Systems, LLC
2980 College Ave, Suite 7
Berkeley, CA 947
device,localtime,code,type,text,0 as status, count(*) as
the_count
from eventlog
group by udatetime,device,code,type,status
having count(*) > 1
>
On 2016/06/28 9:37 PM, Joe Pasquariello wrote:
> Hello,
>
> I'm a novice user of Sqlite, and could use some help. The code below
&g
xt, status )
SELECT udatetime, device, localtime, code, type, text, 0
FROM TempEventLog ORDER BY rowid;
DROP TABLE TempEventLog;
PRAGMA user_version = 1;
COMMIT;
--
Joe Pasquariello
Fenway Systems, LLC
2980 College Ave, Suite 7
Berkeley, CA 94705
510-665-4355
j...@
Hello,
One thread of our Windows application is an HTTP server reading data
from an SQLite database for display by web clients. Some tables are
updated infrequently (minutes), but one contains current status of
numerous machines, and it is written/read relatively frequently. Data is
written
On 4/19/2015 7:08 PM, Richard Hipp wrote:
>> Since power loss occurs relatively
>> frequently, do you recommend synchronous=1 (Normal) or 2 (Full)?
> Either will be fine.
>> Can a power failure during
>> a COMMIT to a TEMPORARY table in memory, with synchronous=0, result in
>> corruption
> No.
On 4/19/2015 2:02 PM, Richard Hipp wrote:
> On 4/19/15, Joe Pasquariello wrote:
>> Some users of my application have their servers in remote locations that
>> lose power. They have UPS backup, but the battery runs down and the
>> computers will suddenly sto
Some users of my application have their servers in remote locations that
lose power. They have UPS backup, but the battery runs down and the
computers will suddenly stop. When power returns and the application
starts, the SQLITE database is sometimes corrupt. The vast majority of
writes to the
11 matches
Mail list logo
