Hello,
I learned about the use of ANALYZE command recently. In my
application, SQLIte file is generated once and never modified.
Currently my application creates SQLIte database, creates required
tables, indexes and inserts records into it. As a last step, it runs
VACUUM.
I am wondering should I
On 6/25/2013 10:13 PM, Woody Wu wrote:
1. When a exclusive transation started and not yet commit, I found if I
open another connection to the same database and try to access it (using
sqlite3_step), I got the error code SQLITE_MISUSE. It sounds a little
strange because I thought the error code
Hi,
I have serveral questions about exclusive transaction. (version 3.7.x)
1. When a exclusive transation started and not yet commit, I found if I
open another connection to the same database and try to access it (using
sqlite3_step), I got the error code SQLITE_MISUSE. It sounds a little
On Tue, Jun 25, 2013 at 9:40 PM, Jay A. Kreibich wrote:
> On Tue, Jun 25, 2013 at 11:49:00PM +0100, Simon Slavin scratched on the
> wall:
> Your other point still stands, however... as soon as _step() returns
> SQLITE_DONE, it is best to call _reset() before doing anything
On Tue, Jun 25, 2013 at 11:49:00PM +0100, Simon Slavin scratched on the wall:
>
> On 25 Jun 2013, at 11:45pm, Yuriy Stelmakh wrote:
>
> > I assumed that commit would take care of sync, but because my
> > statement was never finalized/reset after last use, it didn't it
> >
On Tue, Jun 25, 2013 at 6:44 PM, Eric Sink wrote:
>
> From reading sqlite3.c and the comments therein, it would appear that
> BEGIN IMMEDIATE TRANSACTION never invokes the busy handler.
>
> Is that correct?
>
Correct. BEGIN IMMEDIATE returns SQLITE_BUSY if it cannot
i'm caching the statements for later use, so i assume just doing reset
is also ok? it seemed to work well.
Again thank you for help, wasted a few days on this.
Thanks,
Yuriy
On Jun 25, 2013, at 6:49 PM, Simon Slavin wrote:
>
> On 25 Jun 2013, at 11:45pm, Yuriy Stelmakh
On 25 Jun 2013, at 11:45pm, Yuriy Stelmakh wrote:
> I assumed that commit would take care of sync, but because my
> statement was never finalized/reset after last use, it didn't it
> seems..
You always need to _finalize(). Getting the data you asked for is not the end
of
In the sample code I did not indeed. But in the actual code that i'm
using, the prepared statement used was part of bulk insert surrounded
by begin transaction/ commit transaction. I was reseting the stmt
before it was used inside of transaction and not after, so it caused a
problem.
this is what
From reading sqlite3.c and the comments therein, it would appear that
BEGIN IMMEDIATE TRANSACTION never invokes the busy handler.
Is that correct?
--
E
___
sqlite-users mailing list
sqlite-users@sqlite.org
On Tue, Jun 25, 2013 at 6:32 PM, Yuriy Stelmakh wrote:
> Thank you! that did the trick. Its interesting that even though you
> can commit a transaction, the cache sync doesn't happen until you
> finalize or reset all you statements. I wish this was documented
> somewhere
Thank you! that did the trick. Its interesting that even though you
can commit a transaction, the cache sync doesn't happen until you
finalize or reset all you statements. I wish this was documented
somewhere better!
Thanks,
Yuriy
On Jun 25, 2013, at 2:19 PM, Richard Hipp
On Tue, Jun 25, 2013 at 2:06 PM, Yuriy Stelmakh wrote:
> Hi all, please help: very strange issue that should not be happening:
>
>
>
> 1. Have two connections to same database: _db1 and _db2.
>
> 2. Create table in _db1
>
> 3. Run count * from _db2 ->
This is on OSX and iOs 6. Sqlite versions tested were 3.7.13 & 3.7.17
Database file is stored on disk. Mac OSX journaled partion HFS+.
Thanks,
Yuriy
On Jun 25, 2013, at 2:09 PM, Simon Slavin wrote:
>
> On 25 Jun 2013, at 7:06pm, Yuriy Stelmakh
On 25 Jun 2013, at 7:06pm, Yuriy Stelmakh wrote:
> Hi all, please help: very strange issue that should not be happening:
Please verify:
Which operating system are you using ? And which version ?
Is the database file stored on the hard disk of the computer running the
Hi all, please help: very strange issue that should not be happening:
1. Have two connections to same database: _db1 and _db2.
2. Create table in _db1
3. Run count * from _db2 -> returns 0
4. Insert 1 row using _db1 –OK
5. Run select * from _db2 -> 0 rows
On Jun 25, 2013, at 11:19 AM, Nißl Reinhard wrote:
> because it stays in quotation mode until it finds a further ", which is
> incorrect. Quotation mode may only get activated when " appears at the
> beginning of a column value.
Meh… check the recent "escape quote for
Great :-)
I guess that PRAGMA temp_store=MEMORY then does not add additional
performance on Windows and I can safely let it to DEFAULT or FILE.
This will avoid the excessive memory usage during VACUUM for my use case.
Thanks.
-- Mario
___
Correction - Official CSV fields may not start with specifically CR/LF before quotes as it is the official record delimeter for CSV,
but it may well contain them within quotes in a single field.
Thanks.
On 2013/06/25 12:21, RSmith wrote:
...//it may also start with any whitespace characters
Hi Reinhard - studying this CSV formatting (and file-formatting in general) is somewhat of a hobby of mine and have solved many
issues around it, so I can tell you that your request is a border case and found nowhere else in CSV realms. I think that whatever
system is making the files you are
Hi,
for example, it cannot import the column value
19" rack
because it stays in quotation mode until it finds a further ", which is
incorrect. Quotation mode may only get activated when " appears at the
beginning of a column value.
Once the line has been broken into column
21 matches
Mail list logo