[sqlite] [RE] System.Data.SQLite version 1.0.99.0 released

Hello I have still problems to get it working on SQL Server2012 R2. I got the following message: "That assembly does not allow partially trusted" The server is shared and there is no possibility to change system settings. The program uses ASP.NET C# library under IIS. Is there a possibility to

[sqlite] security problem in ASP.NET C# library

Hello After migration from Windows Server 2003 to Windows Server 2012R2 the following error occurs in the C# library (version 1.0.098.1): "That assembly does not allow partially trusted" The server is shared and there is no possibility to change system settings. The program uses ASP.NET C#

[sqlite] Replace an open database

>On Fri, May 29, 2015 at 8:48 AM, Dan Kennedy <[hidden >email]> > wrote: > >> On 05/29/2015 12:59 PM, Zaumseil Ren? wrote: >> >>> On 05/27/2015 11:59 PM, Wade, William wrote: >>> But instead of using a regular SQL

[sqlite] Replace an open database

On 05/27/2015 11:59 PM, Wade, William wrote: >> 3) The writing thread prefers to delete any existing file. If it can't do >> that (some readers currently have the file open) it gains an exclusive >> read/write lock (consistent with no reader has a transaction in progress) >> and truncates the

[sqlite] emptying tables

>You turn off auto_vacuum but do a manual VACUUM once you've deleted all the >data from /all/ the tables. It's faster >before VACUUM takes time roughly >proportional to the amount of data left in the database. > >Simon. Thank you for the hint. Rene Kernkraftwerk Goesgen-Daeniken AG CH-4658

[sqlite] emptying tables

>Are you running all your delete statements within a single transaction, or a >separate transaction for each? A single transaction as written before in this thread. Rene Kernkraftwerk Goesgen-Daeniken AG CH-4658 Daeniken, Switzerland Diese Nachricht (inkl. Anhaenge) beinhaltet

[sqlite] emptying tables

>> I have used auto_commit as a replacement for vacuum. Because I only add new >> data and only delete from the end I thought it would be faster (no extra >> scan to rebuild ). > >Humor me. Try your experiment without auto_vacuum. Leave everything >else the same. See what performance difference

[sqlite] emptying tables

>I think that operation will go MUCH faster if you (1) turn off >auto_vacuum, (2) use journal_mode=DELETE, and (3) put all of the >DELETE operations inside a single transaction. > >D. Richard Hipp I have used auto_commit as a replacement for vacuum. Because I only add new data and only delete

[sqlite] emptying tables

Here some last test data PRAGMA synchronous = 1; PRAGMA auto_vacuum = FULL; PRAGMA journal_mode = WAL; PRAGMA wal_autocheckpoint = 1; PRAGMA cache_size = 1; A database ca. 4GB with 2200 tables takes 3 minutes for a "delete * from table" over all tables. HTH Rene Kernkraftwerk

[sqlite] emptying tables

>> My main problem is still the time of a delete statement. It takes some >> minutes to delete all data from all tables. > >How many tables do you have ? You are using just the command > I have up to 3000 Tables. Most of them have only some entries. But some can have have up to a million.

[sqlite] emptying tables

Sorry for the delay. >> I started with the single table solution. But it was to slow on select and >> the database was also bigger because of the id for each row. Now I can use >> the timestamp as rowed. > >If it was slow on SELECT I suspect you didn't have an appropriate INDEX. But >my

[sqlite] emptying tables

> The actual truth depends on finicky details of your own setup. But see the > last part of this page: > > > > "When the WHERE is omitted from a DELETE statement and the table being > deleted has no triggers, SQLite uses an optimization to erase the

[sqlite] emptying tables

Hi I have a range of tables with rowid,value inside. Some have only few and some other can have up to a million values. Now I will empty all the tables and vacuum the database. Which is the fastest way? 1. A loop over all tables with "delete * from tablename" (this is what I'm

[sqlite] howto shrink files in wal mode

>If you do the VACUUM before the "PRAGMA wal_checkpoint" instead of after, does >that help? > >Dan. You won the jackpot! Thank you for the tip. May be this should be mentioned in the official documentation. >I think the file actually has shrunk. I just think that the size reported is >not

[sqlite] howto shrink files in wal mode

> I think tcl gets its file size from the operating system and the operating > system doesn't update the size of flies with open > handles. But you are going to need someone who knows tcl to check that. I think that would be me :) > > Please see in the script in the original post. > > I'm

[sqlite] howto shrink files in wal mode

>How are you measuring the size of the database file ? > >Simon. Using the tcl "file" command. puts b=[file size $dbfile] Please see in the script in the original post. Rene Kernkraftwerk Goesgen-Daeniken AG CH-4658 Daeniken, Switzerland Diese Nachricht (inkl. Anhaenge) beinhaltet

[sqlite] howto shrink files in wal mode

> > To clarify, I need to shrink the dbfile, not the *wal file. > The only thing that will do that under your conditions is VACUUM. > > Simon. I have done "vacuum" right before the b= output. But the dbfile will only shrink "after" I have closed the db. When I try the same in "DELETE" mode

[sqlite] howto shrink files in wal mode

> On 5/5/15, Zaumseil Ren? mailto:RZaumseil at kkg.ch>> > wrote: > > > > Is there a way to shrink the file when it is still open in WAL mode? > > > > Run "PRAGMA wal_checkpoint=TRUNCATE;" in SQLite 3.8.8.2 or later. > -- > D. Richard Hipp > drh at sqlite.org

[sqlite] howto shrink files in wal mode

Hi, After running the following script in sqlite 3.8.7.1: set dbfile {c:/temp/db.sqlite3} file delete -force $dbfile sqlite3 ::db $dbfile ::db eval { PRAGMA journal_mode = WAL; create table test2 (id, txt) } for {set i 0} {$i < 1} {incr i} { set t txt$i ::db eval {insert into test2

[sqlite] windows network and wal mode

Hi there, I have used sqlite to store parameter changes with a time stamp in a simulation environment. Because of the number of parameters (2000+) and the max. change rate up to 50ms I have a separate table for each parameter with time stamp and value. The time stamp is used as "integer