[sqlite] Looking for pre-compiled version of sqlite for FreeBSD
Does anyone know where I can get a binary executable of sqlite for the FreeBSD 4.8 platform. This is what my ISP runs and I don't get Telnet/SSH access with my account, so I can't compile. I have Linux and Windows boxes. Thanks. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] tcl/sqlite executing code on failed transaction
-Original Message-
From: Kurt Welgehausen [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 07, 2004 5:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] tcl/sqlite executing code on failed transaction
You should take a look at tcl's catch command. You could
put all your SQLite code in one catch command,
if {[catch {
db eval begin ;# or maybe {begin on conflict rollback}
db eval {... }
db eval {... }
db eval {... }
db eval commit} err]} {
doSomething $err
}
or you could catch each 'db eval ...', or anything in between.
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks very much Kurt. That is exactly what I needed.
later,
marvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] tcl/sqlite executing code on failed transaction
You should take a look at tcl's catch command. You could
put all your SQLite code in one catch command,
if {[catch {
db eval begin ;# or maybe {begin on conflict rollback}
db eval {... }
db eval {... }
db eval {... }
db eval commit} err]} {
doSomething $err
}
or you could catch each 'db eval ...', or anything in between.
Regards
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
- Original Message - From: "Nate Bargmann" <[EMAIL PROTECTED]> > A plugin style of architecture seems much better than a bloated > all-in-one approach. Agreed, a plug-inn mechanism or lib-sqlite-bloated would do the job just as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
On 7 Feb 2004 at 12:10, Rene wrote: > > How old is 2.5.6 version? > > july 7. 2002 > http://www.sqlite.org/cvstrac/timeline?d=3000=2004-Feb-07=0==0=1=1=1=1 > > i'm just wondering what strategy will be if database format changes in the > future, do we depend on external utility then? I think the answer should be 'yes'. There are lots of ways you can move a DB from one engine to another, but if you have an 'orphaned' DB, then you're just out of luck, and we can't all have the luxury of storing a complete text-format data dump of our database around. I'm concerned about 'legacy' databases -- if/when the sysadmins update the SQLite package, all of my apps will die. But worse: some of my very infrequently used DBs [e.g., an archived log DB from past years] will become irretrievably dead. so I think, just as Word and Word Perfect and Excel and other such apps do, I really think that SQLite should have available 'helper' apps that'll be able to convert just about ANY old DB format to whatever-is- current. I agree, that the DB engine, itself, should *NOT* be larded up with all of that kind of stuff: keep it lean and mean. But *do* avoid orphaning our old data... /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
hi, yes, user defined function / callback functionality is there. and of course, user defined functions are great! but i think sqlite should also (try to) compete with alternatives. for some platforms (scripting languages like php) udf may just be (too) slow. i don't mind nor care adding more of those functions, but i think at least 1 encryption function should be available, for an obvious reason: storing passwords in databases. quite often, there is no need to store the password itself, but you just want some verification. next to that, sqlite does not have any mechanism for restricting access, it depends on file privileges. so you have to think twice before storing passwords in plain text in a sqlite DB. what are arguments for this minimalistic approach? in this case not platform compatability, or code size. i can understand that we do not want to end up with 5Mb of executable code, but smallest possible footprint is not (my) major issue. - Original Message - From: "Michael Roth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 2:04 PM Subject: Re: [sqlite] OK to drop support for legacy file formats? > Rene wrote: > >>Why not remove the feature but create a seperate utility project that > >>converts any version of SQLITE DB to the latest version. > > > > > > i think it's better to let it in. why save a few bytes for removing such > > important functionality. by the way, same for md5, you should add support. > > You need MD5. The nextone needs SHA1. Another one needs CRC16. Some > folks may need a function to count hills in an given area. > > Sqlite is a database library and isn't an universal calculator. A > software package should do one thing and should it do well. A database > should store and retrieve data and shouldn't calculate crypto stuff. > > If you need a special function foo() use the extension api of sqlite. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
> If you need a special function foo() use the extension api of sqlite. This is perfectly correct! Few bytes are the footprint of a quick and small database. Thats is more or less the definition. Code that is rarely used and also, does not provide a core function in sqlite, should simply not be there. The discussion gets off the target because if you ask someone if support for this function or that thing is compiled in, there will always be stuff missing and the design goal for sqlite will start diverge from the "small footprint trademark". However, first of all, I am an administrator, and a user and mainly uses and implements sqlite in my applications so bare with me if am totally off track here. My opinion is that the core code should be extremely small and fast and complie to ansi sql as far as possible. To this, the interface where you can add functions should be more of a public library where people needing a certain algorithm , say crypto or compatibility for this or that version, just should be a downloadable plugin. Just have a project that checks the contributed name standard of the provided functions so that it does not by accident can be found two plugin-functions with the same name. Ideally, someone is also reviewing the patches for qualtiy before they are put in the public plugin-area. regards, Jonas Forsman - Original Message - From: "Michael Roth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 07, 2004 2:04 PM Subject: Re: [sqlite] OK to drop support for legacy file formats? > Rene wrote: > >>Why not remove the feature but create a seperate utility project that > >>converts any version of SQLITE DB to the latest version. > > > > > > i think it's better to let it in. why save a few bytes for removing such > > important functionality. by the way, same for md5, you should add support. > > You need MD5. The nextone needs SHA1. Another one needs CRC16. Some > folks may need a function to count hills in an given area. > > Sqlite is a database library and isn't an universal calculator. A > software package should do one thing and should it do well. A database > should store and retrieve data and shouldn't calculate crypto stuff. > > If you need a special function foo() use the extension api of sqlite. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
