[sqlite] help:sqlite3 table and struct is miss at working

hello: Now the SQLITE3 database we use is version 3.6.23.1.which running in the red hat compiler and the hardware system is Linux(version 2.6).We have a problem that for table and struct is miss at working. Attachment is exception database. ___

Re: [sqlite] a bug report

On Mon, Jan 10, 2011 at 11:55 AM, wrote: > Hi Richard, > > I don't know if I have collected accurate and enough information for you, > please check and let me know. > > As you said, I'm calling sqlite apis to add callbacks, without any kind of > changes to sourcecode. The

Re: [sqlite] Propose minor incompatible API change

There's the issue of "this is what I meant" vs. "this is what I did." When you have a couple hundred customer's, changing the code is painful but doable. When you have a couple million customer's, then what is "out there" is the "true" API and must be kept around. Microsoft has bent over

Re: [sqlite] long running INSERT (up to now ~ 11 hours and still working)

On 01/11/2011 03:00 PM, Oliver Peters wrote: > Hello, > > I'm on WinXP and using sqlite 3.7.4 with the CLI. I try to insert ~ 10,100,000 > records into a schema with different tables (http://pastebin.com/cbsPHNEj). > The > db file has already 1.9 GB when I start the INSERTs via > > sqlite3 -bail

[sqlite] ADV: "Using SQLite" & other books on sale

Today only (Tues) O'Reilly is offering their "Top 10 Database/SQL Titles" for 60% off ebooks and videos. Included in the group is "Using SQLite", available as an ebook for only $12.80. Purchasing the ebook enables you to download DRM-free files in APK, ePub, Mobi and PDF formats.

Re: [sqlite] Propose minor incompatible API change

>An end user (think: your mom) wants to upgrade her smartphone to the >latest >OS release. That new OS release includes the latest shared library for >SQLite. But in so doing, some percentage of the apps she has downloaded >cease to work. Sure, the problem really is that the apps were

Re: [sqlite] Propose minor incompatible API change

I think that a bunch of good points have been made, especially as to why you should hold your ground. (I don't have sympathy for poor code that doesn't follow the documentation, especially when there is a large, competent, and helpful community group that usually comes to people's aid in less

Re: [sqlite] long running INSERT (up to now ~ 11 hours and still working)

Hello, Simon Slavin writes: > >[...] > > It that takes 11 hours, that means you're taking about 4ms per INSERT. I don't know if this is unusually high. > You might like to try 'PRAGMA synchronous = OFF' > > > > > sqlite3

Re: [sqlite] Propose minor incompatible API change

On 11 Jan 2011, at 13:36, Andy Gibbs wrote: > On Tuesday, January 11, 2011 1:35 PM, Jean-Denis Muys wrote: > >> Don't encumber SQLite with workarounds and special cases >> to cater to bugs in client software. > > Isn't an accurate synopsis of the problem this: that Sqlite has *already* >

Re: [sqlite] Propose minor incompatible API change

On Tuesday, January 11, 2011 1:35 PM, Jean-Denis Muys wrote: > Don't encumber SQLite with workarounds and special cases > to cater to bugs in client software. Isn't an accurate synopsis of the problem this: that Sqlite has *already* implemented a workaround in 3.7.0, and that this workaround

Re: [sqlite] Propose minor incompatible API change

On 11 Jan 2011, at 12:15, Richard Hipp wrote: > That new OS release includes the latest shared library for > SQLite. You didn't put it there, and the consequences of putting it there are not your responsibility. Nor are the consequences of someone else's app breaking because they didn't read

Re: [sqlite] Propose minor incompatible API change

If you can change the API so "correctly" written apps don't break and "poorly" written ones work too...yeah rah... The only thing I would ask is a clear example of what "correctly" written isdoes that exist? I can't find it in the documentataion. Plus, a clear example of "poorly"

Re: [sqlite] Propose minor incompatible API change

On 11 janv. 2011, at 13:15, Richard Hipp wrote: > On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps > wrote: > >> >> My rationale is that either it's technically or economically feasible >> for the offending applications' developpers to change their code to use >> the

Re: [sqlite] Propose minor incompatible API change

On Tue, Jan 11, 2011 at 6:59 AM, Jean-Christophe Deschamps wrote: > > My rationale is that either it's technically or economically feasible > for the offending applications' developpers to change their code to use > the library correctly (and that doesn't seem to be the case), OR

Re: [sqlite] Propose minor incompatible API change

>This is, technically, a compatibility break. On the other hand, there >appear to be vast numbers of smartphone applications that currently depend >on undefined behavior and will suddenly stop working if we don't make this >change. I understand the proposed change will have no incidence for

[sqlite] joining fts table with normal table

Hi, The documentation mentions the possibility of joining a fts table with a normal table via rowid. (e.g. select sender, subject from email join email_text on email.rowid = email_text.rowid where body match 'jam';) Can this join only be done via the rowid field? I tried using an "id" field

Re: [sqlite] a bug report

Hi Richard, I don't know if I have collected accurate and enough information for you, please check and let me know. As you said, I'm calling sqlite apis to add callbacks, without any kind of changes to sourcecode. The routine I'm using: 1. implement my own separate function, let's say,

Re: [sqlite] Propose minor incompatible API change

I agree with this change because it doesn't change all well written programs. It just tries to correct all incorrectly written ones, which is a good thing for the end-users. ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Propose minor incompatible API change

On Tuesday, January 11, 2011 1:54 AM, Richard Hipp wrote: > This is, technically, a compatibility break. But wasn't the original change also a compatibility break? But this time it may make it into the short-form software history at http://www.sqlite.org/changes.html? Having studied the

Re: [sqlite] Propose minor incompatible API change

On 11 janv. 2011, at 01:54, Richard Hipp wrote: > > So the question to you, gentle reader, is should we make this change, and > break backwards compatibility, albeit in a very obscure way, or should we be > hard-nosed and force hundreds or perhaps thousands of smartphone application >

Re: [sqlite] Propose minor incompatible API change

On 11 Jan 2011, at 08:20, Max Vlasov wrote: > On Tue, Jan 11, 2011 at 3:54 AM, Richard Hipp wrote: > >> >> This is, technically, a compatibility break. On the other hand, there >> appear to be vast numbers of smartphone applications that currently depend >> on undefined

Re: [sqlite] long running INSERT (up to now ~ 11 hours and still working)

On 11 Jan 2011, at 8:00am, Oliver Peters wrote: > I'm on WinXP and using sqlite 3.7.4 with the CLI. I try to insert ~ 10,100,000 > records into a schema with different tables It that takes 11 hours, that means you're taking about 4ms per INSERT. I don't know if this is unusually high. You

Re: [sqlite] Propose minor incompatible API change

On Tue, Jan 11, 2011 at 3:54 AM, Richard Hipp wrote: > > This is, technically, a compatibility break. On the other hand, there > appear to be vast numbers of smartphone applications that currently depend > on undefined behavior and will suddenly stop working if we don't make

[sqlite] long running INSERT (up to now ~ 11 hours and still working)

Hello, I'm on WinXP and using sqlite 3.7.4 with the CLI. I try to insert ~ 10,100,000 records into a schema with different tables (http://pastebin.com/cbsPHNEj). The db file has already 1.9 GB when I start the INSERTs via sqlite3 -bail extra.db3 < inserts.sql The statements in inserts.sql look