Re: [sqlite] Do source updates effect DB file compatiblity?

[Ng Pheng Siong]

On Fri, Mar 18, 2005 at 02:13:39PM -0800, Kiel W. wrote:
> As SQLite progresses and I update my source with new releases,
> recompile and deploy 

If your application works fine with the version that you've embedded, why
change? 

-- 
Ng Pheng Siong <[EMAIL PROTECTED]> 

http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com   -+- Transparent AES Encryption for SQLite

[sqlite] SQLITE_SCHEMA[17]

[Steve D. Perkins]

Hello,

SQLite Version 2.8.13

Anybody know what causes SQLite to generate the following error:

SQLITE_SCHEMA[17]: database schema has changed

With no schema change taking place this error occurs out of the blue
and automagically resolves itself.

Any help would be appreciated!!

Thanks in advance!

Steve

Re: [sqlite] How do I Register on sqlite.org

[Kurt Welgehausen]

You can record the ticket number when you originate the
ticket and check the status any time with
.

Or, just bookmark the url after you submit the ticket.

Or, you can scan (search) the timeline for the ticket
number to see what action has been taken.

If you lose the ticket number but remember about when
you submitted it, you can read the timeline around that
date and probably find your ticket from the descriptions.

Regards

Re: [sqlite] How do I Register on sqlite.org

[Lawrence Chitty]

David Wheeler wrote:
On Mar 18, 2005, at 1:31 PM, Witold Czarnecki wrote:
You don't need to register. Just place the ticket: 
http://www.sqlite.org/cvstrac/tktnew

I did that before, but then I received no notifications when the 
ticket was updated or resolved. I'd love to get that information in 
the future...

Cvstrac, the bug tracking system used by Sqlite provides a simple RSS 
feed for the timeline that include bug status changes. If you use an RSS 
reader, the URL you need is :- 
http://www.sqlite.org/cvstrac/timeline.rss  . You could then set  a 
filter (if your RSS reader provides them) on the bug number, e.g 'title 
contains  #1166'

Lawrence


Thanks,
David

[sqlite] Do source updates effect DB file compatiblity?

[Kiel W.]

List,

I'm new to the concept of embedded databases, but it seems to be the
ideal solution for a project I'm developing for school/ my church. 
Along with any resources you might recommend one question has been on
my mind for awhile.

As SQLite progresses and I update my source with new releases,
recompile and deploy is this going to cause the existing database
files to become "outdated" or no longer work?  My guess is no for a
particular branch (ie 3.x) but I want to be certain.  Is there
expected compatibility breaks later in development? To what extent?

If such breaks happen, with the existing framework of SQLite, how hard
might it be to transfer over to a newer release?  Examples from 2.x to
3.x might be helpful.

Thanks for any input.

[sqlite] database replication

[Jay]

I just finished a c++ program to replicate a database while it's in
use. I have tested it on a version 3 database under windows.

It creates a duplicate database with the same schema as the source
database, then in a loop it locks the database, copies a table,
and unlocks the database.

The database will be write locked for however long
it takes for each table to be copied. If you're interested
in the source code I will be happy to release it.





__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: [sqlite] How do I Register on sqlite.org

[Derrell . Lipman]

David Wheeler <[EMAIL PROTECTED]> writes:

> On Mar 18, 2005, at 1:31 PM, Witold Czarnecki wrote:
>
>> You don't need to register. Just place the ticket:
>> http://www.sqlite.org/cvstrac/tktnew
>
> I did that before, but then I received no notifications when the ticket was
> updated or resolved. I'd love to get that information in the future...

Some large open-source projects are set up with bug reporting and tracking
software (typically bugzilla) that allows you to track bugs that you report or
bugs that you are otherwise interested in, by receiving email messages when
the bugs' statuses (stati?) change.  I agree it's a nice feature (although I
think the bugzilla interface leaves much to be desired).

I don't believe that the sqlite bug-reporting system is currently set up to
provide bug tracking on an individual person basis.

Derrell

Re: [sqlite] How do I Register on sqlite.org

[David Wheeler]

On Mar 18, 2005, at 1:31 PM, Witold Czarnecki wrote:
You don't need to register. Just place the ticket: 
http://www.sqlite.org/cvstrac/tktnew
I did that before, but then I received no notifications when the ticket 
was updated or resolved. I'd love to get that information in the 
future...

Thanks,
David

Re: [sqlite] How do I Register on sqlite.org

[Witold Czarnecki]

You don't need to register. Just place the ticket: 
http://www.sqlite.org/cvstrac/tktnew

Best regards,
Witold
- Original Message - 
From: "David Wheeler" <[EMAIL PROTECTED]>
To: "SQLite Users" 
Sent: Friday, March 18, 2005 9:06 PM
Subject: [sqlite] How do I Register on sqlite.org


Hi All,
I'd like to file a bug report for SQLite, but do it as myself, so that I 
(hopefully) will receive emails whenever the ticket is updated. (I 
recently encountered a bug when I upgraded to 3.1.x, and then discovered 
that it wasn't a bug, but a bug fix--for a bug report I had filed!) 
However, I can't find where to register on the site. Am I missing 
something?

Thanks,
David

[sqlite] How do I Register on sqlite.org

[David Wheeler]

Hi All,
I'd like to file a bug report for SQLite, but do it as myself, so that 
I (hopefully) will receive emails whenever the ticket is updated. (I 
recently encountered a bug when I upgraded to 3.1.x, and then 
discovered that it wasn't a bug, but a bug fix--for a bug report I had 
filed!) However, I can't find where to register on the site. Am I 
missing something?

Thanks,
David

[sqlite] F_FULLSYNC Pragma ? (v 3.1.4-3.1.6)

[Eric Hochmeister]

Hi,

I'm quite confused as to how to make use of the added F_FULLSYNC
feature added in v3.1.4 as stated below.

â The F_FULLSYNC ioctl (currently only supported on OS-X) is disabled
if the synchronous pragma is set to something other than "full".

Is this a compile time PRAGMA, or do I need to set this pragma
manually each time I open a database?

I would like to disable the F_FULLSYNC, but I can't figure out how. 
(Preferably I would like it to be disabled for all created databases
so each time I access the database it is disabled)

Thanks,

Eric

Re: [sqlite] tclsqlite3.dll Errors

[Peter G. Brown]

Thank you...
For any future rookie:
I upgraded to 8.4.9 and
putting the following in a file:
load c:/tcl/lib/tclsqlite/tclsqlite3.dll sqlite3
sqlite3 db test.db
db eval {CREATE TABLE t1(a,b,c)}
db eval {INSERT INTO t1 VALUES(1,2,3)}
db eval {INSERT INTO t1 VALUES('hello',NULL,'world')}
db close
... works fine.
Please note the "slash" is "/" not "\".
D. Richard Hipp wrote:
On Fri, 2005-03-18 at 12:19 -0500, Peter G. Brown wrote:
Hello,
OS: Windows XP SP2
Directory: D:\Program Files\Tcl
Path has D:\Program Files\Tcl in it.
Tcl: Tcl/Tk 8.3 for Windows, Binary Distribution
Sqlite: sqlite 3.1
tclsqlite: tclsqlite-3.1

The first thing I would do is try the same thing
with Tcl/Tk 8.4 which has now been out for nearly
3 years.  I'm not sure SQLite will work with earlier
versions.

Re: [sqlite] tclsqlite3.dll Errors

[D. Richard Hipp]

On Fri, 2005-03-18 at 12:19 -0500, Peter G. Brown wrote:
> Hello,
> 
> OS: Windows XP SP2
> Directory: D:\Program Files\Tcl
> Path has D:\Program Files\Tcl in it.
> Tcl: Tcl/Tk 8.3 for Windows, Binary Distribution
> Sqlite: sqlite 3.1
> tclsqlite: tclsqlite-3.1
> 

The first thing I would do is try the same thing
with Tcl/Tk 8.4 which has now been out for nearly
3 years.  I'm not sure SQLite will work with earlier
versions.
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] tclsqlite3.dll Errors

[Peter G. Brown]

Hello,
OS: Windows XP SP2
Directory: D:\Program Files\Tcl
Path has D:\Program Files\Tcl in it.
Tcl: Tcl/Tk 8.3 for Windows, Binary Distribution
Sqlite: sqlite 3.1
tclsqlite: tclsqlite-3.1
tclsqlite3.dll is in D:\Program Files\Tcl\lib\tclsqlite
I have the following piece of code:
load tclsqlite
sqlite3 db test.db
db eval {CREATE TABLE t1(a,b,c)}
db eval {INSERT INTO t1 VALUES(1,2,3)}
db eval {INSERT INTO t1 VALUES('hello',NULL,'world)}
db close
and get the following error:
couldn't load library "tclsqlite": this library or a dependent library
could not be found in library path while executing
"load tclsqlite3"
(file "D:\Program Files\Tcl\examples\sqlite.tcl" line)
I try
load tclsqlite3.dll Sqlite3
... and get a slightly different version:
couldn't load library "tclsqlite3.dll": this library or a dependent
library could not be found in library path while executing
"load tclsqlite3.dll Sqlite3"
(file "D:\Program Files\Tcl\examples\sqlite.tcl" line)
I place tclsqlite3.dll in C:\Windows where I know it will be seen and
and try:
load tclsqlite
... no change to error.
I try:
load tclsqlite3.dll sqlite3 and get:
"Wish Application has encountered a problem and needs to close."
Pressing "Debug" and I get:
"Unhandled exception in wish83.exe (TCLSQLITE3.DLL): 0xC005: Access
Violation"
There are 9 entries on the sqlite user list referencing tclsqlite3.dll 
which I have checked/tried. No success. (The fact there is only 9 
entries means, I suspect, I am doing something fundamentally wrong.

TIA,
**
Peter Brown
Beasley Food Service, Inc.
**

Re: [sqlite] Proposal: limit the number of columns in a table to 2000.

[Edward Macnaghten]

I am an application programmer by trade, programming accountancy and 
inventory type packages using various SQLs.

2000 columns/tableis plenty for my use.  I do not see needing to go 
above that in any scneario.  If the need requires that you do need to go 
above that either the database design is wrong and needs redoing, or you 
should not really be using an engine like SQLite anyway!

Eddy
D. Richard Hipp wrote:
As currently implemented, there is no fixed limit to the number
of columns you can put in a table in SQLite.  If the CREATE TABLE
statement will fit in memory, then SQLite will accept it.  Call
the number of columns in a table K.  I am proposing to limit the
value of K to something like 2000.
Would this cause anyone any grief?

Re: [sqlite] It there a roadmap?

[D. Richard Hipp]

On Fri, 2005-03-18 at 01:06 +, chan wilson wrote:
>I was wondering there is a roadmap of SQLite since many users are 
> concerning what will the upcoming SQLite look like. :)
> 

SQLite roadmap:

   *  Add new features consistent with the mission of SQLite.

   *  Recode existing features to be smaller and/or faster.

   *  Always, always be backwards compatible.

   *  Keep the core database small and efficient - new features
  can be omitted using compile-time flags.

   *  Maintain test coverage above 95%

   *  Maintain and enhance code readability and understandability.

   *  Recruit commercial users of SQLite to provide financial
  support to accomplish all of the above. :-)

-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] atomic db replacement

[Eli Burke]

Andrew Piskorski wrote:
On Thu, Mar 17, 2005 at 08:33:03PM -0700, Ara.T.Howard wrote:
 

On Sat, 12 Mar 2005, Andrew Piskorski wrote:
   

On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
 

does anyone have a strategy for doing massive updates to a db and atomicly
replacing it in a multi-process situation?
You proposed procedure below is an ugly hack.  I do not know the
particulars of your situation, so maybe for you it really is justified
over the correct "use PostgreSQL" alternative.  But I would think long
and hard about that.
(And no, I don't know what the best/simplest way to do an "atomically
replace whole db" step is with SQLite.  That would be useful to know,
regardless.)
 

How about using a second in-memory database for your modifications, then 
using ATTACH to merge
the changes. I'm fairly sure I remember Dr. Hipp stating that moving 
complete rows between attached
database tables is very speedy. Depending on the particulars of your 
situation you could do a couple
different things:

* if you are just adding new rows, open an in-mem database and create an 
identical table to do all your
  inserts. Insert the new rows, then attach the db, and finally start a 
transaction and:
  INSERT INTO old-table SELECT * FROM memory.new-table;

* if you must modify existing data, you could do the process in 
reverse-- select the contents of one or
  more tables into the memory db, modify them, then inside a 
transaction, delete the contents of your
  main db's table(s) and select them back into the main table(s).

  If only one table is getting modified but the readers don't need to 
access it, this will get around the
  problem of one transaction holding an EXCLUSIVE lock for long periods 
of time. If you are touching
  more tables, you may have create and track some sort of dirty 
indicator or last update time.

Because you are using a transaction, it is still atomic. But because you 
are just moving the rows from
another database, it should solve the problem of holding the lock for 
too long. In-memory databases
are created by naming them ":memory:" You can find more info by doing a 
mailing list search on
"ATTACH in memory" or poking around the docs for ATTACH.

-Eli

RE: [sqlite] Proposal: limit the number of columns in a table to2000.

[Robert Simpson]

> -Original Message-
> From: rayB [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 17, 2005 7:14 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Proposal: limit the number of columns 
> in a table to2000.
> 
> I'm in the airline game. 379 columns is the widest table that 
> I can find in
> our production DB2 sub-systems - a highly denormalised table 
> as I'm sure you
> can imagine. Perhaps someone like FedEx or UPS may have 
> requirements to go
> real wide for their warehousing apps.

I've been writing Electronic Invoicing & Remittance applications for FedEx
for the last 10 years as an independent contractor, and I can tell you that
I've never seen anything close to that big with FedEx.  FedEx gives my
software (FedEx DirectLink) to their larger shipping accounts around the
world and the invoice data I'm working with is pretty massive at times.  As
a matter of fact, most of the airlines use the software as well :)

Robert

Re: [sqlite] atomic db replacement

[Andrew Piskorski]

On Thu, Mar 17, 2005 at 08:33:03PM -0700, Ara.T.Howard wrote:
> On Sat, 12 Mar 2005, Andrew Piskorski wrote:
> 
> >On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
> >
> >>does anyone have a strategy for doing massive updates to a db and atomicly
> >>replacing it in a multi-process situation?
> >
> >Why would you want to do that?  SQLite properly supports transactions, so
> >aren't you better of just using those?  What scenario are you working with
> >here?  Do you have a large number of readers that MUST not block while a
> >massive/slow update is done tot he database, or something like that?
> 
> precisely - active web site doing both reads and writes: long running update
> to perform.

If besides that one slow update you had ONLY READS (and those reads do
not care which version of the data they get, old or new), I'd say
sure, fine, an atomic "swap in a totally new db" operation might be
worth trying.

But for a database with active reads AND sometimes also writes, all
while that big slow update is going on?  No, even if your special
procedural scheme below works, the whole idea seems misguided.  If you
really must have the possiblity of other writes while that huge slow
update is happening, use an RDBMS which is actually designed to
support that scenario, like PostgreSQL.  SQLite is the wrong tool.

You proposed procedure below is an ugly hack.  I do not know the
particulars of your situation, so maybe for you it really is justified
over the correct "use PostgreSQL" alternative.  But I would think long
and hard about that.

(And no, I don't know what the best/simplest way to do an "atomically
replace whole db" step is with SQLite.  That would be useful to know,
regardless.)

> obviously not too much (but maybe something) will be happening at night.  my
> plan was
> 
>   lock db
>   take copy
>   note mtime
>   release lock
>   perform updates
>   lock db
>   if mtime has been updated
> retry
>   else
> perform atomic replacement
>   end
> 
> perhaps this is simply impossible with sqlite?

-- 
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/