Re: [sqlite] Strange issue with sqlite 3.7.9

On Wed, Jul 4, 2012 at 3:05 PM, Alan Chandler wrote: > > The commit referenced by that page: >> >>http://www.sqlite.org/src/info/b23ae131874bc5c621f0 >> >> went into 3.7.9. So the problem was probably introduced in >> 3.7.9, not 3.7.10. >> > > > Indeed - I just

Re: [sqlite] Bug in sqlite3_step

On Wed, Jul 4, 2012 at 8:06 AM, Igor Tandetnik wrote: > Nico Williams wrote: >> SQLite3 also needs to know the identifiers of schema elements at >> statement prep time. It might be nice to have a variant of >> sqlite3_prepare_v2() that takes a varargs

Re: [sqlite] Strange issue with sqlite 3.7.9

On 04/07/12 18:52, Dan Kennedy wrote: On 07/04/2012 08:26 PM, Alan Chandler wrote: Due to hardware problems with my Debian Stable server, I have just upgraded to Ubuntu-Server 12.04. I have installed sqlite3 and when I ask it the version (with .version) it replies SQLite 3.7.9 2011-11-01

Re: [sqlite] Strange issue with sqlite 3.7.9

On 07/04/2012 08:26 PM, Alan Chandler wrote: Due to hardware problems with my Debian Stable server, I have just upgraded to Ubuntu-Server 12.04. I have installed sqlite3 and when I ask it the version (with .version) it replies SQLite 3.7.9 2011-11-01 00:52:41

[sqlite] Strange issue with sqlite 3.7.9

Due to hardware problems with my Debian Stable server, I have just upgraded to Ubuntu-Server 12.04. I have installed sqlite3 and when I ask it the version (with .version) it replies SQLite 3.7.9 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e Which exactly complies with the

[sqlite] Standalone LUA regex that can be used in sqlite

Hello ! I did a modification to the LUA regex code to allow using it without LUA dependency so it can be used with sqlite as regex function. It's very light and small thus a good candidate to be included on sqlite. If you are interested on it you can download it here

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

Igor Tandetnik writes: > It doesn't matter. The whole point is that the key is constructed in > such a way that both procedures would arrive at the same result. That's really what was at the heart of my question: If separate value-by-value was necessary,

Re: [sqlite] Bug in sqlite3_step

On Wed, Jul 04, 2012 at 08:29:33AM -0500, Jay A. Kreibich scratched on the wall: > On Wed, Jul 04, 2012 at 01:09:01AM -0500, Nico Williams scratched on the wall: > > > But this would > > just be a glorified (if safer) variant of sqlite3_mprintf() -- for > > apps that allow users to manipulate the

Re: [sqlite] Bug in sqlite3_step

On Wed, Jul 04, 2012 at 09:06:16AM -0400, Igor Tandetnik scratched on the wall: > Nico Williams wrote: > > SQLite3 also needs to know the identifiers of schema elements at > > statement prep time. It might be nice to have a variant of > > sqlite3_prepare_v2() that takes a

Re: [sqlite] Bug in sqlite3_step

On Wed, Jul 04, 2012 at 01:09:01AM -0500, Nico Williams scratched on the wall: > But this would > just be a glorified (if safer) variant of sqlite3_mprintf() -- for > apps that allow users to manipulate the schema this could actually be > a good improvement. The sqlite3_*printf() family

Re: [sqlite] When to call VACUUM - revisited

On 4 Jul 2012, at 10:54am, Hauptmann Peter wrote: > However, they also have rough indicators, whether or not it's necessary > (fragmentation or > a recommendation when closing Outlook) > > Q: Are there any useful indicators to suggest a VACUUM? >(Or, to reverse it:

Re: [sqlite] Bug in sqlite3_step

Nico Williams wrote: > SQLite3 also needs to know the identifiers of schema elements at > statement prep time. It might be nice to have a variant of > sqlite3_prepare_v2() that takes a varargs list of parameters which > must be identifiers, and then have a syntax for

Re: [sqlite] When to call VACUUM - revisited

On 4 Jul 2012, at 10:54 AM, Hauptmann Peter wrote: > However, VACUUM is by far requiring the most time, and with most uncertain > results > (i.e. whether or not it improves subsequent performance). VACUUM exists only to release unused space from the database file. If you

[sqlite] When to call VACUUM - revisited

Hi List, I've read what I could find about the issue, this thread: http://thread.gmane.org/gmane.comp.db.sqlite.general/57770/focus=57775  pretty much gathers the positions, ranging from  - don't  - don't worry  - don't expect to much  - let the user decide The last is closest to my approach -

Re: [sqlite] Bug in sqlite3_step

SQLite3 also needs to know the identifiers of schema elements at statement prep time. It might be nice to have a variant of sqlite3_prepare_v2() that takes a varargs list of parameters which must be identifiers, and then have a syntax for referring to identifier parameters as opposed to value