Re: [sqlite] Unaligned access in SQLite on Itanium
> > Well, it's supported by most compilers today, but I try to avoid > anonymous unions in C code as well. They are fairly standard for C++, > but not for C. But the approach seems fine to me - the alignment will > be forced in this case. > Just to make it clear: can I expect this fix in the next SQLite release? Should I submit a ticket for this? I will provide Linux ia64/x86_64 testing from my side. -- Alexei Alexandrov
Re: [sqlite] How to get the schema
> Is there another way to get the column schema besides parsing the original > CREATE TABLE command? > > thx > -Brett G. > > > This message was sent using IMP, the Internet Messaging Program. Hello Brett You can access the sqlite_master table to get a list of tables. Something like: SELECT name FROM sqlite_master WHERE type='table'; http://www.sqlite.org/cvstrac/wiki?p=InformationSchema For each table then, use PRAGMA table_info(); http://www.sqlite.org/pragma.html#schema There are as well information about indices available. HTH Philipp
Re: [sqlite] How to get the schema
Brett Goodman wrote: Is there another way to get the column schema besides parsing the original CREATE TABLE command? Sure, sqlite3_table_column_metadata, see http://sqlite.org/capi3ref.html#sqlite3_table_column_metadata This routine is used to obtain meta information about a specific column of a specific database table accessible using the connection handle passed as the first function argument. Cheers! -- -Boris http://bpopov.wordpress.com
Re: [sqlite] LIKE and GLOB bug with numbers?
Hello everybody, On 26/03/2006, at 10:08, John Stanton wrote: LIKE and GLOB do a row scan, and give you none of the advantages of an RDBMS. Why not use a flat file and grep and get simplicity and greater speed? I'm very well aware that LIKE and GLOB perform a row scan. I do appreciate your concerns about the presumed lack of suitability of my design, but that is not open for discussion. The original question was related about something very specific: whether there is a bug in LIKE and GLOB when dealing with numbers. Regardless of whether my design is suitable or not, I think it's important to clarify what's happening. Other users might be suffering from this issue without knowing it. Again, thanks for your responses. Regards, -- Tito
[sqlite] How to get the schema
Is there another way to get the column schema besides parsing the original CREATE TABLE command? thx -Brett G. This message was sent using IMP, the Internet Messaging Program.
Re: [sqlite] LIKE and GLOB bug with numbers?
John Stanton wrote: Tito Ciuro wrote: On 26/03/2006, at 10:51, MGC wrote: Your design is fundamentaly wrong. I don't know what your intended use is for this data, but I am logging identical fstat file info along with an MD5 sums. Well... if you don't know what is the intended use for the data, how can you say that my design is fundamentally wrong? :-) It's not wrong. That's the way it has to be. Now, if I could match the data properly with LIKE and GLOB, that would be great. Thanks for your response though. Regards, -- Tito LIKE and GLOB do a row scan, and give you none of the advantages of an RDBMS. Why not use a flat file and grep and get simplicity and greater speed? Or even simply split your CSV attributes array into separate columns? Or at least those values which you need to use in queries if you're resisting doing that? Cheers! -- -Boris http://bpopov.wordpress.com
Re: [sqlite] LIKE and GLOB bug with numbers?
Tito Ciuro wrote: On 26/03/2006, at 10:51, MGC wrote: Your design is fundamentaly wrong. I don't know what your intended use is for this data, but I am logging identical fstat file info along with an MD5 sums. Well... if you don't know what is the intended use for the data, how can you say that my design is fundamentally wrong? :-) It's not wrong. That's the way it has to be. Now, if I could match the data properly with LIKE and GLOB, that would be great. Thanks for your response though. Regards, -- Tito LIKE and GLOB do a row scan, and give you none of the advantages of an RDBMS. Why not use a flat file and grep and get simplicity and greater speed?
Re: [sqlite] Re: How to invert positional argument in ORDER BY
On 3/26/06, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > Nemanja Corlija <[EMAIL PROTECTED]> wrote: > > I have a following query: > > SELECT date FROM chng ORDER BY -date; > > > > Is there a way to use positional argument (hopefully that's the right > > term) instead of column name here? > > Something like this: > > SELECT date FROM chng ORDER BY -1; > > select date, -date from chng order by 2; Not exactly what I was hopping for, but still an acceptable workaround I guess. Thanks Igor. -- Nemanja Corlija <[EMAIL PROTECTED]>
[sqlite] Re: How to invert positional argument in ORDER BY
Nemanja Corlija <[EMAIL PROTECTED]> wrote: I have a following query: SELECT date FROM chng ORDER BY -date; Is there a way to use positional argument (hopefully that's the right term) instead of column name here? Something like this: SELECT date FROM chng ORDER BY -1; select date, -date from chng order by 2; Igor Tandetnik
Re: [sqlite] LIKE and GLOB bug with numbers?
On 26/03/2006, at 10:51, MGC wrote: Your design is fundamentaly wrong. I don't know what your intended use is for this data, but I am logging identical fstat file info along with an MD5 sums. Well... if you don't know what is the intended use for the data, how can you say that my design is fundamentally wrong? :-) It's not wrong. That's the way it has to be. Now, if I could match the data properly with LIKE and GLOB, that would be great. Thanks for your response though. Regards, -- Tito
[sqlite] How to invert positional argument in ORDER BY
I have a following query: SELECT date FROM chng ORDER BY -date; Is there a way to use positional argument (hopefully that's the right term) instead of column name here? Something like this: SELECT date FROM chng ORDER BY -1; This fails with a message "ORDER BY column number -1 out of range - should be between 1 and 1" This is not a big deal obviously since I can "ORDER BY 1 DESC" here. I'm just trying to simplify my code since SQL is generated at runtime. -- Nemanja Corlija <[EMAIL PROTECTED]>
Re: [sqlite] LIKE and GLOB bug with numbers?
There may be an issue, but. Your design is fundamentaly wrong. I don't know what your intended use is for this data, but I am logging identical fstat file info along with an MD5 sums. Each informational element needs to be stored in an individual column. Stuffing all those fields into a single string that needs to be parsed to find ownership or last mod times removes all the benefit from having it in a database in the first place. Stuff it into a sorted flat file. that would be faster and simpler. A database would be 'much better' IMHO but only if it it properly 'normalized'. Mgc ___ Sent with SnapperMail www.snappermail.com .. Original Message ... On Sun, 26 Mar 2006 09:50:31 -0800 "Tito Ciuro" <[EMAIL PROTECTED]> wrote: >Hello, > >I've populated a datafile with 40.176 records which contain file >attributes and file paths. I have two columns, CMKey and CMValues. >The column CMKey contains the path to the file and the column >CMValues contains the attribute values. For example: > >CMKey: Application Support/AbiSuite/AbiWord.Profile > >CMValues: >( > 0, > NSFileTypeRegular, > 1, > 21508, > 0, > staff, > 234881026, > 294022, > 2004-12-16 10:11:35 -0800, > tciuro, > 384, > 2006-03-26 08:35:55 -0800, > 502, > 20 >) > >Both columns are of type TEXT. > >This is what I've found: > >1) SELECT * FROM FinderFiles WHERE CMKey GLOB '*AbiWord.Profile*' >returns 1 match. This is correct. > >2) SELECT * FROM FinderFiles WHERE CMKey LIKE '%ABIWORD.Profile%' >returns 1 match. This is correct. > >3) SELECT * FROM FinderFiles WHERE CMValues GLOB '*2004-12-16 >10:11:35 -0800*' returns 40.176 matches. This is not correct. There >is no way I created these 40.176 file at the *very same* time. Just >to be sure, I looked at one random file (of the 40.176) and I've >obtained the following creation date attribute: > >NSFileCreationDate = 2004-02-21 06:12:43 -0800; > >The same problem occurs if I perform the query: > >SELECT * FROM FinderFiles WHERE CMValues LIKE '%2004-12-16 10:11:35 >-0800%' > >This problem seems to occur when trying to match something with numbers: > >- If I look for NSFilePosixPermissions 448 (which I know exists) I >get zero matches >- If I look for strings, such as in step #1 or #2, it works fine. > >Something is wrong, I just can't figure out why... > >Any ideas? Is this a bug? > >Thanks, > >-- Tito
[sqlite] LIKE and GLOB bug with numbers?
Hello, I've populated a datafile with 40.176 records which contain file attributes and file paths. I have two columns, CMKey and CMValues. The column CMKey contains the path to the file and the column CMValues contains the attribute values. For example: CMKey: Application Support/AbiSuite/AbiWord.Profile CMValues: ( 0, NSFileTypeRegular, 1, 21508, 0, staff, 234881026, 294022, 2004-12-16 10:11:35 -0800, tciuro, 384, 2006-03-26 08:35:55 -0800, 502, 20 ) Both columns are of type TEXT. This is what I've found: 1) SELECT * FROM FinderFiles WHERE CMKey GLOB '*AbiWord.Profile*' returns 1 match. This is correct. 2) SELECT * FROM FinderFiles WHERE CMKey LIKE '%ABIWORD.Profile%' returns 1 match. This is correct. 3) SELECT * FROM FinderFiles WHERE CMValues GLOB '*2004-12-16 10:11:35 -0800*' returns 40.176 matches. This is not correct. There is no way I created these 40.176 file at the *very same* time. Just to be sure, I looked at one random file (of the 40.176) and I've obtained the following creation date attribute: NSFileCreationDate = 2004-02-21 06:12:43 -0800; The same problem occurs if I perform the query: SELECT * FROM FinderFiles WHERE CMValues LIKE '%2004-12-16 10:11:35 -0800%' This problem seems to occur when trying to match something with numbers: - If I look for NSFilePosixPermissions 448 (which I know exists) I get zero matches - If I look for strings, such as in step #1 or #2, it works fine. Something is wrong, I just can't figure out why... Any ideas? Is this a bug? Thanks, -- Tito
