Re: [sqlite] shared cache mode and 'LOCKED'

Let's say we have the three connections in that diagram, and two tables named t1 and t2. I'll use a simple syntax to describe some concurrency scenarios: con#>>t# will mean con# writes to t# Commas will separate concurrent attempted operations After the operations will be a pipe '|' followed by

Re: [sqlite] Late data typing. Am I missing something?

Strings have a number of other disadvantages in this case. They take more computations to compare, they take time to parse when you read them, and they take longer to build when you insert them. Generally, storing dates as a number of some sort is ideal. Building a query to return the value as a

Re: [sqlite] Late data typing. Am I missing something?

Jay A. Kreibich wrote: >> -Original Message- >> From: sqlite-users-boun...@sqlite.org >> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen >> Sent: Wednesday, October 28, 2009 3:11 PM >> To: General Discussion of SQLite Database >> Subject: Re: [sqlite] Late data typing.

Re: [sqlite] Late data typing. Am I missing something?

John Crenshaw wrote: > SQLite has plenty of date editing routines. Dates are stored in a double > as a Julian date. Well, that's one way of doing it. I store them as strings because I wanted a human-readable format. The downside is that this requires 19 bytes instead of 8. I wish SQLite could

Re: [sqlite] How to input a double num?

liubin liu wrote: > Now I use the sqlite3_mprintf() and the "%f" to get the double num. My code > is below. > > Now there is a num like "212345678901234567890123456.988290112". With the > way of "sqlite3_mprintf()" and "%f", the num is cut to > "2123456789012346000.00". > > > How to

Re: [sqlite] How to input a double num?

liubin liu wrote: > Now I use the sqlite3_mprintf() and the "%f" to get the double num. My code > is below. > > Now there is a num like "212345678901234567890123456.988290112". With the > way of "sqlite3_mprintf()" and "%f", the num is cut to > "2123456789012346000.00". > > > How to

Re: [sqlite] How to input a double num?

Bad plan. Use prepared statements and bind. Otherwise you're going to create SQL injection vulnerabilities. Prepared statements are faster and easier to read anyway. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of liubin

[sqlite] How to input a double num?

Now I use the sqlite3_mprintf() and the "%f" to get the double num. My code is below. Now there is a num like "212345678901234567890123456.988290112". With the way of "sqlite3_mprintf()" and "%f", the num is cut to "2123456789012346000.00". How to input the num

Re: [sqlite] shared cache mode and 'LOCKED'

i guess this isn't that complicated. the error codes even say basically what you've said: #define SQLITE_BUSY 5 /* The database file is locked */ #define SQLITE_LOCKED 6 /* A table in the database is locked */ i guess the point is that separate connections normally lock the

Re: [sqlite] re gular expression search

SqliteSpy has RegExp functionality. -- View this message in context: http://www.nabble.com/regular-expression-search-tp25916275p26102979.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list

Re: [sqlite] shared cache mode and 'LOCKED'

Almost. Locking happens at a table level in this case, not a database level. Three different threads can all write at the same time, if they write to different tables. But, if two threads write try to the same table at the same time, one of them will return SQLITE_LOCKED. John -Original

Re: [sqlite] shared cache mode and 'LOCKED'

oh, right. my bad. i don't mean to share a connection between two threads, but rather that each thread (with its own connection) in the same process where shared cache mode is enabled will cause SQLITE_LOCKED error rather than SQLITE_BUSY error when these threads contend for the DB. is this

[sqlite] test DBD::SQLite 1.26_06 please

All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI Driver) version 1.26_06 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.26_06/ TESTING NEEDED! Please bash the hell out of the latest DBD::SQLite and report any

Re: [sqlite] shared cache mode and 'LOCKED'

I don't know. Elsewhere it says you really shouldn't use the same connection in multiple threads. I use a different connection in each thread. With the shared cache, this results in very little overhead, so I'm unsure why you would need to do this the "not recommended" way. The contention between

Re: [sqlite] shared cache mode and 'LOCKED'

and here is the link to the thread where i received the below advice: http://sqlite.org:8080/cgi-bin/mailman/private/sqlite-users/2009-October/016404.html -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent Sent:

Re: [sqlite] Late data typing. Am I missing something?

> -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen > Sent: Wednesday, October 28, 2009 3:11 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Late data typing. Am I missing something? > >

Re: [sqlite] SELECT * vs SELECT columns ?

You could use EXPLAIN to see if there is a different query plan, but I'd bet there isn't. * will generally be slower, just because you usually won't need EVERY column. If you can specify only certain columns, that will save you some time. John -Original Message- From:

Re: [sqlite] shared cache mode and 'LOCKED'

It appears to be up to date. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen Sent: Wednesday, October 28, 2009 1:45 PM To: General Discussion of SQLite Database Subject: [sqlite] shared cache mode and

Re: [sqlite] Late data typing. Am I missing something?

Yeah, the code is fortunately all there, so once you know what you're looking for it is easy to copy out, but it should have been exposed in the API. John -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen Sent:

Re: [sqlite] Late data typing. Am I missing something?

You can get close if you put some check constraints on the columns. I must agree with other posters that the lack of an exposed timestamp type does feel like something of a gap. Owen -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On

Re: [sqlite] Late data typing. Am I missing something?

SQLite's data typing means it can support any and all field types supported in any other SQL database. That's a big deal. For the most part, the proper method for accessing any given data is going to be simple and universal. Homegrown routines will only happen if people have specific homegrown

Re: [sqlite] how to get the Trigger's Raise err in Application

greensparker schrieb: > i want the trigger's raise error in QT call. Try this in Qt: QString msg; QVariant v = QSqlDatabase::database().driver()->handle(); sqlite3 *handle = *static_cast(v.data()); if (handle != 0) msg =sqlite3_errmsg(handle); Jan

Re: [sqlite] Late data typing. Am I missing something?

On 28 Oct 2009, at 5:57pm, Ted Rolle wrote: > Doesn't dynamic data typing lead to bad data? > And proliferation of home-grown editing routines? True in an application which interacts with a user. Not true in a database backend. SQLite does not at any time interact with a user: it does not

Re: [sqlite] Late data typing. Am I missing something?

Ted Rolle wrote: > Doesn't dynamic data typing lead to bad data? No. Buggy programs lead to bad data. > It seems that a strict data typing at column definition time would be > MUCH better. For instance, date-editing routines... There is no shortage of database systems

[sqlite] Late data typing. Am I missing something?

Doesn't dynamic data typing lead to bad data? And proliferation of home-grown editing routines? It seems that a strict data typing at column definition time would be MUCH better. For instance, date-editing routines... Ted ___ sqlite-users mailing list

[sqlite] shared cache mode and 'LOCKED'

Hi Everyone, Does anyone know if this page is still up to date with respect to when you get "SQLITE_LOCKED" when operating in shared cache mode ? http://www.sqlite.org/cvstrac/wiki?p=DatabaseIsLocked (I'm trying to solve a two writers problem and am trying to understand the best way to solve

Re: [sqlite] SELECT * vs SELECT columns ?

I don't know about SQLite, but in all SQL courses you learn that you should NEVER use the asterisk. The asterisk is merely there to let you quickly view data _manually_. > Date: Wed, 28 Oct 2009 16:02:01 +0200 > From: mi...@limbasan.ro > To: sqlite-users@sqlite.org > Subject: Re: [sqlite]

Re: [sqlite] Conditional JOIN

Jay, First, yes I screwed up on the table data examples. The 3/SPECIAL TAbleA values should have shown 2 3/STANDARD TableB entries. My brain is hurting too! Anyway, the main thing is that your latest suggestion works perfectly so thanks for your help, I appreciate it. Pete On Oct

Re: [sqlite] SELECT * vs SELECT columns ?

I would expect there to be a speed and memory performance *impact* if the result set contains columns other than the three specified ones, since obviously the library will need to allocate more memory to hold the extra data. On 10/28/2009 03:52 PM, Pete56 wrote: > I am searching across two

[sqlite] SELECT * vs SELECT columns ?

I am searching across two joined tables and am interested in a few parameters: SELECT a.first a.third b.first FROM a JOIN b ON a.RowID = b.RowID WHERE value = :value Is there any speed or memory performance improvement by using SELECT *, rather than SELECT ? If I know there will only be one

Re: [sqlite] how to get the Trigger's Raise err in Application

thnks igor , the return type of q.exe is bool bool QSqlQuery::exec ( const QString & query ) q.lasterror() returned QSqlError(19, "Unable to fetch row", "constraint failed") I dont know how to track this. i want the trigger's raise error in QT call. Thnks Bala Igor Tandetnik wrote: > >

Re: [sqlite] Performance issues for "WITH x IN (y)" - fixed with "x = y"

I've seen this too! Had to refactor my "x IN (y)" code... Perhaps the optimizer can be improved for this particular case? > Date: Tue, 27 Oct 2009 11:06:14 -0700 > From: t...@zimbra.com > To: sqlite-users@sqlite.org > Subject: [sqlite] Performance issues for "WITH x IN (y)" - fixed with "x

Re: [sqlite] Grammar of "X is Y"

Whoops, sorry, you are perfectly correct. I've been caught out like this before, the online docs tantalising me with features that aren't in my version of sqlite. I suppose I must restrict myself to the locally-installed docs for my version. Cheers, Tom Sillence 2009/10/27 D. Richard Hipp

Re: [sqlite] how to get the Trigger's Raise err in Application

greensparker wrote: > im using QT4.5 and sqlite3 > > im using BEFORE INSERT TRIGGER for validation purpose > [is it good idea to put validation on before_insert_trigger???] You could have a CHECK constraint in the table definition instead. > IN QT im inserting as > q.exec("insert into

[sqlite] how to get the Trigger's Raise err in Application

hi, im using QT4.5 and sqlite3 im using BEFORE INSERT TRIGGER for validation purpose [is it good idea to put validation on before_insert_trigger???] im generating err , when the validation fails like create TRIGGER MobileValid BEFORE INSERT on PARAM_DETAILS when new.PARAM_CODE=12 BEGIN

Re: [sqlite] Grammar of "X is Y"

Scott Hess wrote: > On Tue, Oct 27, 2009 at 9:35 PM, John Crenshaw > wrote: >> Meh, I don't want it THAT badly. I'm just saying that's how it should >> have been in the original design of the SQL language. In fact though, it >> probably wouldn't have mattered. Every

Re: [sqlite] Grammar of "X is Y"

> sqlite> select 1 is 2; > SQL error: near "2": syntax error > sqlite> select 1 is null; > 0 > > It seems to me the documentation is wrong here. That said I'd > much rather the behaviour of sqlite changed to match the docs > rather than vice-versa because I really want to write neat > queries

Re: [sqlite] Grammar of "X is Y"

On Tue, Oct 27, 2009 at 9:35 PM, John Crenshaw wrote: > Meh, I don't want it THAT badly. I'm just saying that's how it should > have been in the original design of the SQL language. In fact though, it > probably wouldn't have mattered. Every different RDBMS seems to