Re: [sqlite] Usage of vacuum and auto vacuum

On Wed, 10 Feb 2010 10:05:34 +0530, wrote: >Hi All, > >I am Ramesh, facing come issue regarding DB malformed, find trace below. > > sqlite> pragma integrity_check; > *** in database main *** > Main freelist: 4 of 4 pages missing from overflow list starting at 0 > Page

Re: [sqlite] Usage of vacuum and auto vacuum

Hi kees Nuyt, I am not able to reply to group, I found option there to reply via email to U, Just did that, Please help me. Regards, Ramesh -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Kees Nuyt Sent: Wednesday, February

Re: [sqlite] Anyone able to access a SQLite database within a Tclstarpack?

Thanks, Alexey. SQLiteVFS a C-language routine for access any file system, on which the SQLite database is found. Doesn't appear to give me access to the Tcl VFS. The temp directory is one feasible option, thanks, although the cost of copying Megabytes of database file and then deleting it, seems

Re: [sqlite] Strange sqlite behaviour when calling from C

Dan Kennedy wrote: > That message is better interpreted as "failed to open some file". > Not necessarily the database file, the same message is returned if > sqlite fails to open or create a journal or temporary file. You were right. I thought I was running as root (I even though I had verified

Re: [sqlite] Usage of vacuum and auto vacuum

Hoi Ramesh, Please reply (again) to the list, not to me personally. On Tue, 16 Feb 2010 10:13:28 +0530, you wrote: >Hi, > >The sqlite version 3.5.8 3.5.8 is old. Too old for people to remember its quirks. I advise to upgrade to 3.6.22. >Regards, >Ramesh -- ( Kees Nuyt ) c[_]

Re: [sqlite] Strange sqlite behaviour when calling from C

Dan Kennedy wrote: > That message is better interpreted as "failed to open some file". > Not necessarily the database file, the same message is returned if > sqlite fails to open or create a journal or temporary file. Thanks, thats a useful hint. > First guess is that you do not have permission

Re: [sqlite] File locking to harsh?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marian Aldenhoevel wrote: > fcntl64(3, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=1073741824, > len=1}, 0xbfae5690) = -1 EACCES (Permission denied) > > I have verified that this is not a mundane issue of access privileges. I > can open /test in

[sqlite] File locking to harsh?

Hi, I am trying to use sqlite (3.6.22) on a linux-system that I have built from scratch. That system currently uses kernel 2.6.32.8 and is ucLibc-based. The problem I am facing is that sqlite3 cannot lock database files. Any statement that needs a lock tells me the database is locked

Re: [sqlite] Writing and reading a csv using sqlite3

On Tue, Feb 16, 2010 at 10:24:58AM +, Phil Hibbs scratched on the wall: > Thanks, Jay, you're absolutely right. I've encountered a few csv > incompatibilities myself, even within the same tool (one case used \" > whereas the other used ""). > > Well, except for your last point, I only wanted

Re: [sqlite] SQLite 3.6.22 ATTACH no longer works for files outside the current working directory

On Feb 15, 2010, at 11:36 PM, Hick Gunter wrote: > In SQLite 3.5.9 it used to be possible to write > > sqlite> ATTACH '/some/unix/file/name.db' AS mydb; > > > In SQLite 3.6.22 this results in the error message > > Error: unable to resolve operation I don't think the above is an SQLite error

Re: [sqlite] Two columns in one index, or one column for each index?

On 16 Feb 2010, at 12:28pm, tho...@tgohome.com wrote: > SELECT * FROM nodes > WHERE n_lat >= 51 AND n_lon >= -1 AND n_lat <= 53 AND n_lon <= 1; Take a look at the BETWEEN operator, section 2 of http://www.sqlite.org/optoverview.html However, this won't improve things much in your case.

[sqlite] Hash keys

Even though SQLite is small enough to be embedded in a phone, there are quite a few questions here about large databases and performance optimization. My question fits in with the latter. Have the SQLite architects considered adding hash key as an option to the b-tree? One of the main tables

Re: [sqlite] Two columns in one index, or one column for each index?

tho...@tgohome.com wrote: > Is there any performance gain or loss from stuffing two columns into one > index, e.x. > > CREATE INDEX `myindex1` ON `nodes` (`n_lat`, `n_lon`); > > compared to: > > CREATE INDEX `myindex2` ON `nodes` (`n_lat`); > CREATE INDEX `myindex3` ON `nodes` (`n_lon`);

[sqlite] Two columns in one index, or one column for each index?

Is there any performance gain or loss from stuffing two columns into one index, e.x. CREATE INDEX `myindex1` ON `nodes` (`n_lat`, `n_lon`); compared to: CREATE INDEX `myindex2` ON `nodes` (`n_lat`); CREATE INDEX `myindex3` ON `nodes` (`n_lon`); when doing a query like this: SELECT

Re: [sqlite] Crash in Rtree

On Feb 16, 2010, at 4:30 PM, Dair Grant wrote: > > Hi, > > I think I have run into a crashing bug in the Rtree module, > triggered by > changing the database page size. Thanks for working this out. A new version of rtree.c with the fix included is here:

Re: [sqlite] Writing and reading a csv using sqlite3

Thanks, Jay, you're absolutely right. I've encountered a few csv incompatibilities myself, even within the same tool (one case used \" whereas the other used ""). Well, except for your last point, I only wanted sqlite3.exe to script some unit tests, so it really is why I downloaded SQLite. I can

[sqlite] Crash in Rtree

Hi, I think I have run into a crashing bug in the Rtree module, triggered by changing the database page size. The summary is that I create a database with an Rtree, populate it with data, change the page size, and then crash when querying the Rtree. The sequence is: - Database is created,

Re: [sqlite] Prohibitive indexing time with large tables

Hello, Jérôme Nice to hear you finally joined us with this really interesting discussion ) > > To Max Vlasov: > > > in sorted order to sqlite base other 5 minutes, so about 10 minutes it > > total. First 5 minutes was possible since we exchange only offsets, > > not data > > and other 5 minutes

Re: [sqlite] Strange sqlite behaviour when calling from C

On Feb 16, 2010, at 7:30 AM, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > >> Hi all, >> >> I've got some relatively simple code that does a query and then >> does the following: >> >>const char *stmt = "DELETE FROM connect WHERE machine = 'xxx';" ; >> >>printf ("Before :

Re: [sqlite] Prohibitive indexing time with large tables

> I'm really surprised you're not seeing something from an increased > cache size. It has always made a very noticeable difference in my own > manipulations, but I think the largest table I've ever worked with > "only" had 6M rows. > Jay, increasing cache size really helps, but till some