Re: [sqlite] Lock files....
Fred Williams wrote: I picked SQLite for its minuscule (by today's standards) footprint, simplicity, and ease of deployment. Why do I get the feeling I've bought into a product like any model in the American car market. With each passing interation the vehicle gets bigger, fatter, and less efficient. This continues until the model bears absolutely no resemblance to the original. But, it does have electric fold down rear seats to the advantage of the totally clueless. I don't think version 3 has compromised the core premise offered by SQLite, but I agree with your analogy as something to watch for in the future. For instance: the new locking scheme in version 3 is irrelevant to me, since SQLite is embedded in my application and I run it as a single thread. However, I can see that attempts to prevent locking when accessing the db file by multiple threads are something that benefit the core product feature set and are real issues when you write multithreaded code. On the other hand, when (if) changes are made in order to make multiple programs access a shared db file then I believe we begin to risk code bloat, as in these scenarios one should clearly use a client/server database scheme and there are several good ones already available and proven. There is no need to bloat SQLite to cover this usage scenarior imo. But of course the code is highly modular. I like the fact that you can ommit some features when compiling by editing sqlite.h (ommit_authorization, etc.) This is a very good design decision, as it allows developers to continue embedding without some of the optional features AND makes it possible to add these features in a very simple way, without a formal plugin mechanism or something like that. So if anything I would request that some of the optional features were always implemented as modules that could be selected at compile time (when possible of course), and everyone would be happy. Regards, Mauricio
Re: [sqlite] Script perl e python, I can't open database from sqlite
D. Richard Hipp wrote: Mauricio Piacentini wrote: I will update SQLiteBrowser to use version 3 when it leaves beta status The more people use SQLite version 3, the faster it will leave beta status Oh, ok. Good to know. I will then try to release a beta version asap, to help testing. Can you rig SQLiteBrowser so that it links against both 2.8 and 3.0 and uses whichever is appropriate for the database it is reading? I already have a version linked to both versions of the library. I was planning to make it able to convert from 2 -> 3, but operate in 3.x format only from now on. I will investigate what it takes to make it able to operate with both formats, however. Regards, Mauricio
Re: [sqlite] Script perl e python, I can't open database from sqlite
SQLite version 3.0.4 Enter ".help" for instructions qlite> .databases Error: file is encrypted or is not a database sqlite> .tables Error: file is encrypted or is not a database But if I open this database with sqlitebrowser I don't have errors. Why sqlite doesn't open it ??? This error is under linux and windows. Your Perl module and SqliteBrowser are both still using SQLite version 2.8.x, so they produce databases in the SQLite 2.1 format. You are trying to read these with SQLite version 3, that's the reason why it does not work. I will update SQLiteBrowser to use version 3 when it leaves beta status, probably after the next release. Regards, Mauricio
Re: [sqlite] Tcl interface updated to require TCL version 8.4
Mosley, Harlan R. wrote: I have been considering sqlite for my windows application, and I am an individual who has not the resources to upgrade, so I continue to use TclPro 1.4 (8.3.2) because of the tools in the TcLPro package. I would not be able to use the latest sqlite because of this, but probably could still consider 2.8.15. Just to let you know you don't necessarily need TCL to use the base SQLite code and packages, to the best of my knowledge. I at least do not have it installed on Windows (but I compile the sources embedded into my project.) Just remove the tclsqlite.c source file from your build. Of course you will not be able to run the TCL tests, but you can definately run your SQLite-enabled program without having TCL installed. Regards, Mauricio
Re: [sqlite] Database locked
> I am trying to import a csv file (ip-to-country to be especific) to a > table > on sqlite db...It has 5+ lines. Tried to use php and it takes like If you are using SQLite 2.8.x you can try importing the file with SQLite Database Browser (sqlitebrowser.sourceforge.net). Use the FILE->IMPORT->CVS TO TABLE menu item. Give it a few minutes to insert all data, it should work. Regards, Mauricio Tabuleiro
Re: [sqlite] Dealing with 2 versions of SQLite
D. Richard Hipp wrote: SQLite 2.8 and SQLite 3.0 can peacefully coexist. They can even be linked together into the same binary. I have just done this for inclusion in the next version of the SQLite DB Browser, and it works great. The only problem is how to identify the file format when I open a new file, is there a way? When I open a SQLite 2.8.x db with sqlite3_open() I do not get any errors. I can even call sqlite3_exec() on it with some pragma commands, no errors returned. However when I attempt to retrieve more info (the table structure) I get error code 26, the error message explains that the db is encrypted or malformed. Is there a way to detect that I am opening a 2.8.x db? I guess I could read the signature from file, but I was hoping maybe for an error message in sqlite3_open. Not really critical but would be nice to have, and in this way we could offer to convert automatically to the new format (by doing a dump to a temp file followed by an import to a new db). Regards, Mauricio
[sqlite] ANN: SQLite Database Browser 1.1
SQLite Database Browser is a freeware, public domain, open source visual tool used to create, design and edit database files compatible with SQLite 2.x. It is hosted at sourceforge, and the home page for the project lives at http://sqlitebrowser.sourceforge.net/ Source is available of course, as well as pre-compiled binaries for Linux, Windows and Mac OSX. The following features were added in the 1.1 update: - SQL query window: enter SQL commands and see the output and error codes directly in a browser view. - SQL log: lists all SQL commands issued by the browser application and/or by the user. Useful as a tool to analyze and learn SQL. - Abitility to open database files specified with a command line parameter (sqlitebrowser mydb) and/or drag and drop. - Added experimental modify table wizard, since SQLite does not support the ALTER TABLE SQL command. Use it with care. Works correctly for all tables originally created in SQLiteBrowser. - The browser uses a transaction in the background to undo changes made to a database before they are commited to disk. All changes are now temporary until the user decides to SAVE the file. - Added CSV import/export capabilities: a wizard makes it possible to configure table importing from a CSV file (delimiters, etc.) Supports most CSV format variations, including files generated by MS Excel and Access. - Added SQL dump import/export capabities. Useful to store an SQL format backup of your database, or to interchange data with MySQL or Oracle, for example. - Added text import/export capabilities directly to from a text file to db records. - Modified record browsing interface. The spreadsheet interface now redraws faster (and clips longer records accordingly) Double click a cell to edit the record on a separate window. This allows better support for longer records including line breaks, for example. and many other small enhancements and bug fixes. Enjoy. Regards, Mauricio Piacentini Tabuleiro
Re: [sqlite] SQLite Browser (Mac OS 10.3)
Yes... in OS X, everything that happens is written on in an app called Console. I write the author a while back too and he asked that I attempt to launch it again with Console running and then send him whatever errors/messages appear, but... strangely... I am still getting nothing in the Console... as I did then. I answered to the original request at Sourceforge forums, so we can take it from there. Just wanted to point out that the MacOSX Console is not the same as the Terminal window, this is a common confusion for users coming from Unix/Linux. I answered this at the sqlitebrowser foruns, and there is a new binary for OSX 10.3 available as well (compiled with the latest Qt.) It works ok in the machines I tested, but then again the old one also worked. This new build however has some Qt fixes and official support for Panther, so you could try it and report if the problem continues. I don't know why it does not work on your machine, and you gave me no new information that we can use to find the source of the problem. The only possible clue for this come from the Console, really. Try monitoring the system.log. Another generic way to cause this problem in all OSX bundles is if for some reason the name of the executable inside the bundle does not match the one specified in the plist, for example because of an error in the decompression, or if you rename the executable. It would also be better to move the discussion to the sqlitebrowser foruns. We would be able to benefit other users of the tool if we can find out why it does not work on your particular setup, and the problem is not related to the main SQLite library, and of little interest to other users of this list. Thanks! Regards, Mauricio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite Browser (Mac OS 10.3)
Yes... in OS X, everything that happens is written on in an app called Console. I write the author a while back too and he asked that I attempt to launch it again with Console running and then send him whatever errors/messages appear, but... strangely... I am still getting nothing in the Console... as I did then. I answered to the original request at Sourceforge forums, so we can take it from there. Just wanted to point out that the MacOSX Console is not the same as the Terminal window, this is a common confusion for users coming from Unix/Linux. The Console is a separate application that logs system level errors that would prevent an app from launching, like the lack of shared libraries, etc. Make sure you are really checking Console.app and not the terminal window. As someone wrote already, shared libraries are definately a weak spot under OSX. Some consider their implementation simply broke. I would not go as far, but there are certainly something not right about them specially if you are launching from the Finder. I believe the standard SQLite distribution does not compile as a shared library under OSX exactly because of this problems, can anyone confirm this? Regards, Mauricio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite Browser (Mac OS 10.3)
[EMAIL PROTECTED] wrote: ...on Mac OS 10.3? What error you get? None. That's what's strange about it. It won't even launch. It starts in the dock but dies one second (literally) later. I can run it on MacOSX 10.3.2. However the version of Qt used to compile the binaries does not support Panther officially, so the widgets do not look correct, specially buttons. There might be other subtle issues with Panther. I will try to find time to compile a newer version against the latest Qt, but please post a request directly to the sourceforge foruns if you have not done so. If you are not using the binaries and have compiled from source you probably do not have Qt setup correctly for static compilation, or your environment is not setup correctly to use Qt shared libraries from the Finder. Since this list is dedicated to SQLite I would recommend checking the Qt forums, or posting to the sqlitebrowser message boards. Regards, Mauricio Piacentini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
