[sqlite] problems on importing quoted csv files

Hello, I'm using sqlite to process some csv files. It is very disappointing that sqlite's csv mode doesn't support quoted csv format. I tried spatialite which can only strip quote marks but can't parse it correctly. Is there any suitable modules or tools for importing quoted csv files? Thanks

Re: [sqlite] Compiling in Xcode 3.1.3

On 16 May 2011, at 10:48pm, john darnell wrote: > sourcecode.c > sourcecode.c.c > sourcecode.c.h > sourcecode.c.objc > sourcecode.cpp > sourcecode.cpp.cpp > sourcecode.cpp.h > sourcecode.cpp.objcpp > > The default filetype for SQLite3.c was sourcecode.c.c. The default filetype > for SQLite3.h

Re: [sqlite] DB triggers: Initial patch

A few more comments: - The patch adds just 8KB to libsqlite3.a and the shell, and this is true regardless of whether the before and after compilations use -g or not, -O0 vs. -O2, and -DSQLITE_DEBUG=1 or not. - I've tried to keep the SQLite3 C style as best I could. - My earlier

Re: [sqlite] Compiling in Xcode 3.1.3

Thanks, Simon: In Xcode 3.1.3 when I highlight SQLite3.c, click the Info icon and look under the General Tab, and then click the File Type dropdown there are perhaps sixty to seventy choices I can make, but only a few make any sense, some more than others. They are: sourcecode.c

Re: [sqlite] Compiling in Xcode 3.1.3

On 16 May 2011, at 10:09pm, john darnell wrote: > I highlighted the file, clicked the information icon and then under the > "General" category I changed the type of file from "sourcecode.c.c" to > "sourcecode.c." When pressing Command-K I get no errors but one warning: > "Warning, no rule

Re: [sqlite] Compiling in Xcode 3.1.3

Okay, I started looking at the code in SQLite3 and noticed that this is already done for me. Please have mercy on me, I am on the road and do not have access to my usual resources. What do I need to do to get Xcode to compile this code in 3.1.3? R, John > -Original Message- >

Re: [sqlite] Compiling in Xcode 3.1.3

Thanks again. I highlighted the file, clicked the information icon and then under the "General" category I changed the type of file from "sourcecode.c.c" to "sourcecode.c." When pressing Command-K I get no errors but one warning: "Warning, no rule to process sqlite3.c of type sourcecode.c

Re: [sqlite] Compiling in Xcode 3.1.3

On Mon, May 16, 2011 at 4:31 PM, john darnell wrote: > Thanks for responding, Mr HIpp. > > There are 1265 errors in all, but most of them look very close to something > like this: > >Invalid conversion from void * to XXX * > > Or > >forward declaration

Re: [sqlite] Compiling in Xcode 3.1.3

Thanks for responding, Mr HIpp. There are 1265 errors in all, but most of them look very close to something like this: Invalid conversion from void * to XXX * Or forward declaration of struct_ht I thought it might be a pathing error (I had not added the path to the directory

Re: [sqlite] Compiling in Xcode 3.1.3

On Mon, May 16, 2011 at 4:01 PM, john darnell wrote: > I have code that compiles just fine using Visual Studio 8 on Windows XP, > but when I port SQLite over to a Mac OSX (Snow Leopard) platform using > Xcode 3.1.3 I get roughly 1000 errors based upon SQLite. Is

[sqlite] Compiling in Xcode 3.1.3

I have code that compiles just fine using Visual Studio 8 on Windows XP, but when I port SQLite over to a Mac OSX (Snow Leopard) platform using Xcode 3.1.3 I get roughly 1000 errors based upon SQLite. Is there something I need to turn off/on when using SQLite on the Mac? R, John A.M.

Re: [sqlite] Need to be able to rename attributes

On Mon, May 16, 2011 at 1:29 PM, Simon Slavin wrote: > Yet strangely, the ability to obtain the statements used to create the schema > is something I find very useful in quite a few utilities.  If you could > depend on them being in a standard format they'd be even more

Re: [sqlite] Need to be able to rename attributes

On 16 May 2011, at 7:18pm, Jay A. Kreibich wrote: > I think the bigger issue is that column rename requires full > understanding of the SQL statements stored in sqlite_master. To > safely do a ALTER TABLE...RENAME COLUMN you have to understand the > context and parts of the CREATE TABLE

Re: [sqlite] Need to be able to rename attributes

On Mon, May 16, 2011 at 1:18 PM, Jay A. Kreibich wrote: > On Mon, May 16, 2011 at 12:49:14PM -0500, Nico Williams scratched on the wall: >> Nit: that's almost certainly the reason that SQLite3 doesn't support >> column rename, > >  I think the bigger issue is that column rename

Re: [sqlite] Need to be able to rename attributes

On Mon, May 16, 2011 at 12:49:14PM -0500, Nico Williams scratched on the wall: > On May 16, 2011 9:33 AM, "Simon Slavin" wrote: > > On 16 May 2011, at 3:44am, romtek wrote: > > > > > Secondly, if I executed the above SQL code, what would happen to > triggers, > > > etc. that

Re: [sqlite] DB triggers: Initial patch

And here's the patch. I should have been using Fossil all this time. I'll switch to Fossil soon. For now the patch is to sqlite\-src\-3070602. A few more notes on the patch besides the ones I posted earlier: - DB triggers are omitted by defining SQLITE_OMIT_TRIGGER - DB triggers are

Re: [sqlite] Need to be able to rename attributes

On May 16, 2011 9:33 AM, "Simon Slavin" wrote: > On 16 May 2011, at 3:44am, romtek wrote: > > > Secondly, if I executed the above SQL code, what would happen to triggers, > > etc. that are associated with the original table? > > I suspect that's a major reason why SQLite

Re: [sqlite] time in AM/PM?

On May 15, 2011, at 9:24 PM, Igor Tandetnik wrote: > Mr. Puneet Kishor wrote: >> I am trying to get time stamps to be reported as '10:33 AM' and '1:27 PM' >> instead of '10:33' or '13:27'. I don't see any >> formatting options to return the time in 12-hour format with

[sqlite] DB triggers: Initial patch

In my next post I'll post a [681 line, 28KB unified diff, or 504 line regular diff] patch implements the following DB triggers: - AFTER DATABASE CONNECT - AFTER TRANSACTION BEGIN - BEFORE TRANSACTION COMMIT These triggers do exactly what I want, and nothing more. If anyone wants to test this

[sqlite] two threads in differnet DB handler in the same process accesssing the same DB will cause mutex assert_fail in 3.7.5

Please neglect the previous email. Two threads are in the different DB handler(FD). I have sent the core dump in the previous email. And I found that one thread receives an event and access DB at the same time with another thread accesses the same DB. It happens in the heavy load for DB

Re: [sqlite] two threads in the same process accesssing the same DB will cause mutex assert_fail in 3.7.5

On Mon, May 16, 2011 at 11:59 AM, ChingChang Hsiao < chingchang.hs...@overturenetworks.com> wrote: > I have sent the core dump in the previous email. And I found that one > thread receives an event and access DB at the same time with another thread > accesses the same DB. It happens in the heavy

[sqlite] two threads in the same process accesssing the same DB will cause mutex assert_fail in 3.7.5

I have sent the core dump in the previous email. And I found that one thread receives an event and access DB at the same time with another thread accesses the same DB. It happens in the heavy load for DB access. Is there a way to prevent this core dump? ChingChang Version is 3.7.5 journal

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hi Steven. You're absolutely right. Adding the sources to a real iOS project (standard Xcode 4, View-based iOS app) results in 885 KB. Great to see the linker/stripping process remove all this symbol info. Thanks for the help, -- Tito On May 16, 2011, at 8:49 AM, Steven Parkes wrote: >

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Well, for my part, I forgot that I'm not including the R-tree stuff at this point. I do include FTS (that's why I have a custom build, not to mention the latest WAL stuff.) And to the extent it matters, I'm not using LLVM. But I am building -O0 -ggdb. That doesn't do any inline or deadcode

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hi Richard, On May 16, 2011, at 8:40 AM, Richard Hipp wrote: > I took the amalgamation file (sqlite3.c) and compiled it thusly: > > gcc -Os -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE -c sqlite3.c > > The resulting binary size (as reported by the "size" command) is 392,203 > bytes. That's

Re: [sqlite] unable to open database file - sqlite jdbc

Am 16.05.2011 07:56, schrieb Christoph P.U. Kukulies: > Am 15.05.2011 16:04, schrieb Christoph P.U. Kukulies: >> I keep getting an SQL error >> "unable to open database file" I solved it: The problem is netbeans (7.0 in this case). When I run the application outside netbeans from the DOS prompt

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

On Mon, May 16, 2011 at 11:32 AM, Tito Ciuro wrote: > Hi Steven, > > OK. First of all, I messed up by compiling shell.c (which is included in > the SQLite amalgamated distro.) Removing it brings the size to: > > GCC: > - Debug: 3.1 MB > - Release: 3.4 MB > > LLVM Compiler 2.0: >

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hi Simon, No, I don't need it... but someone else might. I was considering adding FTS3 to my library in case someone needs to search across several text records. Depending on the table size, LIKE or GLOB would be very expensive because doing a full table scan would not be the most optimal

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hi Steven, OK. First of all, I messed up by compiling shell.c (which is included in the SQLite amalgamated distro.) Removing it brings the size to: GCC: - Debug: 3.1 MB - Release: 3.4 MB LLVM Compiler 2.0: - Debug: 3.7 MB - Release: 4 MB This is what I did: 1) Create a new project in Xcode,

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

On 16 mai 2011, at 17:01, Tito Ciuro wrote: > Hello, > > I have a question about SQLite running on iOS. If I'm not mistaken, SQLite on > iOS is not compiled with R*Tree and FTS3. Compiling a static library of > SQLite's amalgamated version weighs at about 4.3 MB, which represents almost >

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

On 16 May 2011, at 4:06pm, Marco Bambini wrote: > 4.3 MB seems really too big... you are probably building a debug version of > the library. Agreed. I don't know what's wrong but nothing should take 4Meg. Also, do you really need FTS3 ? Try a simple search using LIKE or GLOB. With the

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hi Marco, Oops. My bad. Building for Archive (Release version) has a size of 3.6 MB. -- Tito On May 16, 2011, at 8:06 AM, Marco Bambini wrote: > 4.3 MB seems really too big... you are probably building a debug version of > the library. > > -- > Marco Bambini > http://www.sqlabs.com > > >

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

> Compiling a static library of SQLite's amalgamated version weighs at about > 4.3 MB Where are you coming up with this number? My .a is 2792KB and that's with both armv6 and armv7, debugging, and full symbols. I pull in sqlite3, openssl, about a billion other things, and plenty of my own

Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS

4.3 MB seems really too big... you are probably building a debug version of the library. -- Marco Bambini http://www.sqlabs.com On May 16, 2011, at 5:01 PM, Tito Ciuro wrote: > Hello, > > I have a question about SQLite running on iOS. If I'm not mistaken, SQLite on > iOS is not compiled

[sqlite] Using SQLite with R*Tree and FTS3 support in iOS

Hello, I have a question about SQLite running on iOS. If I'm not mistaken, SQLite on iOS is not compiled with R*Tree and FTS3. Compiling a static library of SQLite's amalgamated version weighs at about 4.3 MB, which represents almost 25% of the 20 MB-per-app allowed on the App Store. For many,

Re: [sqlite] Need to be able to rename attributes

On 16 May 2011, at 3:44am, romtek wrote: > Secondly, if I executed the above SQL code, what would happen to triggers, > etc. that are associated with the original table? I suspect that's a major reason why SQLite doesn't support DROP COLUMN: it has to check for things that might depend on the

Re: [sqlite] Insert a structure

On 16 May 2011, at 10:50am, Enrico Thierbach wrote: > From my experience I would recommend you to convert your structure into some > kind text format. JSON, with the excellent and well-performing yajl library, > is usually my favorite choice here. Enrico has a point. JSON is excellent for

Re: [sqlite] Insert a structure

Enrico Thierbach wrote: > From my experience I would recommend you to convert your structure > into some kind text format JSON, with the excellent and well-performing > yajl library, is usually my favorite choice here. Thanks for recommending yajl The yajl-tools package under

Re: [sqlite] IN clause in search query to search a single field containing comma delimited values

On 05/15/2011 09:14 AM, Igor Tandetnik wrote: > Pontiac wrote: >> On 05/13/2011 03:15 PM, Trevor Borgmeier wrote: >>> SELECT categories FROM myTable WHERE (","||categories||",") LIKE "%,7,%"; >> Careful with how you have your like. As an added bonus, if you were to >> hunt

Re: [sqlite] Insert a structure

On 16 May 2011, at 9:51am, StyveA wrote: > I'm working on a code in C, and I would like to insert a structure into a > table as BLOB type. > > Is-it possible to pass it entirely in one time? Or should I insert each > parameters of my structure independently? Assuming that this is straight C,

Re: [sqlite] Insert a structure

Enrico Thierbach-2 wrote: > > From my experience I would recommend you to convert your structure into > some kind text format. JSON, with the excellent and well-performing yajl > library, is usually my favorite choice here. > > /eno > > I didn't know yajl, but I'll have a look at it, it

Re: [sqlite] Insert a structure

>From my experience I would recommend you to convert your structure into some >kind text format. JSON, with the excellent and well-performing yajl library, >is usually my favorite choice here. /eno On 16.05.2011, at 11:39, StyveA wrote: > > > > Enrico Thierbach-2 wrote: >> >> >> On

Re: [sqlite] Insert a structure

Enrico Thierbach-2 wrote: > > > On 16.05.2011, at 11:08, Christoph P.U. Kukulies wrote: > >> Am 16.05.2011 10:51, schrieb StyveA: >>> Hi all, >>> >>> I'm working on a code in C, and I would like to insert a structure into >>> a >>> table as BLOB type. >>> >>> Is-it possible to pass it

Re: [sqlite] Insert a structure

On 16.05.2011, at 11:08, Christoph P.U. Kukulies wrote: > Am 16.05.2011 10:51, schrieb StyveA: >> Hi all, >> >> I'm working on a code in C, and I would like to insert a structure into a >> table as BLOB type. >> >> Is-it possible to pass it entirely in one time? Or should I insert each >>

Re: [sqlite] Insert a structure

Christoph Kukulies wrote: > > Am 16.05.2011 10:51, schrieb StyveA: > A structure in C has a size and a storage address. So technically I see > no reason, why you can't do that. Just copy > the BLOB like you do a memcpy(). > But as soon as you cross architectures (big-endian, little-endian) or

Re: [sqlite] Insert a structure

Am 16.05.2011 10:51, schrieb StyveA: > Hi all, > > I'm working on a code in C, and I would like to insert a structure into a > table as BLOB type. > > Is-it possible to pass it entirely in one time? Or should I insert each > parameters of my structure independently? A structure in C has a size

[sqlite] Insert a structure

Hi all, I'm working on a code in C, and I would like to insert a structure into a table as BLOB type. Is-it possible to pass it entirely in one time? Or should I insert each parameters of my structure independently? Regards, StyveA -- View this message in context: