[sqlite] what is "in-memory SQLite database"?

[jack wu]

in the documentation: "Appropriate Uses For SQLite" it
says: 

"it is often easier and quicker to load the data into
an in-memory SQLite database and use queries with
joins and ORDER BY clauses to extract the data in the
form and order needed rather than to try to code the
same operations manually"

i am wondering if there are more
information/documentations on how to do that? 

i am writing an application where i need to define
couple of huge hash tables. i load the data from disk,
populate the hash tables and use the tables during
execution. can i replace the hash tables using SQLite?
i am new to SQLite, so any information is helpful.  

jack.

[sqlite] SQLite3 and thread safety

[Cory Nelson]

I understand you are supposed to open a new sqlite3 connection for
every thread that needs access, but- would it be safe to wrap access
to the database with a mutex?  I've got code that needs to insert at
random times (sometimes many times per sec) and select once per sec in
another thread.  The inserting can really get to CPU usage so i want
to wrap it in a transaction that is closed/opened every time the
select is performed.

If there is a better way, I'm open to that too :)

-- 
Cory Nelson
http://www.int64.org

RE: [sqlite] Thanks!

[Fred Williams]

-Original Message-
From: Jay [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 1:43 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Thanks!



> >I believe writing C or C++ code is harder than writing interpreted
> >code. My aim has always been to produce the best product I could,
> >not to produce it with as little effort as possible. I hope the
> >extra effort was worth it. I guess time will tell if I chose
> >correctly.
> 
> One caveat of languages like C and C++ is that you are opening 
> yourself to several classes of potential security problems that 
> interpreted languages tend not to have.  You have to deal with things
> 
> like buffer overflow attacks, one of the more common kind, that can 
> come from you not crossing every "t" and dotting every "i" with your 
> memory management.  Interpreted languages take care of these sorts of
> 
> things for you, so they are orders of magnitude more secure by 
> default.  You have to put in a lot of effort with C and C++ to be 
> just as secure.  (Sure, the interpreter engines themselves could have
> 
> such problems, but they are exceedingly rare due to their common code
> 
> being heavily used and examined by a relatively large group.)  The 
> main advantages of C is that you can get the smallest possible 
> footprint and greatest possible speed; it is best applied to what 
> would be bottlenecks. -- Darren Duncan

One of the things the C++ experts take particular care to remind
everyone is that character arrays are evil. I thought using string
classes mostly elminated the buffer overflow problem. The string
class is heavily examined for such errors as are the intrepreters.

I'm seeing reports of vulnerabilities in interpreted languages
so I'm not sure I agree with that logic, or the orders of magnitude
comparison. Do you have any references or research on it? 

Interpreter authors write code with errors too.
If the interpreter gets tweaked every month the code
only gets 30 days of testing. Few of the packages I've seen
have any regression testing so new errors can be introduced
with each revision and old errors can reappear.

I should go look and see how they cracked php and string overflows.

I just consider it bare metal programming envy :-)

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sqlite] unrecognized token: ":"

[D. Richard Hipp]

On Thu, 2005-03-03 at 19:00 -0600, David Taylor-Fuller wrote:
>char* sqlStmt=sqlite3_mprintf("INSERT INTO %q
> (FileName,ArtistName,TrackNum,TrackName,AlbumName,Genre,Year) values
> (%q,%q,%q,%q,%q,%q,%q)",
> Can Someone please I beg of you explain to me why I am getting the
> following error message
> 
> unrecognized token: ":"
> 

You need to put the %q in quotes, like this:  '%q'.
Or else use %Q which adds the quotes for you
automatically.

-- 
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] unrecognized token: ":"

[David Taylor-Fuller]

Ok I have skimmed the archives and even though people have had similar
problems there solution all point to using '' as an escape instead of
'\. However that doesnt solve my problem. I am writting a mp3player
and wanted to use sqlite as the db backend for the library. Now all
was going well untill I try inserting anything into the table I have
created.

bool LibraryDB::Insert(SongInfo* info)
{
   int rCode;
   char* errMsg;
   char* sqlStmt=sqlite3_mprintf("INSERT INTO %q
(FileName,ArtistName,TrackNum,TrackName,AlbumName,Genre,Year) values
(%q,%q,%q,%q,%q,%q,%q)",
 "Library",
 info->fileName,

info->artistName,
 info->trackNum,

info->trackName,

info->albumName,
 info->genre,
 info->year);

   rCode=sqlite3_exec(m_db,sqlStmt,NULL,NULL,);
   if(rCode==SQLITE_OK)
   return true;

   printf(errMsg);
   return false;
}

there is the function I wrote.an example of the info structure that
gives me the error is below.

info=
{
char *fileName="D:\D'Angelo - Brown Sugar\01 - D'Angelo - Brown Sugar.mp3";
char* trackNum=NULL;
char* artistName"D'Angelo";
char* trackName="Brown Sugar";
char* albumName="Brown Sugar";
char* genre=NULL;
char* year="1995";

}

Can Someone please I beg of you explain to me why I am getting the
following error message

unrecognized token: ":"

Re: [sqlite] Thanks!

[Greg Miller]

[EMAIL PROTECTED] wrote:
After 15 years of assembler programming, I am still to find a compiler that
makes debugging and optimizing as easy as assembler.
I can't remember the number of times that C has got me deep into memory
leaks.

Then give C++ a try.
If you need low level programming, C is a good compromise.
If you need high level programming, C is a good compromise.
If you don't care about performance and need an idiot proof programming
language, try Java or perl.
Obviously C has a place but the day Java performs as well as C, who would
one to deal with all of those "shot your own foot" issues.

Java provides its own ways of shooting yourself in the foot. See the 
"finally" kludge for example.
--
http://www.velocityvector.com/ | http://glmiller.blogspot.com/
http://www.classic-games.com/  |
"We have declared a fierce war on this evil principle of
democracy and those who follow this wrong ideology,"
   -- Abu Musab al-Zarqawi

Re: [sqlite] Thanks!

[Darren Duncan]

At 11:43 AM -0800 3/3/05, Jay wrote:
One of the things the C++ experts take particular care to remind
everyone is that character arrays are evil. I thought using string
classes mostly elminated the buffer overflow problem. The string
class is heavily examined for such errors as are the intrepreters.
I'm seeing reports of vulnerabilities in interpreted languages
so I'm not sure I agree with that logic, or the orders of magnitude
comparison. Do you have any references or research on it?
Interpreter authors write code with errors too.
If the interpreter gets tweaked every month the code
only gets 30 days of testing. Few of the packages I've seen
have any regression testing so new errors can be introduced
with each revision and old errors can reappear.
I should go look and see how they cracked php and string overflows.
I say "orders of magnitude" if a class of errors is the one that 
occurs the most frequently, and only appears with the compiled 
languages.  By emiminating the most common problems, orders of 
magnitude improvement is gained.

With interpreters, any buffer overflows etc are only in the 
interpreter itself, and can never be in your own code written in the 
interpreted language.  Usually, the amount of code in the interpreter 
is many orders of magnitude smaller than the amount of code that is 
written in the interpreted language.  With C/C++ code, the entire 
code base can be suspect, but in an interpreted language, only the 
tiny fraction of the code making up the interpreter itself is 
suspect.  When the code base that can have such problems is a lot 
smaller, the total number of actual problems is smaller.

The greater part of my experience with interpreted languages is with 
Perl 5.8, which is used by tens or hundreds of thousands of 
programmers regularly, and whose source code is scrutinized and 
worked on by probably several dozens of people each day.  Perl 5.8 
also has a large and comprehensive unit test suite, including 
regression tests.  It is very hard for bugs to get by it.  Let me 
know if you're aware of any security vulnerabilities with Perl 5.8. 
The Parrot project also has strong regression testing, though that 
project is pre-alpha.

As for PHP, well I consider that specifically to be less elegant than 
many other interpreted languages, and much more likely to be buggy. 
This has a lot to do with its ad-hoc design principle, just throwing 
in features wherever, rather than having a more thought out system 
design.

All of the above being said, you do gain a lot of the same advantages 
of interpreted languages in C/C++ in regards to bugs and security 
when you use a library that is already well written to handle common 
tasks, as some other posters here mentioned.  In that respect, the 
interpreted language is alike, since you are implicitly using 
libraries rather than explicitly.

-- Darren Duncan

[sqlite] sqlite 3.1.0 code coverage of 41%

[Rouchy, Claire]

Hi,
I ran all the available tests for sqlite 3.1.0. I got a code coverage of 41%
I read that sqlite has a 90% code coverage, can someone provide the list of the
files instrumented ?
Thanks
Claire

Re: [sqlite] Thanks!

[Clay Dowling]

Jay said:

> I used cgicc.
> It's good workable code, but it's a pain sometimes to understand!

Agreed.  In fact I use cgic in either C or C++, since it's easy to use. 
The licensing is agreeable too, since even a commercial license is very
inexpensive.

Clay
-- 
Lazarus Notes from Lazarus Internet Development
http://www.lazarusid.com/notes/
Articles, Reviews and Commentary on web development

Re: [sqlite] Thanks!

[Jay]

> like try to write your own CGI parser.  Libraries like cgic at
> http://www.boutell.com/cgic/ and cgicc at http://www.cgicc.org make a
> lot
> more sense than reinventing that particular wheel yourself.  They
> also
> address the buffer overflow problem directly by using strings, or
> forcing
> the author to state how much data they are capable of receiving.
> 
> Now that I have my infrastructure libraries, C/C++ and PHP are about
> equivalent in speed for me to develop an app, and if complexity is
> involved C++ will be the best bet.

I used cgicc.
It's good workable code, but it's a pain sometimes to understand!






__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: [sqlite] Thanks!

[Jay]

--- [EMAIL PROTECTED] wrote:

> Agree, C is great and thanks God we got it in our asenal of tools. 
> But it
> is not pefect because of its own strengths.
> After 15 years of assembler programming, I am still to find a
> compiler that
> makes debugging and optimizing as easy as assembler.
> I can't remember the number of times that C has got me deep into
> memory
> leaks.
> If you need low level programming, C is a good compromise.
> If you need high level programming, C is a good compromise.
> If you don't care about performance and need an idiot proof
> programming
> language, try Java or perl.
> Obviously C has a place but the day Java performs as well as C, who
> would
> one to deal with all of those "shot your own foot" issues.
> Those are my 2 cents I am not trying to offend anybody.
> 

No worries :)
I have much the same experience.

Sorry if I came across as offended.




__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sqlite] Remote apps reading and writing data to the same DB

[Uriel_Carrasquilla]

John:
Check out SQL Relay at http://sqlrelay.sourceforge.net/
It will do locks but you can lock/unlock really fast.

Regards,

[EMAIL PROTECTED]
NCCI
Boca Raton, Florida
561.893.2415
greetings / avec mes meilleures salutations / Cordialmente
mit freundlichen Grüßen / Med vänlig hälsning


   
  John O'Neill 
  <[EMAIL PROTECTED]To:   

  south.net>   cc: 
   Subject:  [sqlite] Remote apps 
reading and writing data to the same DB
  03/03/2005 02:40 
  PM   
  Please respond to
  sqlite-users 
   
   




Hello all,

I have an application that is designed to run on multiple networked
machines simultaneously, and it is important to maintain speed (i.e. no
blocking write requests) while the main app is running.  At the same time,
a second application can open and read information from the DB.  All
machines have read/write access to a central directory where the main DB
file is stored.

Ultimately, I want all information to be stored in the one database file,
and I'm wondering how to handle the multiple writes from different
processes on separate machines.

I have currently designed a small wrapper around SQLite that does the
following for each of the remote connections:

1. Create a separate database file for a "transaction" which contains
multiple table insertions.  The tables already exist in the master DB, so
only the columns are new.
2. When enough data is stored in this temp DB, open the main DB and merge
the information.
3. Delete the temp DB and repeat the process for new information.

Is this overkill?  Should I simply allow all remote processes to directly
attach to the main database and issue "create temp table...commit"
commands?  What I'm basically doing here is creating a standalone database
to do what "create temp table" does when in the same process.

Thanks in advance for any recommendations or comments.
John

Re: [sqlite] Thanks!

[Clay Dowling]

Darren Duncan said:

> One caveat of languages like C and C++ is that you are opening
> yourself to several classes of potential security problems that
> interpreted languages tend not to have.

You are opening yourself to such problems only if you do something rash
like try to write your own CGI parser.  Libraries like cgic at
http://www.boutell.com/cgic/ and cgicc at http://www.cgicc.org make a lot
more sense than reinventing that particular wheel yourself.  They also
address the buffer overflow problem directly by using strings, or forcing
the author to state how much data they are capable of receiving.

Now that I have my infrastructure libraries, C/C++ and PHP are about
equivalent in speed for me to develop an app, and if complexity is
involved C++ will be the best bet.

Clay

-- 
Lazarus Notes from Lazarus Internet Development
http://www.lazarusid.com/notes/
Articles, Reviews and Commentary on web development

RE: [sqlite] correct use of sqlite3_get_table

[Richard Boyd]

Ok thanks for responding...

That was my understanding but I was wondering why it only returned 1 Row in
*pnRow. I've figured it out now (I think). The first row contains the column
name but does not count as a result. Hence the 1 row that is referred to in
*pnRow returned from sqlite3_get_table() is the single result I'm after.

Lo and behold, when I check the 2nd string referenced by the result pointer,
I get what I'm after!

Many thanks!
Richard.

-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED] 
Sent: 03 March 2005 19:31
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] correct use of sqlite3_get_table

Richard Boyd wrote:

> Hi all,
>
> I’m trying to use sqlite3_get_table() to execute SQL commands on a 
> database. I’ve included a code snippet below.
>
> The problem I’m having is that when I execute the "SELECT 
> MAX(time_stamp) FROM table32;” command using sqlite3_get_table() I 
> only get one column and 1 row returned and the result contains 
> “MAX(time_stamp)” rather than the value I’m after. When I run the same 
> command in sqlite3.exe shell I get the desired result (a single number).
>
> Any one any ideas where I’m going wrong with this??
>
Richard,

You need to read the documentation for the sqlite3_get_table() function 
at http://www.sqlite.org/capi3ref.html#sqlite3_get_table. It explains 
how the column header information is returned along with the actual 
data. You are looking at the heading for your column, the data is 
further into the results array.

HTH
Dennis Cote


-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 28/02/2005




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 28/02/2005

Re: [sqlite] Thanks!

[Jay]

> 
> can a similar argument be made for assembler?

Yes, but modern C compilers generate code that's 99% as good as
a human would write. I've tried to write better code in assembler
than the compiler does. I've managed it, but's it's pretty hard.

If you profile your code you generally find that the difference
between C and assembler to be not significant compared to other
factors. In my case speed is not material because even the worst
code on a really slow machine won't make the internet send the
data any faster.

The only place I've seen assembler used, aside from in the
computer in your microwave oven, is in the innermost rendering
loop in 3d game engines.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sqlite] Thanks!

[D. Richard Hipp]

On Thu, 2005-03-03 at 11:06 -0800, Darren Duncan wrote:
> The main advantages of C is that you can get the smallest possible 
> footprint and greatest possible speed; 
> 

That is not the reason CVSTrac is written in C.  CVSTrac is
written in C to reduce its administration burden.  You can 
drop a statically-linked C program in a cgi-bin directory
and it just works.  With scripts, it is usually not so simple.
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] correct use of sqlite3_get_table

[Dennis Cote]

Richard Boyd wrote:
Hi all,
I’m trying to use sqlite3_get_table() to execute SQL commands on a 
database. I’ve included a code snippet below.

The problem I’m having is that when I execute the "SELECT 
MAX(time_stamp) FROM table32;” command using sqlite3_get_table() I 
only get one column and 1 row returned and the result contains 
“MAX(time_stamp)” rather than the value I’m after. When I run the same 
command in sqlite3.exe shell I get the desired result (a single number).

Any one any ideas where I’m going wrong with this??
Richard,
You need to read the documentation for the sqlite3_get_table() function 
at http://www.sqlite.org/capi3ref.html#sqlite3_get_table. It explains 
how the column header information is returned along with the actual 
data. You are looking at the heading for your column, the data is 
further into the results array.

HTH
Dennis Cote

Re: [sqlite] Thanks!

[Uriel_Carrasquilla]

can a similar argument be made for assembler?

Regards,

[EMAIL PROTECTED]
NCCI
Boca Raton, Florida
561.893.2415
greetings / avec mes meilleures salutations / Cordialmente
mit freundlichen Grüßen / Med vänlig hälsning


   
  Darren Duncan
  <[EMAIL PROTECTED]To:   
sqlite-users@sqlite.org
  can.net> cc: 
   Subject:  Re: [sqlite] Thanks!
  03/03/2005 02:06 
  PM   
  Please respond to
  sqlite-users 
   
   




At 7:27 AM -0800 3/3/05, Jay wrote:
>I believe writing C or C++ code is harder than writing interpreted
>code. My aim has always been to produce the best product I could,
>not to produce it with as little effort as possible. I hope the
>extra effort was worth it. I guess time will tell if I chose
>correctly.

One caveat of languages like C and C++ is that you are opening
yourself to several classes of potential security problems that
interpreted languages tend not to have.  You have to deal with things
like buffer overflow attacks, one of the more common kind, that can
come from you not crossing every "t" and dotting every "i" with your
memory management.  Interpreted languages take care of these sorts of
things for you, so they are orders of magnitude more secure by
default.  You have to put in a lot of effort with C and C++ to be
just as secure.  (Sure, the interpreter engines themselves could have
such problems, but they are exceedingly rare due to their common code
being heavily used and examined by a relatively large group.)  The
main advantages of C is that you can get the smallest possible
footprint and greatest possible speed; it is best applied to what
would be bottlenecks. -- Darren Duncan

Re: [sqlite] Thanks!

[Darren Duncan]

At 7:27 AM -0800 3/3/05, Jay wrote:
I believe writing C or C++ code is harder than writing interpreted
code. My aim has always been to produce the best product I could,
not to produce it with as little effort as possible. I hope the
extra effort was worth it. I guess time will tell if I chose
correctly.
One caveat of languages like C and C++ is that you are opening 
yourself to several classes of potential security problems that 
interpreted languages tend not to have.  You have to deal with things 
like buffer overflow attacks, one of the more common kind, that can 
come from you not crossing every "t" and dotting every "i" with your 
memory management.  Interpreted languages take care of these sorts of 
things for you, so they are orders of magnitude more secure by 
default.  You have to put in a lot of effort with C and C++ to be 
just as secure.  (Sure, the interpreter engines themselves could have 
such problems, but they are exceedingly rare due to their common code 
being heavily used and examined by a relatively large group.)  The 
main advantages of C is that you can get the smallest possible 
footprint and greatest possible speed; it is best applied to what 
would be bottlenecks. -- Darren Duncan

Re: [sqlite] Thanks!

[Jay]

> > * An event management web site for a convention.
> > * Gentoo 2004
> > * Linux 2.4 kernel
> > * AMD Duron 600mhz w/ 256 meg RAM
> > * lighttpd web server
> > * C++ cgi
> > * sqlite backend database
> 
> I'm heartily glad to hear that I'm not the only poor deluded fool
> writing
> CGI apps in C and C++.  There's an article running in this month's
> Linux
> Journal on the topic (I'm the author).  I found it interesting that
> Reuven
> Lerner, in his "At The Forge" column in the same issue, mentioned
> that
> hardly anybody uses C for CGI development.  He's right, but I still
> found
> it humorous given the juxtaposition.

Congrats on getting your article published! :)

After being hacked using other distros several times I
decided to get serious about security. I also wrote about
my adventures in one of the Linux magazines.

I picked Gentoo because I could customize my system to *any* degree
I desired. That box has almost nothing on it that isn't
necessary for its function. The stuff it does
run has as few features as possible. Less is more when it reduces
vulnerabilities. I haven't been hacked since so it must be working,
or I'm very lucky.

The minimalist approach also helps it perform well on what's
considered 'obsolete' hardware. The previous server was even
smaller hardware wise and served 3+ static pages per day
for years. The new server will have more work to do with the
dynamic pages.

Part of the minimalist approach was to not use interpreted code
in web pages. It's harder to hack the box if there's no
perl/php/python/ruby interpreter available.

The Lighttpd and Boa webservers perform very well with minimal
overhead. They both avoid the use of threads and forking for speed.
Lighttpd adds the ability to use ssl and access control that boa lacks.

I've been told interpreted languages can run as fast as compiled
but I've not seen a good example of it. The executable for the
interpreter alone is larger than a good fraction of my cgi apps
added together. There's enough RAM in the box I suspect everything
is in cache, so load time may not be a non issue. I would bet my
raw executable is faster than interpreted code, but that's probably
not an issue either since the bottleneck is almost certainly the
connection to the internet. I probably assemble packets pretty
quickly, but if they don't get to the user any faster who cares?
I've considered rewriting in FastCGI but so far the performance
seems more than adequate.

Sqlite performs very well speed wise. It does what I need and
helped me remove one more possible vulnerability. If there's
no database server nobody can hack it! The only thing I could
wish for is the ability to change the locking methodology on
the fly. There are times when I really do want to do dirty
reads. It's probably not going to be an issue until I get
as busy as google though.

I believe writing C or C++ code is harder than writing interpreted
code. My aim has always been to produce the best product I could,
not to produce it with as little effort as possible. I hope the
extra effort was worth it. I guess time will tell if I chose
correctly.

Thanks for letting me know I'm not the only regressive weirdo out
there!





__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: [sqlite] Thanks!

[D. Richard Hipp]

On Thu, 2005-03-03 at 08:33 -0500, Clay Dowling wrote:
> I'm heartily glad to hear that I'm not the only poor deluded fool writing
> CGI apps in C and C++. 

FWIW, the CVSTrac program used for bug tracking on www.sqlite.org
is a C program that runs as CGI and uses SQLite as its database
backend.  http://www.cvstrac.org/
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] Thanks!

[Clay Dowling]

Jay said:
> My project:
>
> * An event management web site for a convention.
> * Gentoo 2004
> * Linux 2.4 kernel
> * AMD Duron 600mhz w/ 256 meg RAM
> * lighttpd web server
> * C++ cgi
> * sqlite backend database

I'm heartily glad to hear that I'm not the only poor deluded fool writing
CGI apps in C and C++.  There's an article running in this month's Linux
Journal on the topic (I'm the author).  I found it interesting that Reuven
Lerner, in his "At The Forge" column in the same issue, mentioned that
hardly anybody uses C for CGI development.  He's right, but I still found
it humorous given the juxtaposition.

Clay Dowling
-- 
Lazarus Notes from Lazarus Internet Development
http://www.lazarusid.com/notes/
Articles, Reviews and Commentary on web development

Re: [sqlite] Race condition in testThreadLockingBehavior?

[Christopher R. Palmer]

D. Richard Hipp wrote:
On Thu, 2005-03-03 at 07:30 -0500, Christopher R. Palmer wrote:
It looks to me like this test assumes that no other process currently has a 
lock on this file.  If any other process has any lock on this file, I 
believe one or both of the locking calls will fail which will trick sqlite 
into believing that the locks are fd specific, not process specific.

Am I reading this right?
I do not know if this is right or not.
The test in question only occurs once per process, the first time
a lock is acquired on any file.  If the problem is as you describe,
a simple work-around would be to open a dummy database (perhaps in /tmp)
and do a BEGIN EXCLUSIVE in order to get the test to run.  The close
and delete that database.  Once the test has run, the system knows
the locking behavior of the system it is running on and will not
attempt the test again.
And an equivalent code fix would be to not reuse the current fd for the 
test.  Instead, open a temporary file in the testThreadLockingBehavior 
function...

Cheers,
Chris.
--
Christopher R. Palmer [EMAIL PROTECTED]
Chief Technology Officer  www.vivisimo.com
Vivisimo, Inc.

Re: [sqlite] Race condition in testThreadLockingBehavior?

[D. Richard Hipp]

On Thu, 2005-03-03 at 07:30 -0500, Christopher R. Palmer wrote:

> It looks to me like this test assumes that no other process currently has a 
> lock on this file.  If any other process has any lock on this file, I 
> believe one or both of the locking calls will fail which will trick sqlite 
> into believing that the locks are fd specific, not process specific.
> 
> Am I reading this right?
> 

I do not know if this is right or not.

The test in question only occurs once per process, the first time
a lock is acquired on any file.  If the problem is as you describe,
a simple work-around would be to open a dummy database (perhaps in /tmp)
and do a BEGIN EXCLUSIVE in order to get the test to run.  The close
and delete that database.  Once the test has run, the system knows
the locking behavior of the system it is running on and will not
attempt the test again.
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

[sqlite] Race condition in testThreadLockingBehavior?

[Christopher R. Palmer]

I am using version 3.0.8 of sqlite.
In the course of trying to track down a strange error in my application 
where I very infrequently get a database is locked error (even though my 
busy timeout is set to some insanely large number, like a billion seconds), 
I was looking through the code is os_unix.c.

sqlite3OsOpenReadWrite calls
findLockInfo with the open fd which calls
threadThreadLockingBehavior
the thread locking behaviour test dups the fd and then creates two threads 
that try to get a shared lock and an exclusive lock respectively (and fail 
immediately if they cannot acquire the lock).  If both of these calls 
succeed, then it is determined that the locks are process wide and not per fd.

It looks to me like this test assumes that no other process currently has a 
lock on this file.  If any other process has any lock on this file, I 
believe one or both of the locking calls will fail which will trick sqlite 
into believing that the locks are fd specific, not process specific.

Am I reading this right?
Cheers,
Chris.
--
Christopher R. Palmer [EMAIL PROTECTED]
Chief Technology Officer  www.vivisimo.com
Vivisimo, Inc.

Re: [sqlite] Good Graphical Tool for 3.x

[Igor Gorbounov]

Hi!
Detlef Groth wrote:
Hello,
You can try my program dgSQLite. I recently added sqlite3 support:
http://goblet.molgen.mpg.de/dgSQLite3.kit
You need a tclkit runtime from:
http://www.equi4.com/pub/tk/downloads.html
in order to run it.
 

[...]
I've tried it for Linux (Fedora Core 3) : ./tclkit-linux-x86 dgSQLite3.kit
and a very long window opened with complains, it begins with "couldn't 
open "setup.tcl":
no such file" and so on.
Does it really work on Linux?
   Igor Gorbounov

RE: [sqlite] Good Graphical Tool for 3.x

[Detlef Groth]

Hello,

You can try my program dgSQLite. I recently added sqlite3 support:

http://goblet.molgen.mpg.de/dgSQLite3.kit

You need a tclkit runtime from:

http://www.equi4.com/pub/tk/downloads.html

in order to run it.

The old version for sqlite2 is at:
http://www.microemacs.de/tcltk_dgsqlite.html

OS's supported are: Win32,Linux and OSF1. Other can be added as well
if the tclsqlite-shared lib is provided.

Please be aware that there is no warranty of any kind. Currently i
just stick with sqlite2 because my R-library still remains sqlite2 and
I can't change this.

regards,
Detlef


>
>Thanx, I tried that would last night, unfortunately the trial version is
>so crippled its worthless.
>
>>
>> The SqlitePlus Database Manager is pretty good.  Its very similar to
>> Microsoft
>> SQL Query Analyzer.  Here is the URL:
>>
>> www.sqliteplus.com
>>
>>
>> Quoting Tim McDaniel <[EMAIL PROTECTED]>:
>>
>>>