Re: [sqlite] Client/Srever SQLite
I am using SQLite for a storage backend for a phone application, the application downloads the information from an XML-RPC based host and sends information to and from a database. The data is held in the database so the phone application doesn't have to get all the information every 15 minutes or so. This save on bandwidth and connections, as well as battery life. SQLite is such a great storage engine. I am also trying to write a mysql storage plugin so that SQLite databases can easily be taken out. I have found so many uses for SQLite, it is truly a great product / development. On Jun 2, 2008, at 10:40 AM, Alex Katebi wrote: Hi All, I am using remote procedure calls (RPC) for SQLite in my application. I have implemented a few SQLite RPC functions that I needed successfully. I am wondering if there are other people like me who need this. If there are enough people who could benefit from this I can make it available as an open source public domain software. Then people can add more functions as needed. Thanks, -Alex ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite and OS X - Can I have multiple versions?
What I did was used the SQLite sources and added them into a Carbon framework. Then set sqlite3.h and the other source header to public. That way I could call the functions. Then i set the installation path to @executable_path/../Frameworks, then added a new copy phase and copied the target to the Frameworks folder. It really works well, and you don't have to worry about installing the libraries in /usr/lib or wherever when distributing your library. On Jan 28, 2008, at 3:29 PM, Carl Gundel wrote: As I understand it, Apple's Mac OS X comes with SQLite as part of its Mail app. Is there some way to leverage this to avoid distributing SQLite with Mac apps? Has anyone tried this, or is it a bad idea? I'm assuming that I can have my own copy of SQLite packaged with my OS X application and it will not conflict with the version that Apple ships? Thanks, -Carl Gundel http://www.runbasic.com -- View this message in context: http://www.nabble.com/SQLite-and-OS-X---Can-I-have-multiple-versions--tp15145894p15145894.html Sent from the SQLite mailing list archive at Nabble.com. - To unsubscribe, send email to [EMAIL PROTECTED] - smime.p7s Description: S/MIME cryptographic signature
Re: [sqlite] Next Version of SQLite
I was wondering what would constitute the creation of SQLite 4.0? Since the VDBE is being revamped I would consider this a pretty big revamp of the SQLite code. I am looking forward to testing this out new engine out. I also wanted to know what the difference between stack based and register based is. Unfortunately, i do not mess with a lot of C / C++ code in my work. So I was a little curious. On Jan 13, 2008, at 7:41 PM, D. Richard Hipp wrote: On Jan 13, 2008, at 7:53 PM, Gerry Snyder wrote: Joe Wilson wrote: --- D. Richard Hipp [EMAIL PROTECTED] wrote: There are people on this mailing list (ex: Joe Wilson) who appear to read every line of every change that we make to SQLite, within minutes of making them, and complain if we so much as misspell a word in a comment. And I haven't heard a peep from Joe Wow - what prompted that dig against me? I took it as a kidding compliment. I saw an invisible smiley after his comment. Your contributions to SQLite are appreciated by all of us. Exactly. My remark was meant to indicate that I am amazed at how much attention you pay to the code, not any kind of a dig. Sorry for the confusion. You are an important member of the quality assurance team and I hope that you will continue in that role. D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] - smime.p7s Description: S/MIME cryptographic signature
Re: [sqlite] Database Commoditization and SQLite
I think commercial database solutions have their place in the market, and I don't think Richard looks bad in this article. He simply created something that needed to be created. When I am developing an application that uses a database I first lay everything out on whiteboard, then I write some SQLite SQL code, then start writing my application using sqlite3.h. Once I have everything worked out in the sqlite3 code I am able to plug in other APIs like postgresql, mysql, etc. It is so much easier to do it this way and test everything without having continuous access to the database servers or software. More or less it is a database on the go with stability, and community support. I want SQLite to continue to add features and remain stable. Keep up the great work. On Jan 7, 2008, at 3:55 PM, [EMAIL PROTECTED] wrote: Says Brian Aker, Director of Architecture at MySQL AB: SQLite has commoditized the entire low end of the database market out of existence. http://www.linuxworld.com/community/?q=node/2106 -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] - smime.p7s Description: S/MIME cryptographic signature
Re: [sqlite] Database Commoditization and SQLite
That is a great point. But it does help me slim down my app for testing before deployment on another database On Jan 7, 2008, at 5:21 PM, Scott Baker wrote: Rick Langschultz wrote: I think commercial database solutions have their place in the market, and I don't think Richard looks bad in this article. He simply created something that needed to be created. When I am developing an application that uses a database I first lay everything out on whiteboard, then I write some SQLite SQL code, then start writing my application using sqlite3.h. Once I have everything worked out in the sqlite3 code I am able to plug in other APIs like postgresql, mysql, etc. It is so much easier to do it this way and test everything without having continuous access to the database servers or software. More or less it is a database on the go with stability, and community support. I want SQLite to continue to add features and remain stable. Keep up the great work. The way I read that quote is: SQLite is so good, and so free, that there is no reason to use anything else. Period -- Scott Baker - Canby Telcom RHCE - System Administrator - 503.266.8253 - To unsubscribe, send email to [EMAIL PROTECTED] - smime.p7s Description: S/MIME cryptographic signature
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
My question first is can this fix be rolled into a group of related fixes thus creating a service patch? If not then my opinion is 3.5.4. If you can roll it in with 3 - 10 easy fixes call it 3.6.0. Just an opinion though. I am waiting for 4.0, like it is Xmas Eve... On Dec 13, 2007, at 10:40 AM, [EMAIL PROTECTED] wrote: Ticket number #2822 http://www.sqlite.org/cvstrac/tktview?tn=2822 has provoked extensive changes to the way SQLite handles ORDER BY clauses. The current algorithm goes like this: (1) If an ORDER BY term is a constant integer k then sort by the k-th column of the result set. (2) If an ORDER BY term is a simple identifer (like x, not x.y and not x.y.z) and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. (3) Otherwise, evaluate the expression which is in the ORDER BY term and sort by the resulting value. For a compound query, the expression in step (3) must exactly match one of the result columns. Also, the three steps are attempted first on the left-most SELECT. If there is a match, the process stops there. If no match is found, the next SELECT to the right is tried. This repeats as necessary until a match is found or until you run out of SELECT statement in which case there is an error. This algorithm differs from all prior versions of SQLite (1.0.0 through 3.5.3) by the addition of step (2). Adding step (2) brings SQLite much closer to the SQL standard. I believe that SQLite is now a superset of the SQL standard. SQL has no concept of step (3). And in a compound query, SQL only looks at the left-most SELECT and does not fail over to SELECT statements to the right looking for a match. But these changes can be considered extensions. The revised algorithm is mostly compatible with the way SQLite has always operated before. But there are a few obscure corner cases where there is a difference. An example of the difference is the following: CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; In older versions of SQLite, the SELECT statement above would return 9, 1 since the ORDER BY term evaluated to the expression a.y by rule (3) In the next release, because of the addition of rule (2) above, the result will be 1, 9. My question to the community is this: Are these differences sufficient to justify going with version 3.6.0 in the next release? Or can we call the change a bug fix and number the next release 3.5.4? Other information to consider: * We do not have a lot of time to debate the merits of this change since we need to get out a release to fix critical bug #2832. * We have taken no steps toward fixing GROUP BY. If I got ORDER BY wrong, I'm guessing GROUP BY is wrong too. Thanks for your input. -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite is in Android
Actually the SQLite Database doesn't need to be encrypted it shouldn't be jailbroken or hacked into, or broken in any way. Also I am sure that an encryption algorithm inside the iPhone would cause long boot times, etc. and space issues since it already has limited space for the actual OS anyway. ATT users have no access to the data on other phone user's phones so security is more or less not a problem. On Dec 5, 2007, at 7:42 PM, Samuel R. Neff wrote: One of my co-workers was playing around with SQLite on his iPhone and was able to access data including contacts and call log and pretty much everything. It's a SQLite database and not encrypted. Sam - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Request for help with the SQLite Website
This is a big improvement to the website. Keep up the great work on SQLite. Looking forward to 4.0 On Nov 13, 2007, at 7:40 PM, [EMAIL PROTECTED] wrote: The new look for the SQLite website is now in place, if you haven't already noticed: http://www.sqlite.org/ Even though the new look is in place you should understand this as a work in progress, not a done deal. I am still looking for suggestions, comments, and bug reports. I am particularly interested in help in the following ways: * Suggestions for something better to put on the home page. * Suggestions for better CSS for the CVSTrac pages. Example: http://www.sqlite.org/cvstrac/timeline If you can save off a copy of that page, adjust the CSS to make it look better, then send me your adjustments (or post them here) that would be a *big* help. * Somebody please suggest a better tag line - something better than The World's Most Widely Used SQL Database. * Suggest changes that will provide a search bar in the upper right-hand corner. Over the next couple of weeks we plan on adding some additional pages to the site (mostly moving over information currently in the wiki) and doing additional reorganization and cleanup. We also plan to offer the documentation pages as a ZIP or tarball download so that users can view them offline. The feedback from this mailing list has so far been very helpful. Please don't stop offering suggestions. -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
