While doing currency math, a useful money class at following link, may be
used as a a reference.
http://www.di-mare.com/adolfo/p/money.htm
Yet Another C++ Money Class (by Adolfo Di Mare), The C Users Journal, Vol.10
No.4, pp [58-64], April 1992
Rohit.
--
View this message in context:
Hi,
On 8/25/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> I assume you're referring to this:
>
> http://marc.info/?l=sqlite-users=118737502703454=2
>
Yep, that's it.
> In that specific case, the parens are not needed. But that's not always
> the case. In general, LEFT OUTER JOIN is not
Please look at the following link, for few easy-to-use free simple
code-packages (two or three) for Encryption and Decryption.
http://www.efgh.com/software/
Rohit
--
View this message in context:
http://www.nabble.com/Looking-for-a-cryptographic-library-tf4298572.html#a12334506
Sent from the
Hi,
Will Sqlite uses indexes when
using the like operator
as below,
select * from tbl where '9845' like column || '%'
order by des limit 1;
regards
ragha
**
This email and its attachments contain
RaghavendraK 70574
<[EMAIL PROTECTED]> wrote:
Will Sqlite uses indexes when
using the like operator
as below,
select * from tbl where '9845' like column || '%'
order by des limit 1;
No. Next time you have a similar question, be aware you can find out
yourself by prepending your query with
sorry.
regards
ragha
**
This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the
That is an interesting way to store money. We developed a fixed point
arithmetic library of arbitrary precision using the algorithms described
by Knuth in his semi-numerical algorithms volume and using standard
DECIMAL(n,m) definition. Rounding is precise using an algorithm which
does not
Maybe you should look at using FTS to get indexed text searching.
RaghavendraK 70574 wrote:
sorry.
regards
ragha
**
This email and its attachments contain confidential information from HUAWEI,
which is
Hi, guys.
I have some questions about multithreading in SQLite:
a) If one thread "BEGIN" and after that another thread try to "BEGIN".
What will with the second thread? How I understand there is nothing
wrong. Is it right?
b) The same one only when second thread "BEGIN" after first thread
Igor Mironchick <[EMAIL PROTECTED]>
wrote:
a) If one thread "BEGIN" and after that another thread try to "BEGIN".
What will with the second thread? How I understand there is nothing
wrong. Is it right?
No problem. It's OK for two or more threads to issue BEGIN statement.
Such a statement
You need to be prepared to get a busy status after each Sqlite3_step.
If you launch a sqlite3_step while a transaction which is executing an
INSERT or UPDATE is current, you will get an SQLITE_BUSY. If you get a
BUSY, try again until the condition clears.
Igor Mironchick wrote:
Hi, guys.
I
John Stanton <[EMAIL PROTECTED]> wrote:
You need to be prepared to get a busy status after each Sqlite3_step.
Not really. Only the very first sqlite3_step after a prepare or reset
can get SQLITE_BUSY. If it succeeds, the connection has acquired a
SHARED lock and subsequent steps are
How about the case of a simple BEGIN which sets a deferred lock so that
the busy will occur when that lock is promoted later in the the transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects requiring that provision be
made
John Stanton <[EMAIL PROTECTED]> wrote:
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
I'm not sure I understand your question.
http://sqlite.org/lockingv3.html says that a simple BEGIN
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects requiring that provision be
Igor Mironchick <[EMAIL PROTECTED]>
wrote:
What about this:
char * errors;
// I guarante that here no errors in SQL syntaxis.
char * sql = "SELECT * FROM data";
sqlite3_exec( db, "BEGIN", 0, 0, 0 );
int ret = sqlite3_exec( db, sql, 0, 0, );
What's the point of running a SELECT statement
What about this:
char * errors;
// I guarante that here no errors in SQL syntaxis.
char * sql = "SELECT * FROM data";
sqlite3_exec( db, "BEGIN", 0, 0, 0 );
int ret = sqlite3_exec( db, sql, 0, 0, );
What's the point of running a SELECT statement without actually
reading the returned rows?
Igor Mironchick wrote:
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to better
concurrency, but does have other effects
John Stanton <[EMAIL PROTECTED]> wrote:
Igor, I confused the issue with names. The correct name is a
"reserved" lock, created when a simple transaction is launched in
"deferred"
mode. Here is the Sqlite explanation.
A BEGIN IMMEDIATE or EXCLUSIVE will acquire a write lock immediately.
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to
better concurrency, but does have other effects requiring that
provision be
Igor Mironchick <[EMAIL PROTECTED]>
wrote:
while( ret != SQLITE_OK )
{
std::cerr << "There is some errors while executing SQL statement:
" << errors << std::endl;
sqlite3_free( errors );
ret = sqlite3_exec( db, sql, 0, 0, );
Why do you want to keep running the same statement over and
How about the case of:
BEGINsets reserved lock on thread one
SELECT promotes lock to shared on thread one
BEGIN sets reserved lock from thread two
SELECT promotes reserved lock in thread two to shared
...at this point two threads are simultaneously processing
Igor Mironchick wrote:
How about the case of a simple BEGIN which sets a deferred lock so
that the busy will occur when that lock is promoted later in the the
transaction?
As I understand it the deferred lock capability is conducive to
better concurrency, but does have other effects
Based on the description quoted by Igor-2 the situation below would not
occur because the reserved lock is not set until the INSERT is
intercepted. Since there can be only one reserved lock current, a busy
can occur at that point.
As I recall that logic counteracts write starvation by
John Stanton <[EMAIL PROTECTED]> wrote:
How about the case of:
BEGINsets reserved lock on thread one
You mean BEGIN IMMEDIATE, right?
SELECT promotes lock to shared on thread one
I'm not sure what you mean by "promotes" here. If anything, RESERVED
lock is a superset of
You're confused about the locking; see http://sqlite.org/lockingv3.html
On 8/26/07, John Stanton <[EMAIL PROTECTED]> wrote:
> How about the case of:
> BEGINsets reserved lock on thread one
No lock.
> SELECT promotes lock to shared on thread one
Thread one acquires SHARED lock.
>
You are correct about the reserved lock. I looked back at my notes
instead of using memory. It is only set when the database is about to
have something written to it, and it stops further reserved locks from
being set. A reserved lock is promoted to a pending lock which stops
further shared
Travor, absolutely correct. my apology for misleading everyone.
Trevor Talbot wrote:
You're confused about the locking; see http://sqlite.org/lockingv3.html
On 8/26/07, John Stanton <[EMAIL PROTECTED]> wrote:
How about the case of:
BEGINsets reserved lock on thread one
No lock.
John Stanton <[EMAIL PROTECTED]> wrote:
More correctly:
BEGIN Thread one
BEGIN Thread two
INSERT Thread one sets reserved lock
INSERT Thread two, fails to set reserved lock
SELECT Thread two, set shared lock
COMMIT on thread one
29 matches
Mail list logo
