Re: [sqlite] Seemingly random Access violation errors

Matthew Dumbleton wrote: > > I have managed to get hold of a HTC HD2 device to do testing on and > have unfortunately found the error still occurs using the small test > application I sent you a while back. > I've just made some experimental changes (on the "threadAbortProtect" branch),

Re: [sqlite] Seemingly random Access violation errors

Kevin Benson wrote: > > > > > Matthew Dumbleton wrote: > > > > > > I have managed to get hold of a HTC HD2 device to do testing on and have > > > unfortunately found the error still occurs using the small test > > application > > > I sent you a while back. > > > > > > > Looking at your sample

Re: [sqlite] light weight write barriers

Lying hardware is a different problem. Richards was asking for something else. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] light weight write barriers

On 11 Oct 2012, at 10:41pm, Nico Williams wrote: > On Thu, Oct 11, 2012 at 11:59 AM, Simon Slavin wrote: >> On 11 Oct 2012, at 5:38pm, Nico Williams wrote: >>> There is something you can do: use a combination of COW on-disk

Re: [sqlite] light weight write barriers

On Thu, Oct 11, 2012 at 11:59 AM, Simon Slavin wrote: > On 11 Oct 2012, at 5:38pm, Nico Williams wrote: >> There is something you can do: use a combination of COW on-disk >> formats in such a way that it's possible to detect partially-committed >>

Re: [sqlite] Data type information for derived columns

On Wed, Oct 10, 2012 at 8:21 PM, jkp487-sql...@yahoo.com wrote: > New to SQLite. Is there a way to get column data type information for > derived columns in a query or view? For example, if I have something like > this: > > > select Customer.LastName || Customer.FirstName

Re: [sqlite] light weight write barriers

To expand a bit, the on-disk format needs to allow the roots of N of the last transactions to be/remain reachable at all times. At open time you look for the latest transaction, verify that it has been written[0] completely, then use it, else look for the preceding transaction, verify it, and so

Re: [sqlite] light weight write barriers

On Wed, Oct 10, 2012 at 12:48 PM, Richard Hipp wrote: >> Could you list the requirements of such a light weight barrier? >> i.e. what would it need to do minimally, what's different from >> fsync/fdatasync ? > > For SQLite, the write barrier needs to involve two separate inodes.

Re: [sqlite] light weight write barriers

I am not quite whether I should ask this question here, but in terms of light weight barrier/fsync, could anyone tell me why the device driver / OS provide the barrier interface other than some other abstractions anyway? I am sorry if this sounds like a stupid questions or it has been discussed

Re: [sqlite] Ordering of fields in a join

Hi - > Adding the warning to the explain plan output should work well. It'd be a good place for it, I'd agree - it'd've saved me a trawl through the documentation and posting to this list! :) Thanks, Hamish ___ sqlite-users mailing list

Re: [sqlite] Ordering of fields in a join

Adding the warning to the explain plan output should work well. ... And yet the coding mistake in the SQL query was very subtle. It makes me wonder if we shouldn't somehow come up with a "warning" mechanism in SQLite to give developers a heads-up on error-prone constructs, such as using ==

Re: [sqlite] Ordering of fields in a join

On Thu, Oct 11, 2012 at 10:20 AM, Pavel Ivanov wrote: > On Thu, Oct 11, 2012 at 7:09 AM, Hamish Symington > wrote: > >> Note that I was mistaken earlier when I said that "X=Y" and "Y=X" should > >> result in the same answer. If X and Y have

Re: [sqlite] Ordering of fields in a join

On Thu, Oct 11, 2012 at 7:09 AM, Hamish Symington wrote: >> Note that I was mistaken earlier when I said that "X=Y" and "Y=X" should >> result in the same answer. If X and Y have different default collating >> sequences, then X=Y does not mean the same thing as Y=X

Re: [sqlite] Ordering of fields in a join

Hello, > In your schema, SaleItem_SaleUUID collates using NOCASE and Picture_UUID > collates using BINARY. I think you mean SaleItem_PictureUUID, not SaleItem_SaleUUID, but yes. > Note that I was mistaken earlier when I said that "X=Y" and "Y=X" should > result in the same answer. If X and Y

Re: [sqlite] Ordering of fields in a join

On Wed, Oct 10, 2012 at 10:53 AM, Hamish Symington < ham...@lightbluesoftware.com> wrote: > > If I perform the query > > SELECT SaleItem.*, Picture_FileName FROM SaleItem LEFT JOIN Picture ON > SaleItem_PictureUUID=Picture_UUID WHERE SaleItem_SaleUUID = 'DAB8FE97- > D308-4809-B496-E55142DC05B5' >

Re: [sqlite] Please test the latest SQLite enhancements

On Thu, Oct 11, 2012 at 8:23 AM, Eleytherios Stamatogiannakis < est...@gmail.com> wrote: > Is the covering index scan optimization enabled in the mentioned > amalgamation? > Yes. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

[sqlite] sqlite3.dll no longer operative

I am using 64bit Window 7 on my stand alone Toshiba Computer. Recently I lost a Hard Drive and had it replaced. All is well but during activation of the computer a pop-up is on the screen that says that "sqlite3.dll" has been lost and I need to download and replace the file. I have looked and

[sqlite] light weight write barriers

Richard Hipp writes: > > We would really, really love to have some kind of write-barrier that is > lighter than fsync(). If there is some method other than fsync() for > forcing a write-barrier on Linux that we don't know about, please enlighten > us. Could you list the requirements of such a

Re: [sqlite] Seemingly random Access violation errors

On Thu, Oct 11, 2012 at 6:07 AM, Joe Mistachkin wrote: > > Matthew Dumbleton wrote: > > > > I have managed to get hold of a HTC HD2 device to do testing on and have > > unfortunately found the error still occurs using the small test > application > > I sent you a while

Re: [sqlite] Please test the latest SQLite enhancements

Is the covering index scan optimization enabled in the mentioned amalgamation? For large datasets it can speed up the queries a lot. l. On 09/10/12 20:19, Richard Hipp wrote: SUMMARY: If you have a complex application that uses SQLite, please test your application with the SQLite

Re: [sqlite] Ordering of fields in a join

On Thu, Oct 11, 2012 at 3:13 AM, Hamish Symington < ham...@lightbluesoftware.com> wrote: > > > If you run ANALYZE on your database, SQLite will have more information > with > > which to estimate the run-time of each plan, and is more likely to choose > > the faster on. At the very least, it much

Re: [sqlite] Ordering of fields in a join

Hello, > Perhaps try the forthcoming 3.7.15 preview: > http://www.sqlite.org/sqlite3-20121009.zip > See "Please test the latest SQLite enhancements" for details: > http://comments.gmane.org/gmane.comp.db.sqlite.general/77259 Still present in that, as well. I should note (from further

Re: [sqlite] Seemingly random Access violation errors

Matthew Dumbleton wrote: > > I have managed to get hold of a HTC HD2 device to do testing on and have > unfortunately found the error still occurs using the small test application > I sent you a while back. > Looking at your sample code again, the use of Thread.Abort could be causing problems.

Re: [sqlite] Seemingly random Access violation errors

Matthew Dumbleton wrote: > > I noticed in your testce code that when the code the threads are running > ('TestThreadStart()') in the multi-thread test do not seem to 'close()' > their connections once finished. Is there a reason for this (i.e. should > close() not be called?) or is it just part

Re: [sqlite] Building SQLite on Windows Embedded Compact 7(WEC7)

Caleb A. Austin wrote: > > Added near line 14092: > #define HAVE_LOCALTIME_S 0 > Since the SDK you are using does not appear to provide the localtime_s function, even though it uses MSVC and its associated CRT, this makes sense. This could be defined in the Makefile and/or project properties

Re: [sqlite] Ordering of fields in a join

Hi - >> I was under the impression that the order of fields in the ON clause >> doesn't matter. Is this impression incorrect? > It doesn't matter for the answer. You get the same result either way, > right? Just one way is faster than the other. True, I do get the same result. > If

Re: [sqlite] Seemingly random Access violation errors

Matthew Dumbleton wrote: > > Just in case it's of any use I have attached a text file with the end > of the logging from the HD2 crash. > Yes, it is useful. I've noticed something interesting; however, I'm not 100% sure what it means given that the output appears to be incomplete.