[sqlite] PRAGMA user_version;
If I have never set the user_version will the value always be 0? I plan to start using user_version in my app, I will need to set this value to a approprate value if it has not yet been set, and i am just double checking that it is always 0 untill i set it. Anybody have a better way to hold onto a revision of the database? --Preston
[sqlite] sqlite error after upgrade to 3.3.5
Hi all, I recently upgraded my project from 3.2.2 to 3.3.5 (or if you look at my last post 3.4.5 ;) and have found a situation where sqlite tries to access an invalid memory location in file vdbe.c line 3633 (pC==0). I have confirmed that this query causes the command line utility (pre-compiled for windows from the website) to crash as well. The database passes an integrity check, furthermore i can dump the database re-created it and the query still fails. Not all values for i cause the error. The query works in 3.2.2 for all i values passed in. --here is the query, note it doesn't actually return any rows. select ac1, ac2 from ac where (ac1 in (select ac from aci where i=2475) and ac2 in (select ac from aci where i=2051)) union select ac2 ac1, ac1 ac2 from ac where (ac2 in (select ac from aci where i=2475) and ac1 in (select ac from aci where i=2051)); --here is the structure that can be used to reproduce this error... trying to get the smallest set of data that will produce the error i found out that the error will occur with or with out data in the tables... CREATE TABLE ac( ac1intNOT NULL, ac2intNOT NULL ); CREATE UNIQUE INDEX PKAC ON ac(ac1, ac2); CREATE TABLE aci( acintNOT NULL, i intNOT NULL ); CREATE UNIQUE INDEX PKACI ON ACI(ac, i); Any help would be appreciated. --Preston
Re: [sqlite] Possible bug with non-standard characters in column names
if your first statement after creating the database is: PRAGMA encoding = UTF-16; then the error you get is slightly different: sqlite ALTER TABLE test1 ADD straße VARCHAR(255); SQL error: malformed database schema - near (: syntax error I was hoping that would fix it for you.. guess not, but at least you know of the potential error sooner rather than later...tried the column name in quotes too.. didn't help. --preston On 5/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Not sure- I've tried this through JDBC and the command line client, I'm not a developer at that level :( Thanks, Andreas -Original Message- From: Clay Dowling [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 10. Mai 2006 18:42 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Possible bug with non-standard characters in column names [EMAIL PROTECTED] said: CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status VARCHAR(255)); ALTER TABLE test1 ADD name VARCHAR(255); ALTER TABLE test1 ADD straße VARCHAR(255); ALTER TABLE test1 ADD plz VARCHAR(255); Raises an SQL error: malformed database schema - near plz: syntax error The suspected bug is that the ALTER TABLE that adds straße should raise the error, not the following statement? I'm guessing that straße was indeed what ticked off the engine, but it took until plz for the parser to realize the problem. Have you tried using the 16 bit character functions instead? The 8 bit functions could be choking on the essen. Clay Dowling -- Simple Content Management http://www.ceamus.com This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: [sqlite] Encryption
typo... sorry for the confusion, i'll be more careful in the future.. On 5/11/06, Edwin Hernán Barrios Núñez [EMAIL PROTECTED] wrote: Hi , When i can download that sqlite version you take about, with encryption extension. I saw in your message that you use version 3.4.5 but on sqlte.org the last one is 3.3.5. What is the diference ? , where i can download encryption ( that it's a need funcionality for sqlite ) Thanks !!! On 5/10/06, Preston Chrystie [EMAIL PROTECTED] wrote: I'm having trouble compiling the 3.4.5 version with encryption extensions.. I have done it a hundred times before, but i just switched to a new computer and don't know what stupid mistake i am making... (NOTE: *.c is everything in the zip file with the addition of crypto3.c and exclusion of tclsqlite.c) gcc -DSQLITE_HAS_CODEC=1 *.c -o sqlite3.4.5.exe the exe is built, but i can't open an encrypted database and .rekey command gives me the following: 'unknown command or invalid arguments: rekey. Enter .help for help' So what am i doing wrong? thanks, Preston
[sqlite] Encryption
I'm having trouble compiling the 3.4.5 version with encryption extensions.. I have done it a hundred times before, but i just switched to a new computer and don't know what stupid mistake i am making... (NOTE: *.c is everything in the zip file with the addition of crypto3.c and exclusion of tclsqlite.c) gcc -DSQLITE_HAS_CODEC=1 *.c -o sqlite3.4.5.exe the exe is built, but i can't open an encrypted database and .rekey command gives me the following: 'unknown command or invalid arguments: rekey. Enter .help for help' So what am i doing wrong? thanks, Preston
[sqlite] column name inconsistency...
I know there was a lot of talk about columns names a while back and i don't want to start it all up again, but i have noticed some things in the 3.2.2 release that seem a little odd to me. if i write a query as follows: select a.id, b.stuff from a inner join b on a.id=b.id; The column names come back as i expected they would: id, stuff. If however, i create the following view: create view aview as select a.id, b.stuff from a inner join b on a.id=b.id; The column names don't come back as i expected they would instead they are: a.id, b.stuff. I would have expected that to return the same thing as the query. Obviously not a big deal to work around.. but thought it was odd. The same sort of thing happens on an in-line view or subselect. Take the fictitious example below: select a.id, tmpb.stuff from a inner join ( select b.id, b.stuff from b ) as tmpb on tmpb.id=a.id; The work-around for this is of course to explicitly alias your columns to the names you were expecting, but it is probably worth changeing if only to make it more intuitive and consistent. thanks --preston
