Re: [sqlite] Best practices for forward conversion of database formats?

Randall wrote: ~ ~ > Any application that involves a "persistent" database, i.e., one where the data is > long-lived and expected to exist and evolve over time, sooner or later has the issue > of moving customers from a V1 database to a V2 database. Obviously at least one > technical issue (there

Re: [sqlite] Best practices for forward conversion of database formats?

> This is not strictly a SQLite question, though in my case it is. > > Any application that involves a "persistent" database, i.e., one where the > data is long-lived and expected to exist and evolve over time, sooner or later > has the issue of moving customers from a V1 database to a V2

Re: [sqlite] Best practices for forward conversion of database formats?

pated traffic volume. >-Original Message- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Roger Binns >Sent: Thursday, 30 August, 2018 11:10 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] Best practices for forward conversio

Re: [sqlite] Best practices for forward conversion of database formats?

On Thu, Aug 30, 2018 at 11:10 AM Roger Binns wrote: > > On 30/08/18 09:51, Randall Smith wrote: > > is how to convert existing data from one DB format to another, given some > > arbitrary set of changes in the database schema in the interim. > > I use SQLite's user pragma. It starts at zero. >

Re: [sqlite] Best practices for forward conversion of database formats?

On 30 Aug 2018, at 5:51pm, Randall Smith wrote: > Are there accepted or best practices in the industry for handling this in > general, or with SQLite in particular? Can anyone who has implemented this > make useful suggestions? Or are there published resources I am missing? Roger has

Re: [sqlite] Best practices for forward conversion of database formats?

On 30/08/18 09:51, Randall Smith wrote: > is how to convert existing data from one DB format to another, given some > arbitrary set of changes in the database schema in the interim. I use SQLite's user pragma. It starts at zero. https://sqlite.org/pragma.html#pragma_user_version My code ends

[sqlite] Best practices for forward conversion of database formats?

This is not strictly a SQLite question, though in my case it is. Any application that involves a "persistent" database, i.e., one where the data is long-lived and expected to exist and evolve over time, sooner or later has the issue of moving customers from a V1 database to a V2 database.

Re: [sqlite] Best practices for huge batch inserts with WAL?

Scott Hess wrote: > WRT #3, you could also consider journal_mode off (or memory, if your code > requires transactions to work right). In that case, the database state is > indeterminate if you have an app-level crash, but you should be fine if you > make it to the end. It would be a better idea

Re: [sqlite] Best practices for huge batch inserts with WAL?

What I'd do: 1) Look at the indices, and make sure the input is sorted to insert in index order. Also drop any unnecessary indices and add them back at the end. [Read the code for vacuum to see what kinds of things make sense to defer.] 2) Bump up the cache a lot. Inserting in sorted order

Re: [sqlite] Best practices for huge batch inserts with WAL?

Do you have some indices on the table? Drop them before the huge insert and then recreate again. It is faster. On Mon, 24 Apr 2017 11:00:00 -0700 Jens Alfke wrote: > I’m importing a large data set with a lot of rows — an entire Wikipedia dump, > about 60GB, one article per

[sqlite] Best practices for huge batch inserts with WAL?

I’m importing a large data set with a lot of rows — an entire Wikipedia dump, about 60GB, one article per row — into a brand new SQLite database in WAL mode. What’s the fastest way to import it? I started with one big transaction, but noted that (of course) the WAL file was growing rapidly

[sqlite] Best Practices

On 2015-10-01 01:08 AM, eluken at pentarch.org wrote: > Well, when you put it like that :) > > I might allow the user to change the name based on the game name. But > there again, special characters. Ideally, the functionality would > allow for multiple databases. > > I also need to figure

[sqlite] Best Practices

On 1 Oct 2015, at 12:08am, eluken at pentarch.org wrote: > Well, when you put it like that :) > > I might allow the user to change the name based on the game name. But there > again, special characters. Ideally, the functionality would allow for > multiple databases. You could make a rule

[sqlite] Best Practices

Discussion of SQLite Database Subject: Re: [sqlite] Best Practices On 30 Sep 2015, at 12:05am, eluken at pentarch.org wrote: > I am using SQLite as the backend for a table-top wargame aid. One of the > features I am including in the aid is allowing the user to change the name > of the

[sqlite] Best Practices

On 30 Sep 2015, at 12:05am, eluken at pentarch.org wrote: > I am using SQLite as the backend for a table-top wargame aid. One of the > features I am including in the aid is allowing the user to change the name of > the database. What would be the best way to do so? Inside the filesystem? Or >

[sqlite] Best Practices

On 9/29/15, eluken at pentarch.org wrote: > I am using SQLite as the backend for a table-top wargame aid. One of the > features I am including in the aid is allowing the user to change the name > of the database. What would be the best way to do so? Inside the filesystem? > Or some feature in

[sqlite] Best Practices

I am using SQLite as the backend for a table-top wargame aid. One of the features I am including in the aid is allowing the user to change the name of the database. What would be the best way to do so? Inside the filesystem? Or some feature in SQLite to copy the database to a new name? Ideally,

Re: [sqlite] Best practices for create derived SQLite tables

On 2 Jun 2013, at 8:26pm, James Mahon wrote: > I'm trying to find the best method to create new tables in SQLite derived > from a select statement on an existing SQLite table. I've currently tried > the two methods, one in Python and one in the SQLite command shell

[sqlite] Best practices for create derived SQLite tables

Hello, I'm trying to find the best method to create new tables in SQLite derived from a select statement on an existing SQLite table. I've currently tried the two methods, one in Python and one in the SQLite command shell (both illustrated below). Although I generally prefer to code in Python, I

Re: [sqlite] Best practices for Valgrind

On Wed, Dec 5, 2012 at 6:26 PM, Paul Menzel < paulepan...@users.sourceforge.net> wrote: > Dear SQLite folks, > > > using Debian Sid/unstable with SQLite 3.7.14.1-1, running the WebKit > based browser Midori 0.4.7+ from master branch (7567058e) [1] under > Valgrind to analyze WebKit 1.8.1 though,

[sqlite] Best practices for Valgrind

Dear SQLite folks, using Debian Sid/unstable with SQLite 3.7.14.1-1, running the WebKit based browser Midori 0.4.7+ from master branch (7567058e) [1] under Valgrind to analyze WebKit 1.8.1 though, I see a lot of the following. ==31797== 64,008 bytes in 1 blocks are possibly lost in loss

Re: [sqlite] Best practices for dealing with password protected database

On 31 Oct 2011, at 8:07am, Eugene N wrote: > For your .NET application to use the, DB it must first decrypt it; That > means, storing the plain version in ram; A memory dump will pronto show the > contents of this sqlite database; Physical possession of the hardware concerned is always an end

Re: [sqlite] Best practices for dealing with password protected database

Bernd wrote: > This may not be really SQLite specific, but as it's at least SQLite > related I thought I asked here. > Our program ships with an encrypted SQLite database that has to be > opened by the application to process some other data. As it's a .NET > application, it's very

Re: [sqlite] Best practices for dealing with password protected database

Hello Bernd! I have a very limited knowledge about such matters, but it seems to me there is a caveat in the whole area of using encrypted data on a end-user pc; For your .NET application to use the, DB it must first decrypt it; That means, storing the plain version in ram; A memory dump will

[sqlite] Best practices for dealing with password protected database

This may not be really SQLite specific, but as it's at least SQLite related I thought I asked here. Our program ships with an encrypted SQLite database that has to be opened by the application to process some other data. As it's a .NET application, it's very easy to peek inside the source code

Re: [sqlite] Best practices fo web interface

As example, you can build JSON services and use a lot of javascript widgets. I use tclsqlite on my servers and jQuery on clients (desktop brawsers, Google Android applications). Small example: http://mobigroup.ru/service/jsontest/ 2011/2/27 Matt Young : > I am a regular

Re: [sqlite] Best practices fo web interface

On 27 Feb 2011, at 5:51pm, Matt Young wrote: > I am a regular user of sqite at the office, but I want to progress to sqlite > web access via the web. Who has the best widgets for that? Web space not a > problem. Widgets that work in blogger pages would be nice, but I can start > fresh also.

[sqlite] Best practices fo web interface

I am a regular user of sqite at the office, but I want to progress to sqlite web access via the web. Who has the best widgets for that? Web space not a problem. Widgets that work in blogger pages would be nice, but I can start fresh also. ___

Re: [sqlite] Best Practices

On Tue, Jun 10, 2008 at 1:29 PM, A. H. Ongun <[EMAIL PROTECTED]> wrote: > We have an application requirement for the following: > 1) Maintain an in memory database of real time data. The main table mimics > a Modbus register address scheme and once the table is created and records > are

[sqlite] Best Practices

We have  an application requirement for the following: 1) Maintain an in memory database of real time data.  The main table mimics a Modbus register address scheme and once the table is created and records are inserted to create the table at startup, all writes are updates for the state