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 th
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 h
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. A
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
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
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 inp
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
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 "21234567890123456789
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 en
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
sqlite-users@sqlite.
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 Messa
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 r
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 outstand
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
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: W
> -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?
>
>
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: sqlite-users-boun...
to be clear...
"in other words, two threads sharing a connection in shared cache mode will
always cause SQLITE_LOCKED (rather than SQLITE_BUSY) when contention occurs
_between the two threads_. if contention occurs from another connection (i.e.
a connection in a different process) SQLITE_BUSY
i'm no expert on this, but my understanding is that since shared cache mode
'shares a connection' you won't get SQLITE_BUSY but rather SQLITE_LOCKED since
the contention is 'internal' to the connection.
in other words, two threads sharing a connection in shared cache mode will
always cause SQLI
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 'LOCKE
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: Wed
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 Beh
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 need
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
__
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
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 featuring strict typing.
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
s
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 it
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]
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 2
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 join
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
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:
>
>
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
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
>
>
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 PARAM_DET
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
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 different RDBMS seems to treat
> 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 l
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 treat
> nulls differently in th
40 matches
Mail list logo