Re: [sqlite] Deep copy of 2 sqlite3*?

On 08/03/2011 09:20 AM, Nikki Tan wrote: > Hi sqlite-users! > It's just that I'm writing a copy constructor of my own mini sqlite > wrapper, and I ended up having to do a deep copy of a sqlite3* points to a > SQLite connection. And I'm just wondering is it okay that I just do it with >

[sqlite] Case Insensitive String comparison

Hi All, I have a SELECT query with WHERE-IN clause (string values are present in the where-in clause) I need this query to be case insensitive. I checked with simply WHERE clause and in it, the query can be made case-insensitive by adding COLLATE NOCASE, but this does not seem to work with

[sqlite] Deep copy of 2 sqlite3*?

Hi sqlite-users! It's just that I'm writing a copy constructor of my own mini sqlite wrapper, and I ended up having to do a deep copy of a sqlite3* points to a SQLite connection. And I'm just wondering is it okay that I just do it with memcpy(), by digging into the code for the definition of

Re: [sqlite] Field drop work around

I just noticed that this is a FAQ: Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] float value increased as a text field

On 2 Aug 2011, at 5:52pm, Mathias Legerer wrote: > Thank you for clarification. If you need numbers accurate to the 1, use integers. Thats what they're for. Business applications for big businesses don't store money as floating point, they store it as integers. You get more than 17 decimal

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:41:55 +, Black, Michael (IS) wrote: > Since SQLite is type agnostic Actually no, it's not. The optimizer usually does much better job if the types are declared (I've seen many cases where it failed to use index when some column was untyped). Plus there are unique

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:03:52PM +0100, Jack Hughes scratched on the wall: > Hello all, > > Is there a workaround for the lack of support for dropping fields? While this doesn't solve your immediate problem, I'm wondering if it might be possible to add code that simple marks a column

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:03:52 +0100, Jack Hughes wrote: > Any ideas how I can remove unused fields from the database would be > appreciated. I'd consider creating the new database from scratch and importing the data from the old one (by attaching it and doing insert ... select). That way

Re: [sqlite] float value increased as a text field

Hi Richard, Thank you for clarification. And yes, you are right with the guess, that the customer wants to preserve that much digits ;) br, Mathias 2011/8/2 Richard Hipp : > On Tue, Aug 2, 2011 at 12:18 PM, Mathias Legerer > wrote: > >> Hi, >> I noticed

Re: [sqlite] Field drop work around

On Tue, Aug 02, 2011 at 12:41:55PM +, Black, Michael (IS) scratched on the wall: > Since SQLite is type agnostic why don't you use generic field names? Table definitions consist of a lot more than just column names and types. Defining keys and other constraints are an integral part of

Re: [sqlite] float value increased as a text field

On Tue, Aug 2, 2011 at 12:18 PM, Mathias Legerer wrote: > Hi, > I noticed a strange behaviour, when i have a table with a text-field > and i put a big float-number into it. > When stored, it is increased by one. > Floating-point numbers are approximations. Always. No

[sqlite] float value increased as a text field

Hi, I noticed a strange behaviour, when i have a table with a text-field and i put a big float-number into it. When stored, it is increased by one. create table TEST (ordnr int primary key, ktoid TEXT); insert into TEST (ordnr, ktoid) values(0, 99104499464.0); SELECT ordnr, ktoid FROM TEST;

Re: [sqlite] Field drop work around

On 02/08/2011, at 9:03 PM, Jack Hughes wrote: > Is there a workaround for the lack of support for dropping fields? As others have said, you can create a new table and insert data from the old to new table. Remember to also recreate any needed triggers and indexes. For example, I get my SQLite

Re: [sqlite] 32-bit to 64-bit on Snow Leopard

Ya the Lasso bit is about their own admin and session management anyway, so that's fine. Not worried, as I can get it back to original. I keep accounts minimal as I'm running off an SSD which has limited space. Thanks again. Cheers _ Rich in Toronto On 2011-08-02, at 9:05

Re: [sqlite] 32-bit to 64-bit on Snow Leopard

On 2 Aug 2011, at 1:52pm, Viaduct Productions wrote: > ya 3 it is. A package installed the 32 bit version, and now I have to > install the 64 bit version, and I'm worried it might do irreparable things to > my current tables. I'm thinking tables are independent of the binaries, so > I'm

Re: [sqlite] Field drop work around

I don't think NHibernate would allow me do do that... even if it did it would be difficult to understand. Things are hard enough to understand when I name the fields as per their intention never mind when there would be a level of indirection above it. >Since SQLite is type agnostic why don't

Re: [sqlite] 32-bit to 64-bit on Snow Leopard

Hi Simon Thanks for the reply. ya 3 it is. A package installed the 32 bit version, and now I have to install the 64 bit version, and I'm worried it might do irreparable things to my current tables. I'm thinking tables are independent of the binaries, so I'm good, but I wanted to check.

Re: [sqlite] Field drop work around

Since SQLite is type agnostic why don't you use generic field names? Just name your fields 0-NN and keep a set of defines for field names. Then you just use #define to name the fields. create table mytable (field1,field2,field3,field4); #define NAME "field1" #define ADDR "field2"

Re: [sqlite] Field drop work around

On Tue, Aug 2, 2011 at 1:13 PM, Simon Slavin wrote: > copy your data across using INSERT INTO myTable SELECT a,b,c,d FROM > myOldTable > DROP the old TABLE > or, similarly: CREATE TABLE myTable AS SELECT ... FROM myOldTable; Though there might be subtle differences

Re: [sqlite] Field drop work around

Thank you for your response Simon + Teg. The absence of the full ALTER table support turns something that would have been as simple as writing "Delete.Column("ColumnName").FromTable("TableName");" in c# using the fluent migrator project into something that is far from simple and probably quite

[sqlite] Wal index file size

Hello, Is there a relation between the wal index file size and the wal log file ? How does sqlite allocate the max size for the index file. Could figure out scanning thru the source code. However, if someone has already figured out, please share. Sent from BlackBerry® on Airtel

Re: [sqlite] Where to put the SLITE_OMIT_* options?

On Tue, Aug 2, 2011 at 4:54 AM, Baruch Burstein wrote: > I am trying to edit the makefile, as mentioned here > http://www.sqlite.org/compile.html#omitfeatures. I am unclear as to where > these options should go in the makefile, as these are not strictly compile > options, as

Re: [sqlite] Sqlite3_step problem

On Tue, Aug 2, 2011 at 12:49 PM, Prasanth R Kosigi Shroff < prasanth@globaledgesoft.com> wrote: > i am trying to run a compiled query and i am passing it through > sqlite3_step API the return value is SQLITE_DONE. But the same query > works fine when i execute the same query using command

Re: [sqlite] Field drop work around

Hello Jack, I just migrate the tables forward. Generate a new one in my program and do a bulk insert from the old to the new, then drop the old one. At other times, I've just re-purposed the unused field. C Tuesday, August 2, 2011, 7:03:52 AM, you wrote: JH> Hello all, JH> Is there a

Re: [sqlite] Field drop work around

On 2 Aug 2011, at 12:03pm, Jack Hughes wrote: > Is there a workaround for the lack of support for dropping fields? I have an > application and need to evolve the database schema as features are added and > removed. Leaving fields sitting inside the database that are no longer used > will lead

[sqlite] Sqlite3_step problem

hi i am trying to run a compiled query and i am passing it through sqlite3_step API the return value is SQLITE_DONE. But the same query works fine when i execute the same query using command line tool. #sqlite3 tmp.db SQLite version 3.4.2 Enter ".help" for instructions sqlite>select name from

[sqlite] Field drop work around

Hello all, Is there a workaround for the lack of support for dropping fields? I have an application and need to evolve the database schema as features are added and removed. Leaving fields sitting inside the database that are no longer used will lead to a schema that is difficult to

Re: [sqlite] Virtual Table xBestIndex and NULL Search Conditions (Bug!)

On 2 Aug 2011, at 9:06am, Igor Sereda wrote: > Thanks, Simon - it's a bug then. Hope it will get pulled into the bug > tracker. > Simon Slavin-3 wrote: > >> The spec for '<=' should say that comparing any number with NULL always >> gives a NULL result. If SQLite is doing anything apart from

Re: [sqlite] 32-bit to 64-bit on Snow Leopard

On 2 Aug 2011, at 6:09am, Viaduct Productions wrote: > Just wondering if the tables will remain if I configure SQLite to install the > 64 bit version on Snow Leopard over my current 32 bit version. As long as you stay with SQLite3, not SQLite2, The format of the files is completely

[sqlite] Where to put the SLITE_OMIT_* options?

I am trying to edit the makefile, as mentioned here http://www.sqlite.org/compile.html#omitfeatures. I am unclear as to where these options should go in the makefile, as these are not strictly compile options, as no compiling is done (the end result is a source file). Where would I put them?

Re: [sqlite] Virtual Table xBestIndex and NULL Search Conditions (Bug!)

Thanks, Simon - it's a bug then. Hope it will get pulled into the bug tracker. Igor Simon Slavin-3 wrote: > > > On 2 Aug 2011, at 1:10am, Igor Sereda wrote: > >> To my humble knowledge, operations with NULL have well-defined semantics, >> both in SQL-you-name-it standards and in SQLite. "A

Re: [sqlite] Will SQLite supports UnQL?

2011/8/2 Eric Scouten : > It falls apart badly in a highly distributed environment where ... > > ... May be a RDF storage is more reasonable for this. Operations with atomic facts can be highly distributed. And SPARQL is similar to SQL. -- Best regards, Alexey Pechnikov.

Re: [sqlite] SQLite and Java

Yin, A Google search of "sqlite java api" gives several good hits. Click on the first http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers and scroll down to Java Martin Am 02.08.2011 06:01, schrieb yinlijie2011: > Dear, > I want use SQLite, but my program language is Java. And >