Re: [sqlite] Thanks to Peter Aronson for providing help!

Dear Peter: "Using SQLite" is on my listing to purchase. It is really helpful for me to understand futher in SQLite. Thank you again. Best Regards Tom 2012/7/30 > Send sqlite-users mailing list submissions to > sqlite-users@sqlite.org > > To

Re: [sqlite] Thanks for making my product possible

Seconded! Give yourself a raise! ;) I've seen Sqlite popping up all over. I was particularly pleased to see it being supported as a data source option for open office. On 11/1/05, Edward Wilson <[EMAIL PROTECTED]> wrote: > Ditto - sqlite is pure beauty - thanks. > > --- Clay Dowling <[EMAIL

Re: [sqlite] Thanks for making my product possible

Ditto - sqlite is pure beauty - thanks. --- Clay Dowling <[EMAIL PROTECTED]> wrote: > Amid all the wailing and gnashing of teeth I thought that I'd just say > thanks for making a great embeddable database that puts a very minimal > burden on the developer. My product, at least, would never

Re: [sqlite] Thanks

On 2005-05-23T17:29:14+0200, Joel Rosdahl wrote: > > Looking forward to a python db compliant client for 3.x hitting the > > Debian archives (apsw is nice, I am sure, but not what I want for > > the project that I am working on). > > PySQLite 2.0.2 now exists in Debian unstable: > >

Re: [sqlite] Thanks

[EMAIL PROTECTED] (Allan Wind) writes: > Looking forward to a python db compliant client for 3.x hitting the > Debian archives (apsw is nice, I am sure, but not what I want for > the project that I am working on). PySQLite 2.0.2 now exists in Debian unstable:

RE: [sqlite] Thanks!

-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 be

Re: [sqlite] Thanks!

[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

Re: [sqlite] Thanks!

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

Re: [sqlite] Thanks!

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

Re: [sqlite] Thanks!

> 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 >

Re: [sqlite] Thanks!

--- [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

Re: [sqlite] Thanks!

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

Re: [sqlite] Thanks!

> > 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

Re: [sqlite] Thanks!

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

Re: [sqlite] Thanks!

Darren Duncan <[EMAIL PROTECTED]To: sqlite-users@sqlite.org can.net> cc: Subject: Re: [

Re: [sqlite] Thanks!

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

Re: [sqlite] Thanks!

> > * 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

Re: [sqlite] Thanks!

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.

Re: [sqlite] Thanks!

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