Re: [sqlite] Accesing database remotely

[Roger Binns]

I've also seen Google search results where "optimistic" or "opportunistic"
caching on Windows clients may cause data corruption, in the context of
other file-based database libraries.
Oplocks by themselves won't cause corruption.  The way oplocks work is that
the file server tells the client they are the only ones with the file
open, so the client can cache stuff, doesn't have to send all writes and
locking through immediately etc.  If another client opens the same file,
then that is held up and the first client is asked to relinquish the oplock.
The first client will then send uncommitted data, apply any locks etc
and then the second client will have the open succeed.
This scheme allows significant performance improvements in the situation
where only one machine has a file open, or many machines have a read-only
file open.
The default configuration of Samba and Windows servers is to give out 
oplocks.  Since the Windows CIFS server is part of the kernel, it
can hold up opens by any other process to maintain data integrity.
Samba can ensure that other Samba connections maintain data integrity,
but it can't do so for other UNIX processes.

The lesson is that you should be *very* careful if you have multiple
network protocols to the same file (eg CIFS/SMB and NFS) or are
mixing local and remote access to the same file.
There is also another failure mode which is the client having an
oplock, and telling the process using SQLite that all the data
is safely committed.  Then when the file is closed, or an oplock
break message is received being unable to actually send the data
back to the server, or not doing so in a timely enough manner.
Windows clients always ask for oplocks by default.  Generally you
can cause oplocks not to be held by opening the same file again
with different permissions (eg request read only).  Use ethereal
to verify if the oplock is broken.
Roger

Re: [sqlite] SQLite Advocacy

[Jay]

The other important thing to remember is that this only shows
desktop systems. Servers are much more likely to be linux or
Sun than desktops and Servers don't surf  :)

--- Greg Miller <[EMAIL PROTECTED]> wrote:

> D. Richard Hipp wrote:
> > On Mon, 2005-01-31 at 11:31 -0600, [EMAIL PROTECTED] wrote:
> > 
> >> 99% of the world is on windows
> > 
> > 
> > I can't speak for the whole world, but visitors to the 
> > SQLite website over the past two weeks break out something 
> > like this:
> > 
> > Windows:  80.6%
> > Linux:14.9%
> > Mac:   4.5%
> > 
> > (There was really an 11.8% "other" or "not reported" which
> > I omitted then scaled the numbers above accordingly.)
> 
> Last time I checked Google Zeitgeist, they were reporting that 92%
> (or 
> was it 93%?) of visitors used Windows. Kind of makes those claims of 
> Internet Explorer having 95% marketshare back at its peak seem kind
> of 
> silly. 95% would have been right at 100% of Windows and Mac users.
> -- 
> http://www.velocityvector.com/ | http://www.indie-games.com/
> http://www.classic-games.com/  | http://glmiller.blogspot.com/
> "We have declared a fierce war on this evil principle of
> democracy and those who follow this wrong ideology,"
> -- Abu Musab al-Zarqawi
> 


=

-

"Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of 
the ancient tomb of the petrified pharaoh, he vowed there would be no curse on 
him like on that other Lord, unless you count his marriage to Lady Tarlington 
who, when the lost treasure was found, will be dumped faster than that basket 
in the bulrushes."
  Melissa Rhodes
-

The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's 
Call
http://www.lulu.com/content/77264



__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

Re: [sqlite] Accesing database remotely

[Ng Pheng Siong]

On Mon, Jan 31, 2005 at 05:09:56PM -0500, Stephen C. Gilardi wrote:
> You may get it to work, but using an sqlite database file on a network 
> file system has been reported to be troublesome.  

FWIW I wrote a test program that wrote to a database file on a network
drive concurrently from several PCs. All PCs ran Win98. I tested with the
network drive being a Win98 share and Samba on FreeBSD (it was a
dual-boot). It worked _for_me_. YMMV.

>  in a section entitled "How To 
> Corrupt Your Database Files":

I've also seen Google search results where "optimistic" or "opportunistic"
caching on Windows clients may cause data corruption, in the context of
other file-based database libraries.

Cheers.

-- 
Ng Pheng Siong <[EMAIL PROTECTED]> 

http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption

Re: [sqlite] SQLite Advocacy

[Greg Miller]

D. Richard Hipp wrote:
On Mon, 2005-01-31 at 11:31 -0600, [EMAIL PROTECTED] wrote:
99% of the world is on windows

I can't speak for the whole world, but visitors to the 
SQLite website over the past two weeks break out something 
like this:

Windows:  80.6%
Linux:14.9%
Mac:   4.5%
(There was really an 11.8% "other" or "not reported" which
I omitted then scaled the numbers above accordingly.)
Last time I checked Google Zeitgeist, they were reporting that 92% (or 
was it 93%?) of visitors used Windows. Kind of makes those claims of 
Internet Explorer having 95% marketshare back at its peak seem kind of 
silly. 95% would have been right at 100% of Windows and Mac users.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.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] joining a table to the end of another table

[Dan Kennedy]

> Many thanks for the replies.
> 
> I knew it must be something simple!!
> 
> Cheers,
> R.

> insert into combined_table
> select * from table0
> union
> select * from table1

Note that 'union' will eliminate duplicate rows. Use 'union all' instead
if you don't want this.




__ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

Re: [sqlite] Accesing database remotely

[Stephen C. Gilardi]

You may get it to work, but using an sqlite database file on a network 
file system has been reported to be troublesome.  Here is a quote from 
 in a section entitled "How To 
Corrupt Your Database Files":


SQLite uses POSIX advisory locks to implement locking on Unix. On 
windows it uses the LockFile(), LockFileEx(), and UnlockFile() system 
calls. SQLite assumes that these system calls all work as advertised. 
If that is not the case, then database corruption can result. One 
should note that POSIX advisory locking is known to be buggy or even 
unimplemented on many NFS implementations (including recent versions of 
Mac OS X) and that there are reports of locking problems for network 
filesystems under windows. Your best defense is to not use SQLite for 
files on a network filesystem.


Reliable locking is necessary for sqlite to succeed in allowing more 
than one process to access the database contents without corruption.

There is more discussion of this in the mailing list archives and in 
the sqlite source files.

--Steve
On Jan 31, 2005, at 4:44 PM, Richard Boyd wrote:
Hi,
I’m writing a database that will be accessed remotely over Ethernet. I 
had started to write a protocol that would float on top of TCP/IP but 
after reading some posts here it seems that it would be overkill. Is 
it practical to access the database file remotely and run commands on 
it from the remote PC? Are there going to be problems with sharing 
conflicts with more than one application accessing the database 
simultaneously? I know from reading some Sqlite documentation that 
there is some protection built into Sqlite. Does it work automatically 
or is there something I’d have to do at the operating system level?

FYI: I’m using Linux for the computer where the database is stored and 
windows for the machine that will remotely access the database over 
Ethernet.

Thanks again,
Richard.
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005

RE: [sqlite] SQLite Advocacy

[Downey, Shawn]

Some good comments everyone.  Thank you very much.  Sorry to derail the
technical discussions here to such an extent.  

I just wanted to say that I read everyone's replies and I am making most
of the changes requested.  Especially the good comments from cirisme -
Thanks.

And yes Dr. Hipp is quite familiar the program I am discussing, ACD,
since he wrote it.

Shawn M. Downey
MPR Associates
632 Plank Road, Suite 110
Clifton Park, NY 12065
518-371-3983 x3 (work)
860-508-5015 (cell)

[sqlite] Accesing database remotely

[Richard Boyd]

Hi,

 

I’m writing a database that will be accessed remotely
over Ethernet. I had started to write a protocol that would float on top of
TCP/IP but after reading some posts here it seems that it would be overkill. Is
it practical to access the database file remotely and run commands on it from
the remote PC? Are there going to be problems with sharing conflicts with more
than one application accessing the database simultaneously? I know from reading
some Sqlite documentation that there is some protection built into Sqlite. Does
it work automatically or is there something I’d have to do at the
operating system level?

 

FYI: I’m using Linux for the computer where the
database is stored and windows for the machine that will remotely access the
database over Ethernet.

 

Thanks again,

Richard.






No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005

RE: [sqlite] joining a table to the end of another table

[Richard Boyd]

Many thanks for the replies.

I knew it must be something simple!!

Cheers,
R.

-Original Message-
From: John LeSueur [mailto:[EMAIL PROTECTED] 
Sent: 31 January 2005 21:27
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] joining a table to the end of another table

Richard Boyd wrote:

> Hi,
>
> I’m inexperienced with databases so forgive me if this is a silly 
> question.
>
> What I want to do is join to separate tables together into one table. 
> This is to enable me to synchronize databases held on remote systems. 
> I would use a master table which would have the dates of each update 
> and then I could see which databases need updated so that they all the 
> same.
>
> Every time I add data to the main database I put it in a new table, 
> with exactly the same structure as its predecessors. Then updating is 
> a simple matter of checking to see which tables I have on the remote 
> machine and then copying across the tables which are not there. My 
> problem is I’m unclear how to link multiple tables sequentially. I’ve 
> looked into joins but they seem to be a way of performing relational 
> searches which is not what I’m after.
>
> See example below if it’s not clear what I’m looking to do:
>
> Table 0 Table1
>
> 0 | A 5 | F
>
> 1 | B 6 | G
>
> 2 | C 7 | H
>
> 3 | D
>
> 4 | E
>
> Combined table
>
> 0 | A
>
> 1 | B
>
> 2 | C
>
> 3 | D
>
> 4 | E
>
> 5 | F
>
> 6 | G
>
> 7 | H
>
> I’m sure there’s a simple way to do it but I’m not sure how.
>
> Thanks in advance…
>
> Richard
>
>
>
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005
>  
>
insert into combined_table
select * from table0
union
select * from table1

John


-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005

Re: [sqlite] joining a table to the end of another table

[Darren Duncan]

At 9:05 PM + 1/31/05, Richard Boyd wrote:
See example below if it's not clear what I'm looking to do:
Table 0  Table1
0 | A 5 | F
1 | B 6 | G
2 | C 7 | H
3 | D
4 | E
Combined table
0 | A
1 | B
2 | C
3 | D
4 | E
5 | F
6 | G
7 | H
I'm sure there's a simple way to do it but I'm not sure how.
Richard, try the UNION ALL operator, something like this:
  SELECT a, b FROM t0
  UNION ALL
  SELECT a, b FROM t1
-- Darren Duncan

Re: [sqlite] joining a table to the end of another table

[Jay]

Other database engines provide methods of doing this, but I
don't think sqlite does. I would use an insert statement that uses
select to copy the content of one table into the other.

insert into X(field1,field2) select field1,field2 from Y


--- Richard Boyd <[EMAIL PROTECTED]> wrote:

> Hi, 
>  
> I’m inexperienced with databases so forgive me if this is a silly
> question.
>  
> What I want to do is join to separate tables together into one table.
> This
> is to enable me to synchronize databases held on remote systems. I
> would use
> a master table which would have the dates of each update and then I
> could
> see which databases need updated so that they all the same.
>  
> Every time I add data to the main database I put it in a new table,
> with
> exactly the same structure as its predecessors. Then updating is a
> simple
> matter of checking to see which tables I have on the remote machine
> and then
> copying across the tables which are not there. My problem is I’m
> unclear how
> to link multiple tables sequentially. I’ve looked into joins but they
> seem
> to be a way of performing relational searches which is not what I’m
> after.
>  
> See example below if it’s not clear what I’m looking to do:
>  
> Table 0  Table1
> 0 | A 5 | F
> 1 | B 6 | G
> 2 | C 7 | H
> 3 | D
> 4 | E
>  
> Combined table
> 0 | A
> 1 | B
> 2 | C
> 3 | D
> 4 | E
> 5 | F
> 6 | G
> 7 | H
>  
> I’m sure there’s a simple way to do it but I’m not sure how.
>  
> Thanks in advance…
> Richard
>  
>  
> > No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005
> 


=

-

"Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of 
the ancient tomb of the petrified pharaoh, he vowed there would be no curse on 
him like on that other Lord, unless you count his marriage to Lady Tarlington 
who, when the lost treasure was found, will be dumped faster than that basket 
in the bulrushes."
  Melissa Rhodes
-

The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's 
Call
http://www.lulu.com/content/77264

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

[sqlite] joining a table to the end of another table

[Richard Boyd]

Hi, 

 

I’m inexperienced with databases so forgive me if this
is a silly question.

 

What I want to do is join to separate tables together into
one table. This is to enable me to synchronize databases held on remote systems.
I would use a master table which would have the dates of each update and then I
could see which databases need updated so that they all the same.

 

Every time I add data to the main database I put it in a new
table, with exactly the same structure as its predecessors. Then updating is a
simple matter of checking to see which tables I have on the remote machine and
then copying across the tables which are not there. My problem is I’m
unclear how to link multiple tables sequentially. I’ve looked into joins
but they seem to be a way of performing relational searches which is not what I’m
after.

 

See example below if it’s not clear what I’m
looking to do:

 

Table 0  Table1

0 | A 5
| F

1 | B 6
| G

2 | C 7
| H

3 | D

4 | E

 

Combined table

0 | A

1 | B

2 | C

3 | D

4 | E

5 | F

6 | G

7 | H

 

I’m sure there’s a simple way to do it but I’m
not sure how.

 

Thanks in advance…

Richard

 

 






No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.1 - Release Date: 27/01/2005

Re: RE(1): RE(1): [sqlite] SQLite Advocacy

[Dick Davies]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [0120 19:20]:
> As well, what if you want to move the database to another machien to 
> distribute workload.  

> Well, our bug tracking system Swatter we did use Sqlite but we had to write 
> the thead syncronization layer.  
> In fact, it is a .nET application that runs across a web service or a sockets 
> layer, to a sqlite database eventually.  

Well, if you're doing that you probably want a database server.
Using sqlite for that seems a bit like 'when all you have is a hammer' syndrome.

-- 
'Blackmail's such an ugly word. I prefer extortion. The x makes it sound cool.'
-- Bender
Rasputin :: Jack of All Trades - Master of Nuns

Re: RE(1): [sqlite] SQLite Advocacy

[D. Richard Hipp]

On Mon, 2005-01-31 at 11:31 -0600, [EMAIL PROTECTED] wrote:
>  99% of the world is on windows

I can't speak for the whole world, but visitors to the 
SQLite website over the past two weeks break out something 
like this:

Windows:  80.6%
Linux:14.9%
Mac:   4.5%

(There was really an 11.8% "other" or "not reported" which
I omitted then scaled the numbers above accordingly.)
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: RE(1): [sqlite] SQLite Advocacy

[Dick Davies]

* Brass Tilde <[EMAIL PROTECTED]> [0121 18:21]:
> > If you install MS SQL server you run a network based service that
> > is vulnerable to attack. If you run Sqlite you don't run any
> > service and thus are invulnerable (to network service based
> > infections).
> 
> Not relevant.  No reference to "network service based infections" was made
> in the original post.

Whether a reference is made or not, it's still relevant. If a server listens
to the network its potentially vulnerable, whereas sqlite is effectively a file,
so long as the host computer (or more accurately host account) is secured you
are safe.
 
> > Yes, any executable can be infected, but that's a meaningless statement
> > since you can't have any database without executable code.
> 
> Then saying that SQLite won't be a source of virus infections is also
> meaningless, since "you can't have any [SQLite] database without executable
> code," which executable code can be infected.

Yes, but since it's cross-platform, you can run it on something other than
windows, which like it or not is the number one cause and target of viruses
on the net today.


-- 
'You were doing well until everyone died'
-- God
Rasputin :: Jack of All Trades - Master of Nuns

Re: [sqlite] SQLite Advocacy

[D. Richard Hipp]

On Mon, 2005-01-31 at 09:27 -0500, Downey, Shawn wrote:
> In our organization, my management is debating the use of SQLite vs. MS
> SQL Server 7 for an upcoming MS Windows project. 

As it turns out, I am familiar with the software that Mr. Downey
refers to and can state with confidence that his management
is asking the wrong question.  The question is not SQLite vs.
SQLServer but rather, should one database be selected over the
other.  The answer is "no".

Mr. Downey's software was written in the 90s, originally
for HPUX and an Informix database.  It has, at various times,
included database backends for

* Informix
* PostgreSQL
* SQLite 
* Oracle

There might be others that I do not know about.  The software
is highly database agnostic.  It does very little other than
some simple SELECTs with an occasional INSERT or UPDATE thrown
in.  There are no triggers, views, or even subqueries.  Any
database that is remotely SQL compatible should work.  The 
database interface is very modular - it should not take more
than an afternoon to write a driver for yet another database
engine.

If my guess is right, the version of the software that Mr. Downey
is using has only drivers for SQLite.  This is likely the case
because SQLite is the best solution for the particular problem
and also because of the various available drivers, only the
SQLite driver is cross-platform.  (The Informix driver
requires esql on HPUX and the PostgreSQL and Oracle drivers
require Linux.)

The software that Mr. Downey is working on has survived to
this day because it is cross-platform.  It was designed from 
the beginning to using any SQL database engine and to run on
any reasonably modern operating system.  Other contemporaneous
software that was specific to HPUX and Informix has by this
time all but died off.  Mr. Downey's software has been able
to adapt and has therefore survived.

The lesson is simply this:  Do not choose.  Do not make an
arbitrary choice for one particular database engine - make it
work with all that you have at hand.  Do not code for just
one operating system - port early and often.  It sounds like
this would be a lot more work, but experience suggests that
the opposite is true.  Portable software turns out to be much
easier (and less costly) to write and maintain.  Especially
long-term.

So if the question is asked about whether you should port
program A to SQLServer or port program B to SQLite, the right
answer should be to port both programs to both databases.
Then deploy whichever database best meets the needs of the
moment.
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: RE(1): [sqlite] SQLite Advocacy

[Jay]

> > If you install MS SQL server you run a network based service that
> > is vulnerable to attack. If you run Sqlite you don't run any
> > service and thus are invulnerable (to network service based
> > infections).
> 
> Not relevant.  No reference to "network service based infections" was
> made in the original post.

It seems silly to limit your arguments to things people have
already thought of. The best arguments are those that tell people
about points they may not have already considered.

Being vulnerable to viral infection is ALWAYS a relevant consideration
for any professional.

> 
> > Yes, any executable can be infected, but that's a meaningless
> statement
> > since you can't have any database without executable code.
> 
> Then saying that SQLite won't be a source of virus infections is also
> meaningless, since "you can't have any [SQLite] database without
> executable
> code," which executable code can be infected.

Let me rephrase then:

The advantage of Sqlite over Sql Server is that it gives you one *less*
vulnerability.

Since there's no network service there's no network service
vulnerability. I assume all the other methods of viral vulnerability
(infected executables, sql injection attacks, etc.) are equivalent for
both Sql server and Sqlite.



=

-

"Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of 
the ancient tomb of the petrified pharaoh, he vowed there would be no curse on 
him like on that other Lord, unless you count his marriage to Lady Tarlington 
who, when the lost treasure was found, will be dumped faster than that basket 
in the bulrushes."
  Melissa Rhodes
-

The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's 
Call
http://www.lulu.com/content/77264



__ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

Re: RE(1): RE(1): [sqlite] SQLite Advocacy

[Jay]

--- [EMAIL PROTECTED] wrote:

> Let me clarify then.  100% of our customer want web based.  With .NET
> and SQL server we can throw in our data adapter and be off to the
> races.  We don't have to worry about future scalability.  With
> Sqlite, you dont' receive a trusty data provider.  Good ones exist,
> but all of this extra work boils down to time cost.  As well, what if
> you want to move the database to another machien to distribute
> workload.  
> 
> Well, our bug tracking system Swatter we did use Sqlite but we had to
> write the thead syncronization layer.  In fact, it is a .nET
> application that runs across a web service or a sockets layer, to a
> sqlite database eventually.  Our sql server version does not require
> any special coding like sqlite.   So after 250k lines of code in our
> bug tracking system, we have a picture painted.  The sqlite version
> is what we use, not the sql server but we deal with the corporate
> requirments as well like this fellow is up against.
> 
> Does SQLite have a distributed API now.  This means a client that
> talks efficient binary across a network to a server that eventually
> syncronizes into database work?  Did I miss something.  I thought
> this thing was only a binary that you have to do everything else on
> top of.

I believe you understand correctly.

With sqlite there is no central server, the applications that use
the database all open a single file containing the data. It's suitable
for web applications (I use it for that) if all the applications
can access the same file. Usually that means they're all on a single
server, or on group of servers that can connect to a single network
shared file.

In my case the web server houses the database as well as all
the code that uses it. It's light, fast, self contained, and fairly
difficult for hackers to break into.

It won't work if you want to let users connect to it using
Excel and run reports against the database, though I understand
that can be done with an odbc driver. I don't know how well that works.
Connectivity can be an issue if you need it, but in my case the
lack of exposed (I.E. Hackable) connections is a bonus.

Scaling can be done by buying bigger iron.



=

-

"Lord Tarlington gazed upon the crazed Egyptian hieroglyphics on the walls of 
the ancient tomb of the petrified pharaoh, he vowed there would be no curse on 
him like on that other Lord, unless you count his marriage to Lady Tarlington 
who, when the lost treasure was found, will be dumped faster than that basket 
in the bulrushes."
  Melissa Rhodes
-

The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's 
Call
http://www.lulu.com/content/77264



__ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

RE(1): [sqlite] SQLite Advocacy

[aedwards]

I greatly appreciate your answer Fred.  


- Original message -
From: "Fred Williams" <[EMAIL PROTECTED]>
Date: 1/31/2005 1:37:50 PM
Subject: RE: [sqlite] SQLite Advocacy

> 
> 
> -Original Message-
> From: Mario Ruggier [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 12:24 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] SQLite Advocacy
> 
> 
> On Jan 31, 2005, at 5:48 PM, Paul Malcher wrote:
> > Fred Williams wrote:
> >
> >> Politically, if you  are in the organization that was "acquired", you
> >> best bite the bullet and learn to dance the Big Gates' version of "I
> >> Shall Overcome."  I don't think there is a WinCE version of SQL
> >> Server,
> >> (yet) so that might be your only real chance.
> >>
> >> My experience with organizations that embrace all things Gates' is,
> >> pretty much any technical advantageous products which lie outside the
> >> Mickeysoft umbrella are ignored and usually completely banned as,
> "not
> >> conforming to organization policy."
> >>
> >> Fred
> >>
> > Hi,
> > I so agree with Fred he's nailed it dead on.
> 
> Irrespective of this non-negotiable logic, what about the comparative
> top limits for handling large volumes of data ?
> 
> mario
> 
> All the logic and data in the world won't change a biased management
> mind set.  Believe me.  Management does not understand technology and
> does not want to.  They understand people.  That is why they are
> managers.  I spent over thirty years, most as a consultant, many, many
> times swimming upstream.  If the politics are entrenched, technically
> you are kicking a dead dog.
> 
> My first experience was learning the world's safest MIS CYA statement,
> back in the very early sixties:  "I don't know what went wrong. We are
> using IBM."  Look very confused when delivering this line.
> 
> I think you could very easily replace "IBM" with "Microsoft" in this
> "enlightened" day and age.  Been there.  Done that.  Lost the battle
> every time.
> 
> Fred
> 
> 
> 
> 
> 

RE: [sqlite] SQLite Advocacy

[Fred Williams]

-Original Message-
From: Mario Ruggier [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 12:24 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQLite Advocacy


On Jan 31, 2005, at 5:48 PM, Paul Malcher wrote:
> Fred Williams wrote:
>
>> Politically, if you  are in the organization that was "acquired", you
>> best bite the bullet and learn to dance the Big Gates' version of "I
>> Shall Overcome."  I don't think there is a WinCE version of SQL
>> Server,
>> (yet) so that might be your only real chance.
>>
>> My experience with organizations that embrace all things Gates' is,
>> pretty much any technical advantageous products which lie outside the
>> Mickeysoft umbrella are ignored and usually completely banned as,
"not
>> conforming to organization policy."
>>
>> Fred
>>
> Hi,
> I so agree with Fred he's nailed it dead on.

Irrespective of this non-negotiable logic, what about the comparative
top limits for handling large volumes of data ?

mario

All the logic and data in the world won't change a biased management
mind set.  Believe me.  Management does not understand technology and
does not want to.  They understand people.  That is why they are
managers.  I spent over thirty years, most as a consultant, many, many
times swimming upstream.  If the politics are entrenched, technically
you are kicking a dead dog.

My first experience was learning the world's safest MIS CYA statement,
back in the very early sixties:  "I don't know what went wrong. We are
using IBM."  Look very confused when delivering this line.

I think you could very easily replace "IBM" with "Microsoft" in this
"enlightened" day and age.  Been there.  Done that.  Lost the battle
every time.

Fred

RE(1): RE(1): [sqlite] SQLite Advocacy

[aedwards]

Let me clarify then.  100% of our customer want web based.  With .NET and SQL 
server we can throw in our data adapter and be off to the races.  We don't have 
to worry about future scalability.  With Sqlite, you dont' receive a trusty 
data provider.  Good ones exist, but all of this extra work boils down to time 
cost.  As well, what if you want to move the database to another machien to 
distribute workload.  

Well, our bug tracking system Swatter we did use Sqlite but we had to write the 
thead syncronization layer.  In fact, it is a .nET application that runs across 
a web service or a sockets layer, to a sqlite database eventually.  Our sql 
server version does not require any special coding like sqlite.   So after 250k 
lines of code in our bug tracking system, we have a picture painted.  The 
sqlite version is what we use, not the sql server but we deal with the 
corporate requirments as well like this fellow is up against.

Does SQLite have a distributed API now.  This means a client that talks 
efficient binary across a network to a server that eventually syncronizes into 
database work?  Did I miss something.  I thought this thing was only a binary 
that you have to do everything else on top of.

Allan


- Original message -
From: "cirisme" <[EMAIL PROTECTED]>
Date: 1/31/2005 12:24:23 PM
Subject: Re: RE(1): [sqlite] SQLite Advocacy

> >>Their are still sa couple extra features missing from this db that
> would make it a true contender for business software.<<
> 
> Too general of a comment.  If the business software requires a
> distributed database, SQLite fits the bill.  If the business software
> requires a central database, SQL Server is probably more suited.
> 
> It just depends on the exact nature of the requirements.
> 

Re: [sqlite] SQLite Advocacy

[Mario Ruggier]

On Jan 31, 2005, at 5:48 PM, Paul Malcher wrote:
Fred Williams wrote:
Politically, if you  are in the organization that was "acquired", you
best bite the bullet and learn to dance the Big Gates' version of "I
Shall Overcome."  I don't think there is a WinCE version of SQL 
Server,
(yet) so that might be your only real chance.

My experience with organizations that embrace all things Gates' is,
pretty much any technical advantageous products which lie outside the
Mickeysoft umbrella are ignored and usually completely banned as, "not
conforming to organization policy."
Fred
Hi,
I so agree with Fred he's nailed it dead on.
Irrespective of this non-negotiable logic, what about the comparative 
top limits for handling large volumes of data ?

mario

RE: [sqlite] SQLite Advocacy

[Downey, Shawn]

Please understand that my intent is not to mislead.  I will not claim
anything which is untrue in this comparison.  I fully intend to make
corrections based on input I am getting.

Shawn M. Downey
MPR Associates
632 Plank Road, Suite 110
Clifton Park, NY 12065
518-371-3983 x3 (work)
860-508-5015 (cell)


-Original Message-
From: Tim Anderson [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 31, 2005 12:44 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy

> -Original Message-
> From: Downey, Shawn [mailto:[EMAIL PROTECTED] 
> Sent: 31 January 2005 17:16
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLite Advocacy
> 
> Thanks everyone for there input.  See below for the arguments 
> I've compiled so far.  Please let me know if I am incorrect 
> on any of these items.  Do we have any speed comparisons 
> between SQLite and SQL Server 7?

I have an application that can use either SQLite or local SQL Server.
I've not benchmarked it but performance is similar. That's a good result
for SQL Server since it is far more feature-rich.

SQLite is a fantastic piece of work and some of your points are valid
(eg. simplicity of installation). But there is no need to bash at SQL
Server which is an excellent and very different product. I think you
would do better to promote SQLite on its merits rather than presenting
this misleading comparison.

Tim

Re: RE(1): [sqlite] SQLite Advocacy

[Brass Tilde]

> >> 11. By using SQLite you eliminate a possible source of virus
> >> infection.  SQL server has been targeted in at least one major virus
> >> outbreak.
> >
> > Completely and totally false.  Applications that use SQLite can be
> > corrupted and infected by viruses just like any other executable
> > file on the file system.
>
>
> If you install MS SQL server you run a network based service that
> is vulnerable to attack. If you run Sqlite you don't run any
> service and thus are invulnerable (to network service based
> infections).

Not relevant.  No reference to "network service based infections" was made
in the original post.

> Yes, any executable can be infected, but that's a meaningless statement
> since you can't have any database without executable code.

Then saying that SQLite won't be a source of virus infections is also
meaningless, since "you can't have any [SQLite] database without executable
code," which executable code can be infected.

Re: [sqlite] SQLite Advocacy

[cirisme]

I'd agree with Tim, focus on the merits and disadvantages of each
without resorting to bashing.

Some suggestions:

Eliminate:


>>2.  An SQLite database is exactly one file.  SQL Server 7 has many
files for each table in the database.<<

Or merge it with #1.  This isn't an advantage unless the database
needs to be widely distributed.

>>3.  SQLite is much faster than SQL Server 7.<<

While this may be true, you really should have data to support it, and
not just general data that you find out there, but data specifically
relating to your project.  If your product will usually handle 3
million rows of data, perform some queries on this test data and see
how well it will perform.  Then you can give specific data like:
SQLite performed an average of 32% better on sample data than did SQL
Server 7.

Change 4 to:


>>SQLite is easy to administrate in a distributed environment.  To
distribute a database, all that is needed is to copy one file.  SQL
Server 7 is difficult to administer in a distributed environment.  SQL
Server 7 is best used as centralized database server, whereas SQLite
is best used in a distributed environment.  Further, licensing costs
can be prohibitive for SQL Server 7 in a distributed environment,
whereas it costs nothing to distribute SQLite.<<

Change 5 to:

>>SQL Server 7 is obsolete and the database is not upward
compatible.  When Microsoft discontinues support for SQL Server 7, it
may no longer work on the latest Windows platform.  SQL Server 7 can no
longer be purchased directly from Microsoft.<<

Merge 8, 10 into one.  It would be more effective to merge 9 with 3
and run specific stats to verify this is true and get hard numbers.

>> SQL Server 7 has higher system requirements than SQLite, so SQLite
will work better in a distributed environment where the specs can't be
so closely controlled.  SQLite will also run on a wide range of
operating systems and can be ported to almost any operating system
without additional cost.  SQL Server 7 runs only on Windows.<<

Note in 11 that SQLite isn't an RDBMS, and doesn't accept network
connections, so no extra configuration on firewalls is necessary, and
is safer than SQL Server for the possibility of a network based
attack.

Drop the

>>Microsoft has been known to sit on patches for years
because it's inconvenient or costly to roll them out.<<

in 12 and note that bug fixes in SQL Server 7 may not come since SS7
is no longer actively released.  SQLite is actively developed, and bug
fixes can be made by the user were this to change making it relatively
future-proof.

>>."Security
through Obscurity" is regarded a fallacy in the cryptographic community
at large.<<

Back this up...there's lot's out there and providing sources will be
far more effective than merely saying it.

You're on the right track, providing some solid information will
really sell this for you :)

On Mon, 31 Jan 2005 12:16:27 -0500, Downey, Shawn <[EMAIL PROTECTED]> wrote:
> Thanks everyone for there input.  See below for the arguments I've
> compiled so far.  Please let me know if I am incorrect on any of these
> items.  Do we have any speed comparisons between SQLite and SQL Server
> 7?
> 
> I do understand we are talking Apples and Oranges here.  Never the less,
> I need to do the comparison!  If not, I might as well go get an MS
> certification (not that there's anything wrong with that... :-).
> 
> SQLite Advocacy
> 
> 1.  SQLite has "Zero Installation".  This means that all that is
> needed to run SQLite is to copy the database on the machine along with
> the program which accesses it.  There is no need to adjust the registry
> for SQLite.  Installing SQL Server 7 on the other hand is complex and
> sometimes problematic.  Even moving SQL Server 7 to a different
> directory on the same machine is difficult.
> 
> 2.  An SQLite database is exactly one file.  SQL Server 7 has many
> files for each table in the database.
> 
> 3.  SQLite is much faster than SQL Server 7.
> 
> 4.  SQLite is easy to administrate.  All that is needed is to copy
> one database file.  SQL Server 7 is very difficult for the novice end
> user to backup or to deploy database updates in the field.  SQL Server 7
> is best used for a centralized database (rather than a distributed
> database) since it is so hard to deploy data updates.
> 
> 5.  SQLite has an active community with good people which help each
> other solve rather complex programming problems.
> 
> 6.  SQL Server 7 is obsolete and the database is not upward
> compatible.  When Microsoft discontinues support for SQL Server 7, it
> may no longer work on the latest Windows platform.  SQL Server can no
> longer be purchased directly from Microsoft.
> 
> 7.  SQL server 7 is very expensive.  Development tools and
> deployment license costs for SQL Server 7 are very high.  SQLite is free
> and can be developed using free compilers or Microsoft compilers as
> desired.
> 
> 8.  SQL Server 7 requires powerful 

Re: [sqlite] SQLite Advocacy

[Scott Chapman]

On Monday 31 January 2005 7:58 am, Downey, Shawn wrote:

> "If anyone can see the source code, then won't we be venerable to
> hackers?"

Here is a very useful paragraph that should be given to anyone who thinks in 
the above terms:

"A common question in the minds of some CEOs and CIOs is, 'If it is open, 
how can it be secure?' " The very question displays a fundamental 
misunderstanding of security. The correct notion was known and set down 
by Auguste Kerckhoffs in the 19th century. David Kahn's classic book, 
_The Codebreakers_, puts it succinctly for codes and ciphers: "security 
must reside solely in the keys." You must assume that the enemy knows the 
algorithm--"security by obscurity" is a delusion and a sham. Indeed, 
proprietary software is a far more likely haven for back doors and 
Trojans, because it is kept secret. 

Regarding the issue of SQL Server vs. SQLite:
If the choice were between SQL Server and SQLite, and the need came up that 
SQLite could not meet, I'd pitch for PostgreSQL (_not_ MySQL).  PostgreSQL 
version 8.0 has been released and runs natively on Windows.

Cordially,
Scott

Re: RE(1): [sqlite] SQLite Advocacy

[Jay]

> > 10. SQLite runs on almost ever operating systems.  SQL Server runs
> > on MS Windows exclusively.
> > 
> yep, but again who cares, 99% of the world is on windows

About half of the web servers on the internet
are not windows based:
http://news.netcraft.com/archives/web_server_survey.html



> > 11. By using SQLite you eliminate a possible source of virus
> > infection.  SQL server has been targeted in at least one major
> virus
> > outbreak.
> not always true, microsoft had a bug in their network strnsport
> distributed layer "slammer" but they patched it, SQlite does not even
> have a distributed network layer, comparison is not valid here.

and

>> 11. By using SQLite you eliminate a possible source of virus
>> infection.  SQL server has been targeted in at least one major virus
>> outbreak.
>
>Completely and totally false.  Applications that use SQLite can be
> corrupted and infected by viruses just like any other executable
> file on the file system.


If you install MS SQL server you run a network based service that
is vulnerable to attack. If you run Sqlite you don't run any
service and thus are invulnerable (to network service based
infections).

Yes, any executable can be infected, but that's a meaningless statement
since you can't have any database without executable code.


> > 12. Changes can be made to the source code for SQLite by the end
> > user.  In this way, any bugs in SQLite can be fixed quickly.  If
> > something was wrong with SQL Server 7, Microsoft is unlikely to
> address
> > it as quickly.  Microsoft has been known to sit on patches for
> years
> > because it's inconvenient or costly to roll them out.
> yeah, but Microsoft also backs their products with millions of
> testing hours.  I have to admit I used to work in Redmon on VC++.  I
> saw all of it first hand.

I work for a large organization that services government contracts.
I know first hand about how the right thing isn't always done for
"business" reasons.

If MS won't roll out patches because it's costly,
embarrassing, or inconvenient then all the testing in the
world is worthless.

MS's design decisions are made for business reasons.
They benefit MS's bottom line, not their customers.



> > 
> > 13. Open source and Free Software such as SQLite has proven to be
> > more robust and more secure than proprietary software due to open,
> > intense, and ongoing peer reviews by the user community.  "Security
> > through Obscurity" is regarded a fallacy in the cryptographic
> community
> > at large.
> > 
> Not true at all.  In fact, from experience, the Linux OS is much more
> full of holes than Windows.  It appears most hate Microsoft so thier
> OS gets the most virus and hackers.  All I can say is we
> independently did a test with Linux and Windows we isntalled a
> default OS and put it on the net without a firewall.  Windows was
> never hacked, but Linux was hacked in a day and they took root access
> to the point where we could not get back in.  

I don't know who did your test, but their results do not match others
results at all. Other independent testers have shown the average
time to get infected for a windows box is 20 minutes:

http://isc.sans.org/survivalhistory.php






__ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

RE(1): RE(1): [sqlite] SQLite Advocacy

[aedwards]

Yeah, good points.  So  if their are holes!  You are at fault, not the 
database.  You might as well go with SQL server for CYA! : - )

Allan


- Original message -
From: "Roger Binns" <[EMAIL PROTECTED]>
Date: 1/31/2005 11:42:46 AM
Subject: Re: RE(1):  [sqlite] SQLite Advocacy

> > Not true at all.  In fact, from experience, the Linux OS is 
> > much more full of holes than Windows.  It appears most hate 
> > Microsoft so thier OS gets the most virus and hackers.  All 
> > I can say is we independently did a test with Linux and Windows 
> > we isntalled a default OS and put it on the net without a 
> > firewall.  Windows was never hacked, but Linux was hacked in 
> > a day and they took root access to the point where we could 
> > not get back in.  
> 
> That is one of the most insignificant tests.  Typically the
> "holes" are going to depend on what applications and services
> you have installed on the operating system.  For Linux, the
> default installs have almost no exposed services.  The same is
> mostly true of using XP SP2.  And there are many many
> counter examples to your data point anyway.  The logic is the
> same as saying that some airline hasn't had a crash yet
> this year therefore it must be safer than the other ones.
> 
> But it does raise a good point for SQLite.  SQLite is not
> exposed as a service in *any* way.  It is just a library.
> You cannot hack into it over the network.  You can hack into 
> an application using SQLite, but you can do the same for
> an application using SQL Server, or anything else.  SQLite
> buys you one less point of exposure.  (The same is true of
> any other embedded database.)
> 
> What SQLite and other open source/free projects give you is
> freedom of choice.  You can get support from whomever you want.
> You can get maintenance from whomever you want.  There is
> no lockin.  So if you want to pay lots of money for 30 minute
> response times, you can.  If you want to pay almost no money
> for one month response times, you can.  If you don't like how
> long whomever you choose to pay, you can drop them and pick
> someone else.  With Microsoft, you get only what they offer
> with no choice.  You get to go where they want to go today.
> And try to get a customisation out of Microsoft ...
> 
> How about proper research on how long it takes to get systems
> hacked:
> 
> http://www.honeynet.org/papers/trends/life-linux.pdf
> http://www.schneier.com/blog/archives/2005/01/linux_security_1.html
> 
> And some counter-FUD:
> 
> http://www.theregister.co.uk/2004/10/22/linux_v_windows_security/
> http://www.wired.com/news/linux/0,1411,66022,00.html?tw=wn_tophead_1
> http://www.newsfactor.com/perl/story/19649.html
> http://www.securitypipeline.com/showArticle.jhtml?articleID=26805728
> http://www.fcw.com/fcw/articles/2004/0503/feat-linux3-05-03-04.asp
> 
> Roger
> 

RE(1): RE(1): [sqlite] SQLite Advocacy

[aedwards]

Well hell man, sorry to go off the sqlite topic here but geez, I have to know 
to go and patch the crap out of my system to make it secure.  What a cost 
advantage windows has in our data center!  Money walks.  

My point here is both open source, closed source, windows, and linux all have 
issues, but my experience has been truly more positive wiht windows.  I like 
Linux a lot to man.

Allan


- Original message -
From: [EMAIL PROTECTED]
Date: 1/31/2005 11:42:32 AM
Subject: Re: RE(1):  [sqlite] SQLite Advocacy

> On Jan 31, 2005, at 9:31 AM, [EMAIL PROTECTED] wrote:
> > Not true at all.  In fact, from experience, the Linux OS is much more 
> > full of holes than Windows.  It appears most hate Microsoft so thier 
> > OS gets the most virus and hackers.  All I can say is we independently 
> > did a test with Linux and Windows we isntalled a default OS and put it 
> > on the net without a firewall.  Windows was never hacked, but Linux 
> > was hacked in a day and they took root access to the point where we 
> > could not get back in.
> 
> That is incorrect and counter to recent tests that show that an 
> unpatched Windows system will survive less than an hour whereas an 
> unpatched Linux system will generally survive for 3 months.   Once 
> "hacked", the level of ownership is irrelevant as any standard rootkit 
> will "own" the box to the level you describe with a single installation 
> command.
> 
> It isn't a case of "hate".   The sheer volume of unpatched Windows 
> systems running on wide open broadband connections makes for an 
> extremely attractive-- lucrative, even-- set of systems to take over 
> for the purposes of spamming and distributed denial of service attacks.
> 
> See:  http://www.schneier.com/blog/archives/2005/01/linux_security.html
> 
> b.bum
> 
> 

Re: RE(1): [sqlite] SQLite Advocacy

[Roger Binns]

Not true at all.  In fact, from experience, the Linux OS is 
much more full of holes than Windows.  It appears most hate 
Microsoft so thier OS gets the most virus and hackers.  All 
I can say is we independently did a test with Linux and Windows 
we isntalled a default OS and put it on the net without a 
firewall.  Windows was never hacked, but Linux was hacked in 
a day and they took root access to the point where we could 
not get back in.  
That is one of the most insignificant tests.  Typically the
"holes" are going to depend on what applications and services
you have installed on the operating system.  For Linux, the
default installs have almost no exposed services.  The same is
mostly true of using XP SP2.  And there are many many
counter examples to your data point anyway.  The logic is the
same as saying that some airline hasn't had a crash yet
this year therefore it must be safer than the other ones.
But it does raise a good point for SQLite.  SQLite is not
exposed as a service in *any* way.  It is just a library.
You cannot hack into it over the network.  You can hack into 
an application using SQLite, but you can do the same for
an application using SQL Server, or anything else.  SQLite
buys you one less point of exposure.  (The same is true of
any other embedded database.)

What SQLite and other open source/free projects give you is
freedom of choice.  You can get support from whomever you want.
You can get maintenance from whomever you want.  There is
no lockin.  So if you want to pay lots of money for 30 minute
response times, you can.  If you want to pay almost no money
for one month response times, you can.  If you don't like how
long whomever you choose to pay, you can drop them and pick
someone else.  With Microsoft, you get only what they offer
with no choice.  You get to go where they want to go today.
And try to get a customisation out of Microsoft ...
How about proper research on how long it takes to get systems
hacked:
http://www.honeynet.org/papers/trends/life-linux.pdf
http://www.schneier.com/blog/archives/2005/01/linux_security_1.html
And some counter-FUD:
http://www.theregister.co.uk/2004/10/22/linux_v_windows_security/
http://www.wired.com/news/linux/0,1411,66022,00.html?tw=wn_tophead_1
http://www.newsfactor.com/perl/story/19649.html
http://www.securitypipeline.com/showArticle.jhtml?articleID=26805728
http://www.fcw.com/fcw/articles/2004/0503/feat-linux3-05-03-04.asp
Roger

Re: RE(1): [sqlite] SQLite Advocacy

[bbum]

On Jan 31, 2005, at 9:31 AM, [EMAIL PROTECTED] wrote:
Not true at all.  In fact, from experience, the Linux OS is much more 
full of holes than Windows.  It appears most hate Microsoft so thier 
OS gets the most virus and hackers.  All I can say is we independently 
did a test with Linux and Windows we isntalled a default OS and put it 
on the net without a firewall.  Windows was never hacked, but Linux 
was hacked in a day and they took root access to the point where we 
could not get back in.
That is incorrect and counter to recent tests that show that an 
unpatched Windows system will survive less than an hour whereas an 
unpatched Linux system will generally survive for 3 months.   Once 
"hacked", the level of ownership is irrelevant as any standard rootkit 
will "own" the box to the level you describe with a single installation 
command.

It isn't a case of "hate".   The sheer volume of unpatched Windows 
systems running on wide open broadband connections makes for an 
extremely attractive-- lucrative, even-- set of systems to take over 
for the purposes of spamming and distributed denial of service attacks.

See:  http://www.schneier.com/blog/archives/2005/01/linux_security.html
b.bum

RE: [sqlite] SQLite Advocacy

[Dan Keeley]

3.	SQLite is much faster than SQL Server 7.
I'm sorry but you simply cannot state that.
Sure, it's faster in some circumstances, but there are situations where SQL 
Server 7 would definately be faster.  And if you're in that situation, then 
you probably want advanced features such as replication and much more as 
well.

I'm not a supporter of SQL Server, it just bugs me when people compare 
sqlite to something like that, oracle, mysql etc, when they're two 
completely different solutions to different problems ( Albeit with _some_ 
overlap )

Rgds,
Dan

RE: [sqlite] SQLite Advocacy

[Tim Anderson]

> -Original Message-
> From: Downey, Shawn [mailto:[EMAIL PROTECTED] 
> Sent: 31 January 2005 17:16
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLite Advocacy
> 
> Thanks everyone for there input.  See below for the arguments 
> I've compiled so far.  Please let me know if I am incorrect 
> on any of these items.  Do we have any speed comparisons 
> between SQLite and SQL Server 7?

I have an application that can use either SQLite or local SQL Server.
I've not benchmarked it but performance is similar. That's a good result
for SQL Server since it is far more feature-rich.

SQLite is a fantastic piece of work and some of your points are valid
(eg. simplicity of installation). But there is no need to bash at SQL
Server which is an excellent and very different product. I think you
would do better to promote SQLite on its merits rather than presenting
this misleading comparison.

Tim

RE(1): [sqlite] SQLite Advocacy

[aedwards]

my comments below.


- Original message -
From: "Downey, Shawn" <[EMAIL PROTECTED]>
Date: 1/31/2005 11:11:27 AM
Subject: RE: [sqlite] SQLite Advocacy

> Thanks everyone for there input.  See below for the arguments I've
> compiled so far.  Please let me know if I am incorrect on any of these
> items.  Do we have any speed comparisons between SQLite and SQL Server
> 7?

no point, they are both fast and index for queries the same, n time searches.
> 
> I do understand we are talking Apples and Oranges here.  Never the less,
> I need to do the comparison!  If not, I might as well go get an MS
> certification (not that there's anything wrong with that... :-).
> 
> SQLite Advocacy
> 
> 1.SQLite has "Zero Installation".  This means that all that is
> needed to run SQLite is to copy the database on the machine along with
> the program which accesses it.  There is no need to adjust the registry
> for SQLite.  Installing SQL Server 7 on the other hand is complex and
> sometimes problematic.  Even moving SQL Server 7 to a different
> directory on the same machine is difficult.

SQL server 7 MSDE is also this way.  They have 3 versions of SQL Server
> 
> 2.An SQLite database is exactly one file.  SQL Server 7 has many
> files for each table in the database.
> 
> 3.SQLite is much faster than SQL Server 7.

not on inserts
> 
> 4.SQLite is easy to administrate.  All that is needed is to copy
> one database file.  SQL Server 7 is very difficult for the novice end
> user to backup or to deploy database updates in the field.  SQL Server 7
> is best used for a centralized database (rather than a distributed
> database) since it is so hard to deploy data updates.
> 
true
> 5.SQLite has an active community with good people which help each
> other solve rather complex programming problems.
> 
YEs, everyone buy myself! : - )
> 6.SQL Server 7 is obsolete and the database is not upward
> compatible.  When Microsoft discontinues support for SQL Server 7, it
> may no longer work on the latest Windows platform.  SQL Server can no
> longer be purchased directly from Microsoft.
true, but you can dump the databsae and convert it easily to 2000 or later 
Yukon, tools exist for this
> 
> 7.SQL server 7 is very expensive.  Development tools and
> deployment license costs for SQL Server 7 are very high.  SQLite is free
> and can be developed using free compilers or Microsoft compilers as
> desired.
SQL server 7 MSDE is free
> 
> 8.SQL Server 7 requires powerful hardware to run.  SQLite runs on
> cheaper hardware.
this is true, lots of memory 
> 
> 9.SQLite has a small memory footprint and SQL Server 7 is a very
> very large memory footprint.
> 
big time, Sqlite is a stud here
> 10.   SQLite runs on almost ever operating systems.  SQL Server runs
> on MS Windows exclusively.
> 
yep, but again who cares, 99% of the world is on windows
> 11.   By using SQLite you eliminate a possible source of virus
> infection.  SQL server has been targeted in at least one major virus
> outbreak.
not always true, microsoft had a bug in their network strnsport distributed 
layer "slammer" but they patched it, SQlite does not even have a distributed 
network layer, comparison is not valid here.
> 
> 12.   Changes can be made to the source code for SQLite by the end
> user.  In this way, any bugs in SQLite can be fixed quickly.  If
> something was wrong with SQL Server 7, Microsoft is unlikely to address
> it as quickly.  Microsoft has been known to sit on patches for years
> because it's inconvenient or costly to roll them out.
yeah, but Microsoft also backs their products with millions of testing hours.  
I have to admit I used to work in Redmon on VC++.  I saw all of it first hand.
> 
> 13.   Open source and Free Software such as SQLite has proven to be
> more robust and more secure than proprietary software due to open,
> intense, and ongoing peer reviews by the user community.  "Security
> through Obscurity" is regarded a fallacy in the cryptographic community
> at large.
> 
Not true at all.  In fact, from experience, the Linux OS is much more full of 
holes than Windows.  It appears most hate Microsoft so thier OS gets the most 
virus and hackers.  All I can say is we independently did a test with Linux and 
Windows we isntalled a default OS and put it on the net without a firewall.  
Windows was never hacked, but Linux was hacked in a day and they took root 
access to the point where we could not get back in.  
> 
> 
> Shawn M. Downey
> MPR Associates
> 632 Plank Road, Suite 110
> Clifton Park, NY 12065
> 518-371-3983 x3 (work)
> 860-508-5015 (cell)
> 
> 

RE: [sqlite] SQLite Advocacy

[Downey, Shawn]

Thanks everyone for there input.  See below for the arguments I've
compiled so far.  Please let me know if I am incorrect on any of these
items.  Do we have any speed comparisons between SQLite and SQL Server
7?

I do understand we are talking Apples and Oranges here.  Never the less,
I need to do the comparison!  If not, I might as well go get an MS
certification (not that there's anything wrong with that... :-).

SQLite Advocacy

1.  SQLite has "Zero Installation".  This means that all that is
needed to run SQLite is to copy the database on the machine along with
the program which accesses it.  There is no need to adjust the registry
for SQLite.  Installing SQL Server 7 on the other hand is complex and
sometimes problematic.  Even moving SQL Server 7 to a different
directory on the same machine is difficult.

2.  An SQLite database is exactly one file.  SQL Server 7 has many
files for each table in the database.

3.  SQLite is much faster than SQL Server 7.

4.  SQLite is easy to administrate.  All that is needed is to copy
one database file.  SQL Server 7 is very difficult for the novice end
user to backup or to deploy database updates in the field.  SQL Server 7
is best used for a centralized database (rather than a distributed
database) since it is so hard to deploy data updates.

5.  SQLite has an active community with good people which help each
other solve rather complex programming problems.

6.  SQL Server 7 is obsolete and the database is not upward
compatible.  When Microsoft discontinues support for SQL Server 7, it
may no longer work on the latest Windows platform.  SQL Server can no
longer be purchased directly from Microsoft.

7.  SQL server 7 is very expensive.  Development tools and
deployment license costs for SQL Server 7 are very high.  SQLite is free
and can be developed using free compilers or Microsoft compilers as
desired.

8.  SQL Server 7 requires powerful hardware to run.  SQLite runs on
cheaper hardware.

9.  SQLite has a small memory footprint and SQL Server 7 is a very
very large memory footprint.

10. SQLite runs on almost ever operating systems.  SQL Server runs
on MS Windows exclusively.

11. By using SQLite you eliminate a possible source of virus
infection.  SQL server has been targeted in at least one major virus
outbreak.

12. Changes can be made to the source code for SQLite by the end
user.  In this way, any bugs in SQLite can be fixed quickly.  If
something was wrong with SQL Server 7, Microsoft is unlikely to address
it as quickly.  Microsoft has been known to sit on patches for years
because it's inconvenient or costly to roll them out.

13. Open source and Free Software such as SQLite has proven to be
more robust and more secure than proprietary software due to open,
intense, and ongoing peer reviews by the user community.  "Security
through Obscurity" is regarded a fallacy in the cryptographic community
at large.



Shawn M. Downey
MPR Associates
632 Plank Road, Suite 110
Clifton Park, NY 12065
518-371-3983 x3 (work)
860-508-5015 (cell)

RE: [sqlite] SQLite Advocacy

[Rani Pinchuk]

Maybe this link could help:
http://www.opensource.org/advocacy/faq.php

Rani

On Mon, 2005-01-31 at 16:58, Downey, Shawn wrote:
...
> I am sorry I can not disclose more about the products in question.  What
> I am looking for are some talking points which can convince my own
> management to push back against converting all our good work into SQL
> Server 7.  I am trying to overcome the attitude of:
> 
> "If SQLite is as good as you say, then why is it free?"
> 
> and 
> 
> "If anyone can see the source code, then won't we be venerable to
> hackers?"
> 
> etc.

Re: [sqlite] SQLite Advocacy

[Paul Malcher]

Fred Williams wrote:
Politically, if you  are in the organization that was "acquired", you
best bite the bullet and learn to dance the Big Gates' version of "I
Shall Overcome."  I don't think there is a WinCE version of SQL Server,
(yet) so that might be your only real chance.
My experience with organizations that embrace all things Gates' is,
pretty much any technical advantageous products which lie outside the
Mickeysoft umbrella are ignored and usually completely banned as, "not
conforming to organization policy."
Fred
 

Hi,
I so agree with Fred he's nailed it dead on.

Re: [sqlite] SQLite Advocacy

[Paul Malcher]

Downey, Shawn wrote:
I am trying to overcome the attitude of:
"If SQLite is as good as you say, then why is it free?"
and 

"If anyone can see the source code, then won't we be venerable to
hackers?"
Hi, I hope I may be of assistance in this area. I own my own company and 
we use exclusively open source stuff for ourselves and clients. We went 
thought those questions too. What you must have them understand is that 
just because its open source and free, doesn't mean its of low quality. 
You see open source projects, ones like SQLite have many people working 
on them and looking the source over. As a result of this you get a high 
quality yet, free project. The more people that look at the source and 
stuff, the more of a bug free/exploit free product you end up with. The 
bugs that do exist also tend to be discovered quickly and fixed rather 
quickly.  Of course  there is always encryption if you're that  
worried.  Also if SQLite worked for you guys before then why change?  As 
some else mentioned, MS SQL is a full rdbms and SQLite is embedded. On a 
more opinion side of things I condemn anything made by MS, by default 
anyhow. Oh, as far as vulnerability to hackers goes, that depends on how 
well the project is run, if they fix bugs quickly and such then you need 
not be to worried. Also depends on how its built, do they build it in a 
manner that doesn't present vulnerabilities. I would recommend 
encryption though if you're really worried.

RE(1): [sqlite] SQLite Advocacy

[aedwards]

Their is a WinCe version of SQL server and it has a huge memory cross section.  
It appeared buggy as well.  I did my best sometime ago to convince a group to 
allow use of this database in our embedded product but I received the same free 
mantra garbage.  Even though i could run test after test proving this great 
database, the management did not care.

Allan


- Original message -
From: "Fred Williams" <[EMAIL PROTECTED]>
Date: 1/31/2005 10:18:47 AM
Subject: RE: [sqlite] SQLite Advocacy

> Politically, if you  are in the organization that was "acquired", you
> best bite the bullet and learn to dance the Big Gates' version of "I
> Shall Overcome."  I don't think there is a WinCE version of SQL Server,
> (yet) so that might be your only real chance.
> 
> My experience with organizations that embrace all things Gates' is,
> pretty much any technical advantageous products which lie outside the
> Mickeysoft umbrella are ignored and usually completely banned as, "not
> conforming to organization policy."
> 
> Fred
> 
> -Original Message-
> From: Downey, Shawn [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 9:58 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLite Advocacy
> 
> 
> Thank you for your replies (both yours and Jalil's).  I understand that
> SQLite is not universally applicable.  Let me give you some background
> to better explain my request.
> 
> We currently have a product (which we inherited the responsibility from
> another company).  This product was originally written to use SQLite.
> We have expanded the this product (continuing to use SQLite).
> 
> Now our organization is partnered with another company which has a
> related product which uses SQL Server 7.  This new partner is pushing my
> management to convert our product over to use SQL Server 7 instead of
> SQLite.  The intent is that we can use a single database format at some
> point in the future.
> .
> 
> 
> -Original Message-
> From: Fred Williams [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 10:32 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] SQLite Advocacy
> 
> I think if your organization is truly looking at SQLite vs SQL Server,
> you need to reconsider your project specifications.  You are basically
> comparing a Corvette to a  Greyhound Bus.
> .
> 
> 
> 

RE(1): [sqlite] SQLite Advocacy

[aedwards]

Does Sqlite support multiple data files yet along with a thread syncronized 
engine?  As well, does it have a distributed data access layer?  Their are 
still sa couple extra features missing from this db that would make it a true 
contender for business software.  I am not knocking it all. It is truly 
impressive stuff.  We even backed our bug tracking software with it. 

Allan


- Original message -
From: "Jalil Vaidya" <[EMAIL PROTECTED]>
Date: 1/31/2005 10:17:37 AM
Subject: RE: [sqlite] SQLite Advocacy

> I hate to say this again but its apples to oranges
> comparison. Anyway, you can try some points like cost
> effectiveness, TCO, cross-platform needs, maintenance
> requirements, disk and memory footprint, speed,
> hardware requirements etc.
> 
> > "If SQLite is as good as you say, then why is it
> > free?"
> 
> This kind of mindset is very difficult to overcome.
> Not everything paid is good and not everything free is
> bad. If your company is hell bent on paid solution
> then I am sure Dr. Hipp won't mind taking donations
> and can also provide paid support ;-)
> 
> > "If anyone can see the source code, then won't we be
> > venerable to hackers?"
> 
> Security is more than just being able to see the code.
> Closed source products have been proven to be equally
> vulnerable. Security of any product also depends upon
> the practices of the product's users. For instance, if
> someone has their entire system (files, databases
> etc.) encrypted but if their server is open and keys
> accessible then whether the code for OS or database is
> available or not is a moot point; hackers will still
> be able to get the sensitive data.
> 
> HTH,
> 
> Jalil Vaidya
> 
>  --- "Downey, Shawn" <[EMAIL PROTECTED]> wrote: 
> > Thank you for your replies (both yours and Jalil's).
> >  I understand that
> > SQLite is not universally applicable.  Let me give
> > you some background
> > to better explain my request.
> > 
> > We currently have a product (which we inherited the
> > responsibility from
> > another company).  This product was originally
> > written to use SQLite.
> > We have expanded the this product (continuing to use
> > SQLite).
> > 
> > Now our organization is partnered with another
> > company which has a
> > related product which uses SQL Server 7.  This new
> > partner is pushing my
> > management to convert our product over to use SQL
> > Server 7 instead of
> > SQLite.  The intent is that we can use a single
> > database format at some
> > point in the future.
> > 
> > I can see no earthy reason to move in that
> > direction.  If a single
> > database is needed, I would like to see it be
> > SQLite.  I am convinced
> > that SQLite could fill both companies our needs. 
> > 
> > I am sorry I can not disclose more about the
> > products in question.  What
> > I am looking for are some talking points which can
> > convince my own
> > management to push back against converting all our
> > good work into SQL
> > Server 7.  I am trying to overcome the attitude of:
> > 
> > "If SQLite is as good as you say, then why is it
> > free?"
> > 
> > and 
> > 
> > "If anyone can see the source code, then won't we be
> > venerable to
> > hackers?"
> > 
> > etc.
> > 
> > Thanks again.
> > 
> > Shawn M. Downey
> > MPR Associates
> > 632 Plank Road, Suite 110
> > Clifton Park, NY 12065
> > 518-371-3983 x3 (work)
> > 860-508-5015 (cell)
> > 
> > 
> > -Original Message-
> > From: Fred Williams [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, January 31, 2005 10:32 AM
> > To: sqlite-users@sqlite.org
> > Subject: RE: [sqlite] SQLite Advocacy
> > 
> > I think if your organization is truly looking at
> > SQLite vs SQL Server,
> > you need to reconsider your project specifications. 
> > You are basically
> > comparing a Corvette to a  Greyhound Bus.
> > 
> > Fred
> > 
> > -Original Message-
> > From: Downey, Shawn [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 31, 2005 8:28 AM
> > To: sqlite-users@sqlite.org
> > Subject: [sqlite] SQLite Advocacy
> > 
> > 
> > In our organization, my management is debating the
> > use of SQLite vs. MS
> > SQL Server 7 for an upcoming MS Windows project. 
> > Does anyone have any
> > SQLite advocacy info I can use?  Perhaps a link to
> > an article?  I am
> > hoping someone had written something eloquent about
> > SQLite's advantages
> > such as its size, speed, zero-installation, etc.
> > 
> > ...
> > 
> > 
> >  
> 
> =
> 01001010
> 0111
> 01101100
> 01101001
> 01101100
> 

RE: [sqlite] SQLite Advocacy

[Fred Williams]

Politically, if you  are in the organization that was "acquired", you
best bite the bullet and learn to dance the Big Gates' version of "I
Shall Overcome."  I don't think there is a WinCE version of SQL Server,
(yet) so that might be your only real chance.

My experience with organizations that embrace all things Gates' is,
pretty much any technical advantageous products which lie outside the
Mickeysoft umbrella are ignored and usually completely banned as, "not
conforming to organization policy."

Fred

-Original Message-
From: Downey, Shawn [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 9:58 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy


Thank you for your replies (both yours and Jalil's).  I understand that
SQLite is not universally applicable.  Let me give you some background
to better explain my request.

We currently have a product (which we inherited the responsibility from
another company).  This product was originally written to use SQLite.
We have expanded the this product (continuing to use SQLite).

Now our organization is partnered with another company which has a
related product which uses SQL Server 7.  This new partner is pushing my
management to convert our product over to use SQL Server 7 instead of
SQLite.  The intent is that we can use a single database format at some
point in the future.
...


-Original Message-
From: Fred Williams [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 10:32 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy

I think if your organization is truly looking at SQLite vs SQL Server,
you need to reconsider your project specifications.  You are basically
comparing a Corvette to a  Greyhound Bus.
...

[sqlite] sqlite3_reset

[Jan-Eric Duden]

Hi!
I have a couple of questions regarding the sqlite3_reset function.
Does sqlite3_reset free all the locks on the database?
Do I actually need to call sqlite3_reset directly after sqlite3_step is 
done to free database locks?
Or does sqlite3_step free the locks automatically?

Thanks in advance!
Jan-Eric Duden

RE: [sqlite] SQLite Advocacy

[Drew, Stephen]

Shawn,

"If SQLite is as good as you say, then why is it free?"

Things don't have to cost the earth (or anything at all) to be good! 

"If anyone can see the source code, then won't we be venerable to
hackers?"

There is a encryption package available, at a cost.
http://www.hwaci.com/sw/sqlite/prosupport.html

Regards,
Steve 

-Original Message-
From: Downey, Shawn [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 31, 2005 3:58 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy

Thank you for your replies (both yours and Jalil's).  I understand that
SQLite is not universally applicable.  Let me give you some background
to better explain my request.

We currently have a product (which we inherited the responsibility from
another company).  This product was originally written to use SQLite.
We have expanded the this product (continuing to use SQLite).

Now our organization is partnered with another company which has a
related product which uses SQL Server 7.  This new partner is pushing my
management to convert our product over to use SQL Server 7 instead of
SQLite.  The intent is that we can use a single database format at some
point in the future.

I can see no earthy reason to move in that direction.  If a single
database is needed, I would like to see it be SQLite.  I am convinced
that SQLite could fill both companies our needs. 

I am sorry I can not disclose more about the products in question.  What
I am looking for are some talking points which can convince my own
management to push back against converting all our good work into SQL
Server 7.  I am trying to overcome the attitude of:

"If SQLite is as good as you say, then why is it free?"

and 

"If anyone can see the source code, then won't we be venerable to
hackers?"

etc.

Thanks again.

Shawn M. Downey
MPR Associates
632 Plank Road, Suite 110
Clifton Park, NY 12065
518-371-3983 x3 (work)
860-508-5015 (cell)


-Original Message-
From: Fred Williams [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 10:32 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy

I think if your organization is truly looking at SQLite vs SQL Server,
you need to reconsider your project specifications.  You are basically
comparing a Corvette to a  Greyhound Bus.

Fred

-Original Message-
From: Downey, Shawn [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 8:28 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] SQLite Advocacy


In our organization, my management is debating the use of SQLite vs. MS
SQL Server 7 for an upcoming MS Windows project.  Does anyone have any
SQLite advocacy info I can use?  Perhaps a link to an article?  I am
hoping someone had written something eloquent about SQLite's advantages
such as its size, speed, zero-installation, etc.

...

RE: [sqlite] SQLite Advocacy

[Downey, Shawn]

Thank you for your replies (both yours and Jalil's).  I understand that
SQLite is not universally applicable.  Let me give you some background
to better explain my request.

We currently have a product (which we inherited the responsibility from
another company).  This product was originally written to use SQLite.
We have expanded the this product (continuing to use SQLite).

Now our organization is partnered with another company which has a
related product which uses SQL Server 7.  This new partner is pushing my
management to convert our product over to use SQL Server 7 instead of
SQLite.  The intent is that we can use a single database format at some
point in the future.

I can see no earthy reason to move in that direction.  If a single
database is needed, I would like to see it be SQLite.  I am convinced
that SQLite could fill both companies our needs. 

I am sorry I can not disclose more about the products in question.  What
I am looking for are some talking points which can convince my own
management to push back against converting all our good work into SQL
Server 7.  I am trying to overcome the attitude of:

"If SQLite is as good as you say, then why is it free?"

and 

"If anyone can see the source code, then won't we be venerable to
hackers?"

etc.

Thanks again.

Shawn M. Downey
MPR Associates
632 Plank Road, Suite 110
Clifton Park, NY 12065
518-371-3983 x3 (work)
860-508-5015 (cell)


-Original Message-
From: Fred Williams [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 31, 2005 10:32 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] SQLite Advocacy

I think if your organization is truly looking at SQLite vs SQL Server,
you need to reconsider your project specifications.  You are basically
comparing a Corvette to a  Greyhound Bus.

Fred

-Original Message-
From: Downey, Shawn [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 8:28 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] SQLite Advocacy


In our organization, my management is debating the use of SQLite vs. MS
SQL Server 7 for an upcoming MS Windows project.  Does anyone have any
SQLite advocacy info I can use?  Perhaps a link to an article?  I am
hoping someone had written something eloquent about SQLite's advantages
such as its size, speed, zero-installation, etc.

...

RE: [sqlite] SQLite Advocacy

[Fred Williams]

I think if your organization is truly looking at SQLite vs SQL Server,
you need to reconsider your project specifications.  You are basically
comparing a Corvette to a  Greyhound Bus.

Fred

-Original Message-
From: Downey, Shawn [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 8:28 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] SQLite Advocacy


In our organization, my management is debating the use of SQLite vs. MS
SQL Server 7 for an upcoming MS Windows project.  Does anyone have any
SQLite advocacy info I can use?  Perhaps a link to an article?  I am
hoping someone had written something eloquent about SQLite's advantages
such as its size, speed, zero-installation, etc.

...

Re: [sqlite] SQLite Advocacy

[Jalil Vaidya]

You should really consider the use-cases. SQLite is
meant to be used as an embeded database where as MS
SQL Server 7 is a full fledge RDBMS. Both have their
own place depending upon the requirement and may not
be possible to use interchangeably. I'd say it
depends...

HTH,

Jalil 

 --- "Downey, Shawn" <[EMAIL PROTECTED]> wrote: 
> In our organization, my management is debating the
> use of SQLite vs. MS
> SQL Server 7 for an upcoming MS Windows project. 
> Does anyone have any
> SQLite advocacy info I can use?  Perhaps a link to
> an article?  I am
> hoping someone had written something eloquent about
> SQLite's advantages
> such as its size, speed, zero-installation, etc.  
> 
>  
> 
> Thank you.
> 
>  
> 
> Shawn M. Downey
> 
> MPR Associates
> 
> 632 Plank Road, Suite 110
> 
> Clifton Park, NY 12065
> 
> 518-371-3983 x3 (work)
> 
> 860-508-5015 (cell)
> 
>  
> 
>  

=
01001010
0111
01101100
01101001
01101100

[sqlite] SQLite Advocacy

[Downey, Shawn]

In our organization, my management is debating the use of SQLite vs. MS
SQL Server 7 for an upcoming MS Windows project.  Does anyone have any
SQLite advocacy info I can use?  Perhaps a link to an article?  I am
hoping someone had written something eloquent about SQLite's advantages
such as its size, speed, zero-installation, etc.  

 

Thank you.

 

Shawn M. Downey

MPR Associates

632 Plank Road, Suite 110

Clifton Park, NY 12065

518-371-3983 x3 (work)

860-508-5015 (cell)

 

FW: [sqlite] slow "INSERT"

[Alessandro Renzi (RM/TEI)]

Thanks to everyone,
I'll have to study more but I've already tried some of your suggestions and now 
sqlite
behaviour is very, very good.
/Ale


-Original Message-
From: Tito Ciuro [mailto:[EMAIL PROTECTED]
Sent: lunedì 31 gennaio 2005 11.06
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] slow "INSERT"

Alessandro,

Take a few minutes to read the different wiki pages. There is a lot of 
info there. Answering your question:

http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning

Just scroll at the end of the page: Use transactions when updating 
tables. Another reference:

http://www.sqlite.org/cvstrac/wiki?p=MultiThreading

Regards,

-- Tito

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: lunedì 31 gennaio 2005 10.58
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] slow "INSERT"

You should use a transaction otherwise sqlite syncs the file for every INSERT.

Clive

-Original Message-
From: Ionut Filip [mailto:[EMAIL PROTECTED]
Sent: lunedì 31 gennaio 2005 11.04
To: Alessandro Renzi (RM/TEI)
Subject: RE: [sqlite] slow "INSERT"


Hi Ale,

Your code is correct, however there are two things you should be aware:

1. With SQLite if you don't use explicit transactions every INSERT will
have it's own transaction. This means data will be flushed to disk after
each insert. Use a single transactions for all inserts ("BEGIN
TRANSACTION" / "END TRANSACTION").

2. For every insert that you made now, the SQL statement is parsed, this
is obviously not efficient. Use instead prepared (or precompiled)
statements. See http://www.sqlite.org/docs.html for details.

By doing this two things you'll get speeds as in
http://www.sqlite.org/speed.html .

Ionut


-Original Message-
From: Alessandro Renzi (RM/TEI) [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 31, 2005 11:49 AM
To: 'sqlite-users@sqlite.org'
Subject: [sqlite] slow "INSERT"


Hi,
I'm a new sqlite user.
For sure I'm doing something wrong with sqlite because it takes about 1
second to perform 10 INSERT operation ! If instead I use the sqlite client
and read an external file with thousands of  INSERT operation the updating
is almost immediate. The test program I'm using is the following one:

char * sql = "INSERT INTO PEOPLE (NAME, AGE) VALUES
('John','25')";
for (int i=0; i<100; i++) {
rc = sqlite_exec(db,sql,callback,0,);
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %s\n", zErrMsg);
return 1;
}
}

Where I'm wrong ?
Thanks, Ale

Re: [sqlite] slow "INSERT"

[Tito Ciuro]

Alessandro,
Take a few minutes to read the different wiki pages. There is a lot of 
info there. Answering your question:

http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning
Just scroll at the end of the page: Use transactions when updating 
tables. Another reference:

http://www.sqlite.org/cvstrac/wiki?p=MultiThreading
Regards,
-- Tito
On Jan 31, 2005, at 10:49, Alessandro Renzi (RM/TEI) wrote:
Hi,
I'm a new sqlite user.
For sure I'm doing something wrong with sqlite because it takes about 
1 second to perform 10 INSERT operation !
If instead I use the sqlite client and read an external file with 
thousands of  INSERT operation the updating is
almost immediate.
The test program I'm using is the following one:

char * sql = "INSERT INTO PEOPLE (NAME, AGE) VALUES ('John','25')";
for (int i=0; i<100; i++) {
rc = sqlite_exec(db,sql,callback,0,);
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %s\n", zErrMsg);
return 1;
}
}
Where I'm wrong ?
Thanks, Ale

Re: [sqlite] slow "INSERT"

[clive]

You should use a transaction otherwise sqlite syncs the file for every INSERT.

Clive





"Alessandro Renzi (RM/TEI)" <[EMAIL PROTECTED]> on 31-01-2005
11:49:24

Please respond to sqlite-users@sqlite.org

To:   "'sqlite-users@sqlite.org'" 
cc:(bcc: clive/Emultek)

Subject:  [sqlite] slow "INSERT"



Hi,
I'm a new sqlite user.
For sure I'm doing something wrong with sqlite because it takes about 1 second
to perform 10 INSERT operation !
If instead I use the sqlite client and read an external file with thousands of
INSERT operation the updating is
almost immediate.
The test program I'm using is the following one:

 char * sql = "INSERT INTO PEOPLE (NAME, AGE) VALUES ('John','25')";
 for (int i=0; i<100; i++) {
  rc = sqlite_exec(db,sql,callback,0,);
  if( rc!=SQLITE_OK ){
   fprintf(stderr, "SQL error: %s\n", zErrMsg);
   return 1;
  }
 }

Where I'm wrong ?
Thanks, Ale

[sqlite] slow "INSERT"

[Alessandro Renzi (RM/TEI)]

Hi,
I'm a new sqlite user.
For sure I'm doing something wrong with sqlite because it takes about 1 second 
to perform 10 INSERT operation !
If instead I use the sqlite client and read an external file with thousands of  
INSERT operation the updating is
almost immediate.
The test program I'm using is the following one:

char * sql = "INSERT INTO PEOPLE (NAME, AGE) VALUES ('John','25')";
for (int i=0; i<100; i++) {
rc = sqlite_exec(db,sql,callback,0,);
if( rc!=SQLITE_OK ){
fprintf(stderr, "SQL error: %s\n", zErrMsg);
return 1;
}
}

Where I'm wrong ?
Thanks, Ale