[sqlite] Does anyone know how I would uninstall sqlite?
I have the latest version of sqlite3 on my debian box and I'd like to uninstall it because I keep getting this error through bash: sqlite3: error while loading shared libraries: libsqlite3.so.0: cannot open shared obje ct file: No such file or directory I'm actually running xandros linux and I just want to find where all the files were installed so I can delete them manually and install sqlite through a debian package. Is this possible? -- -TwoEyedHuman tech support d00d at Glenkirk www.glenkirk.org my home: greenguy41.csoft.net linux user 39
Re: [sqlite] store result
thanks, i failed to notice that one, any way thanks for your replay Jay Sprenkle <[EMAIL PROTECTED]> wrote: On 1/19/06, manoj marathayil wrote: > ok this i can do, but the problem is i need to select a set of records and i > want to manipulate with each record then only i need to delete that record That's why I had it separated. Select the set into a temporary table. Process the records listed in the temporary table. Then delete them when you're finished using the temporary table to define what to delete: delete from source_table where id in ( select id from temp_table ); > > Jay Sprenkle wrote: On 1/19/06, manoj marathayil wrote: > > > > hi, > > is there is any way so that i can store the result > > of > > a select query and execute a delete query on the > > same > > table with out using any other buffer? > > How about: > > select id > into temp_table > from source_table > where somecondition = true; > > delete from source_table > where id in ( select id from temp_table ); > > > > Send instant messages to your online friends http://in.messenger.yahoo.com > -- --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264 T h a n k s & R e g a r d s , Manoj M | Webyog | Bangalore | Voice: 91 9886171984, 91 80 51216434(off) "A winner is not one who never fails, but one who never quits!" Send instant messages to your online friends http://in.messenger.yahoo.com
Re: [sqlite] Version 3.3.0 (alpha)
Does anyone have any more information or documentation on how to use the "READ UNCOMMITTED" feature of the latest version? Thanks, Jeff [EMAIL PROTECTED] wrote: SQLite version 3.3.0 is now available on the website http://www.sqlite.org/ Version 3.3.0 incorporates many enhancements and changes. Among the changes in this release: * CHECK constraints are now enforced. * The IF [NOT] EXISTS syntax of MySQL is now recognized on CREATE/DROP TABLE/INDEX statements. * DESC indices really are descending now. The DESC keyword on index definitions used to be ignored. * The database file format has changed slightly to more compactly represent boolean values and to support DESC indices. Version 3.3.0 will read and write all prior version 3 databases. But new databases created by version 3.3.0 will not be readable by older versions of SQLite. If this is a problem for your application, compile SQLite using -DSQLITE_DEFAULT_FILE_FORMAT=1 and then version 3.3.0 will create new databases in the legacy format understood by all prior versions of SQLite. DESC indices only work in the new format. * SQLite now distinguishes between REAL and INTEGER columns and attempts to make appropriate conversions. * The OS-interface layer has been modified for greater flexibility and control of custom ports and implementations. * SQLite now responses better to out-of-memory errors. The library will recover and reset itself automatically. There is no longer a need to call sqlite3_global_recover(). The new sqlite3_enable_memory_management() API can be used to put SQLite into a mode where it will automatically try to reduce its database cache size when it comes under memory pressure. * The database cache and parsed schema information can now optionally be shared between two or more database connections. This can be used to reduce I/O and to improve concurrency. On a database using a shared cache, you can specify READ UNCOMMITTED isolation as an option (the default is SERIALIZABLE). With READ UNCOMMITTED, a reader will not block or be blocked by a writer and you will never get an SQLITE_BUSY error on a read. There have been many internal changes to SQLite. The library passed a full regression test with no errors prior to this release, but even so you can expect to find a few bugs. Please report them. Consider this release to be an alpha. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] journal files and database corruption
On Jan 20, 2006, at 8:25 AM, Will Leshner wrote: Thanks for this information. It sounds like a reasonable precaution might be not to make "too many" changes to a database in one transaction. But I guess knowing how many changes is too many would be a pretty hard thing to figure out. Sorry to reply my own email, but I wonder if it might be useful to have some mechanism by which SQLite could report back when it has filled its cache and is about to spill it to disk? I'm not sure what a user would do with such a callback. It's probably unlikely that a commit could occur right at that spot because SQLite itself will be in the middle of doing something else. But maybe the callback could allow the user to abort the writing of the cache, and if that happened, it could be treated as some kind of fatal error that would basically abort the entire transaction.
RE: [sqlite] Decimal conversion
I was using version 3.2.1. I downloaded 3.3.1 and your suggestion worked, but it is very slow compared to 3.2.1. I use the original query to test the speed. 3.2.1 returned the data in a little over 10 seconds while 3.3.1 took a minute. Why is that? I used .dump to create .sql files and then loaded 3.3.1 from the .sql files. -Original Message- From: Dennis Cote [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 2:31 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Decimal conversion nbiggs wrote: >When I try executing the command I get 'SQL error: near "as": syntax >error'. > >Let me explain what I am trying to do, there might be a better way to do >it. I have a table of weights as one of the columns. I am trying to >return data so that I can create a histogram of the data. My query is >as follows: > >Select round(field, 1), count(*) >from table >group by round(field, 1); > > > > Nathan, What version of SQLite are you using? The cast syntax was added fairly recently. I'm using version 3.2.7 to test. With a current version of SQLite this should work. select cast (field * 10 as integer) / 10.0 as bin, count(*) from table group by bin; Note, you wont get a result row for any bin values that would have had a count of zero. I.e. if there are no rows with a value of 49.8?? then there will not be a result row in the histogram for that value with a count of zero. The histogram output only has rows where the count was 1 or more. This may or may not be what you want. HTH Dennis Cote
Re: [sqlite] journal files and database corruption
On Jan 20, 2006, at 8:07 AM, [EMAIL PROTECTED] wrote: Deleting a hot journal after a power loss or OS crash is more likely to result in severe database corruption, but database corruption is possible from deleting a hot journal after an ordinary program crash. Thanks for this information. It sounds like a reasonable precaution might be not to make "too many" changes to a database in one transaction. But I guess knowing how many changes is too many would be a pretty hard thing to figure out. I'm mainly thinking about what happens if a customer doesn't realize what the journal file is and throws it away. Probably the best way to avoid that problem is to be sure to tell the customer not to do that :)
Re: [sqlite] journal files and database corruption
Will Leshner <[EMAIL PROTECTED]> wrote: > On Jan 20, 2006, at 7:41 AM, [EMAIL PROTECTED] wrote: > > > The database might be completely unusable. It depends on > > which writes completed and which had not at the time of the > > crash. > > Am I right in thinking that that would be more likely to happen in, > say, a hardware failure, and less likely to happen if the crash > occurs because of a bug in my code? In other words, if every SQLite > call returns successfully, is it unlikely that the database is in an > unusable state? > Deleting a hot journal after a power loss or OS crash is more likely to result in severe database corruption, but database corruption is possible from deleting a hot journal after an ordinary program crash. Here is one scenario for generating reasonably severe database corruption by crashing a program: (1) Start a transaction (2) Make *many* changes to the database - so many that the internal cache overflows and has to spill to disk. (3) Crash the program. (4) Delete the journal file Another way to get database corruption from a program crash is to crash the program during a COMMIT and then delete the journal. This might happen, for example, if one thread is doing a COMMIT and a different thread happens to segfault at the same time. (Yet another reason to not used threads!) -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] journal files and database corruption
On Jan 20, 2006, at 7:41 AM, [EMAIL PROTECTED] wrote: The database might be completely unusable. It depends on which writes completed and which had not at the time of the crash. Am I right in thinking that that would be more likely to happen in, say, a hardware failure, and less likely to happen if the crash occurs because of a bug in my code? In other words, if every SQLite call returns successfully, is it unlikely that the database is in an unusable state? Thanks.
Re: [sqlite] journal files and database corruption
Will Leshner <[EMAIL PROTECTED]> wrote: > In the article about locking and concurrency on the SQLite website, > where it talks about how to corrupt a SQLite database, it says that a > SQLite database can be corrupted if a hot journal file is missing > when SQLite reconnects to the database. What kind of corruption are > we talking about, exactly? Is it that the data in the database is > inconsistent, in the sense that only some of the data has been > written with no way to roll any of it back? Or is this a more serious > kind of corruption in which the database file becomes completely > unusable? I guess I'd always thought the latter, but after reading > through the article more carefully, I am now thinking it might be the > former. If it is the former, it might be useful to make that explicit > in the article. While having an inconsistent database is certainly a > BadThing, having a completely unusable database (one that SQLite > can't even open anymore) is far worse, in my opinion. > The database might be completely unusable. It depends on which writes completed and which had not at the time of the crash. -- D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] journal files and database corruption
In the article about locking and concurrency on the SQLite website, where it talks about how to corrupt a SQLite database, it says that a SQLite database can be corrupted if a hot journal file is missing when SQLite reconnects to the database. What kind of corruption are we talking about, exactly? Is it that the data in the database is inconsistent, in the sense that only some of the data has been written with no way to roll any of it back? Or is this a more serious kind of corruption in which the database file becomes completely unusable? I guess I'd always thought the latter, but after reading through the article more carefully, I am now thinking it might be the former. If it is the former, it might be useful to make that explicit in the article. While having an inconsistent database is certainly a BadThing, having a completely unusable database (one that SQLite can't even open anymore) is far worse, in my opinion. Thanks.
Re: [sqlite] store result
On 1/19/06, manoj marathayil <[EMAIL PROTECTED]> wrote: > ok this i can do, but the problem is i need to select a set of records and i > want to manipulate with each record then only i need to delete that record That's why I had it separated. Select the set into a temporary table. Process the records listed in the temporary table. Then delete them when you're finished using the temporary table to define what to delete: delete from source_table where id in ( select id from temp_table ); > > Jay Sprenkle <[EMAIL PROTECTED]> wrote: On 1/19/06, manoj marathayil wrote: > > > > hi, > > is there is any way so that i can store the result > > of > > a select query and execute a delete query on the > > same > > table with out using any other buffer? > > How about: > > select id > into temp_table > from source_table > where somecondition = true; > > delete from source_table > where id in ( select id from temp_table ); > > > > Send instant messages to your online friends http://in.messenger.yahoo.com > -- --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264
[sqlite] Re: Checking for string length
malcom wrote: Hello, is possible with sqlite to return a row with a column string length > n chars? ex: SELECT * FROM TABLE WHERE MY_COLUMN LENGTH > 0 SELECT * FROM TABLE WHERE length(MY_COLUMN) > 0 Igor Tandetnik
Re: [sqlite] Checking for string length
See http://www.sqlite.org/lang_expr.html Ran On 1/20/06, malcom <[EMAIL PROTECTED]> wrote: > > Hello, is possible with sqlite to return a row with a column string > length > n chars? > > ex: SELECT * FROM TABLE WHERE MY_COLUMN LENGTH > 0 > > thanks >
[sqlite] Checking for string length
Hello, is possible with sqlite to return a row with a column string length > n chars? ex: SELECT * FROM TABLE WHERE MY_COLUMN LENGTH > 0 thanks
[sqlite] Re: Question about string concatenation
thanks a lot 2006/1/20, malcom <[EMAIL PROTECTED]>: > Hello, > Anyone can translate this SQL query to sqlite? I know that to > concatenate two string you should to use || but I can't port this > query to sql :( > > UPDATE table_name > SET column = CONCAT(column, " other text to add") > WHERE confront_column_key = "something_key" > > Thanks > -- -- marklar-x86 software development -- web: www.malcom-mac.com mail: [EMAIL PROTECTED]
