[sqlite] cygwin c problem
Ok I had no problem compiling the program, and the test program it creates works fine.. but I can't seem to get the libraries to function.. I've tried moving them to various directories, but have accomplished nothing of great substance. The closest I come is having it successfully include sqlite.h but not load the library. I've never had this problem before when installing libraries, but I think their processes have been more automated or perhaps I'm simply being dense. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [sqlite] SQLite for Win32 TCHAR
=== On 2004-03-19, Will Leshner wrote === >On Mar 19, 2004, at 7:18 AM, Nuno Lucas wrote: > >> What I believe is in separation of the os.c file for the diferent >> platforms supported. >> A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) >> separation will make the code for each port more readable and easy to >> set new ports (for example, ifdefing the incompatible code in os_win.c >> and adding a os_wince.c). > >Yes, I think this is a great idea. > hehe, let's lobby for it ;-) ~Nuno Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
=== On 2004-03-20, sword wrote === .. >So, what you want to do basically falls in maintaining ports, but >internally in SQLite codebase, isn't it? If I understood you correctly, yes. I just replyed to correct a litle misconception about the Windows CE port. I agree with you on patching sqlite to work under the Unicode environment (a very quick fix). About adding a Unicode API to sqlite, I don't, for now (until sqlite works with it natively). The reason is that as sqlite would convert to UTF8 anyway, it would not add nothing except maybe confusing the developer of why his database access was slower than his coleage (using the Ansi version). If you want this Wide API, is easy enough to make it yourself (as you probably have done, already). What could be missing in here is a contrib page where this kind of stuff could be exposed for all (it could be a wiki page, also). In this case, a .h/.c pair of files would do the trick, maybe titled wsqlite.h/.c. Another pair tsqlite.h/.c would expose the Win32 generic types interface. Regards, ~Nuno Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQLite 3.0...when???
> I have been using SQLite for over a year now and it is an excellent SQL
> Library. Some more features from SQL92 would surely be welcome
> while keeping
> SQLite fast and small. Suggestions for ver 3.0 include:
>
> - Full referential integrity by implement check and foreign key
> constraints
> - multi-row value inserts just like MySQL (..copied the REPLACE from
> MySQL..so copy INSERT as well)
> - control-of-flow language such as IF-THEN-ELSE, BEGIN..END, WHILE,
> PRINT, RAISERROR, etc
> - use of local variables e.g. DECLARE @varName dataType
> - system global variables e.g. @@error, @@identity
> - stored procedures: if triggers can be implemented then so can
> stored procs
> - add alter TABLE, VIEW and TRIGGER
> - CREATE, ALTER and DROP DATABASE: if we can attach and detach, we
> should also be able to create
> and delete them through DDL statements
>
> I will be lucky if any of these would/could or should be
> implemented but if
> most were then even for embedded applications,
> being able to do almost all data manipulation using SQL statements only,
> would be a great improvement...
>
> B.Thomas
The likelihood of any of this being implemented varies in direct proportion
to how much of it you're willing to work on. Start something and people will
likely turn up to help. Ask for something and you're at the mercy of other
people's whims.
Incidentally, all these are good suggestions. ;-)
I'd love to see something along these lines (not SQL standard though AFAIK):
'PROCEDURE' 'LANGUAGE' '='
'('')''{' '}'
Dave LeBlanc
Seattle, WA USA
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] SQLite 3.0...when???
I have been using SQLite for over a year now and it is an excellent SQL Library. Some more features from SQL92 would surely be welcome while keeping SQLite fast and small. Suggestions for ver 3.0 include: - Full referential integrity by implement check and foreign key constraints - multi-row value inserts just like MySQL (..copied the REPLACE from MySQL..so copy INSERT as well) - control-of-flow language such as IF-THEN-ELSE, BEGIN..END, WHILE, PRINT, RAISERROR, etc - use of local variables e.g. DECLARE @varName dataType - system global variables e.g. @@error, @@identity - stored procedures: if triggers can be implemented then so can stored procs - add alter TABLE, VIEW and TRIGGER - CREATE, ALTER and DROP DATABASE: if we can attach and detach, we should also be able to create and delete them through DDL statements I will be lucky if any of these would/could or should be implemented but if most were then even for embedded applications, being able to do almost all data manipulation using SQL statements only, would be a great improvement... B.Thomas This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
Re: [sqlite] a few questions about indexes
eno wrote: [EMAIL PROTECTED] wrote: ok. As I am sure you realize it would be very useful to be able to create case-insensitive indexes with: create index idx_my_index on my_table(lower(my_column)); How can you be sure which index sqlite will use when there are more indices on a field? SELECT * FROM my_table WHERE lower(my_column) < "cd" but I wonder if such a thing could be done with triggers. /eno Excuse me for the late reaction, I tried what you suggested, but in a certain project I am bound to SQLite 2.7.3, maybe it has changed. When I try your solution, the index as suggested is not used, instead a tablescan is done and the lower is called as a function. Maybe your suggestion works in younger versions of SQLite, I don't know. Kind regards Bert Verhees - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] moving from mySQL to SQLite - A guidance request
At 9:47 AM -0600 3/19/04, Fred Williams wrote: You have raised some vaild concerns for sure. But, the rest of the known SQL database universe (Oracle, SQL Server, MySQL, Advantage, Access(?), and etc.) does it the other way round. The only reason I prefer the change is to allow for greater cross platform migration. If there are those who obviously have a great deal invested in the current implementation, then something like a sticky PRAGMA would be a very good solution. This would allow the existing code base be protected, but future migration to be more "industry standard." In the old IBM days the "c.foo" would require a "gray area" in the manual:-) If the main issue at hand is cross-database compatability, then there is a good method that already exists as defined by the SQL standards - "AS". If one were to use that for every returned column in the select list then you would have the same result using this on any SQL database. Moreover, using AS all the time allows a type of uniformity on selects that contain arbitrary expressions in the select list, which typically use AS anyway. And for people such as myself who are inclined to generate our SQL from a data dictionary, making it generate AS all the time is trivial. Those are some thoughts. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQL engine on our file formats
> -Original Message- > From: Jean-Eric Cuendet [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 8:07 AM > To: [EMAIL PROTECTED] > Subject: [sqlite] SQL engine on our file formats > > > Hi, > We have our own files containing data for our automatic > testing line. We > would be interested to serve these informations through SQL. One idea > would be to put them in an SQL database but we would like to > stick with > our text only files: easy to manage, to edit, to version. If you are wedded to the text files, then the only options I can see are: 1) Re-import the text files into an sqlite database (in the background) when ever the times stamps of the text files have changed - a poor mans replication, its not really a good idea if the data set is large. 2) Don't use sqlite, use something else. Options off the top of my head: shsql - http://midriff.sourceforge.net/sqlman/html/Contents.html Perl DBI modules that can use text files via SQL (there is at least on CSV based one) ODBC driver similar to perl DBI modules that access text files via SQL interface (I've not seen any ODBC drivers that do this under Linux, I've only seen these under win32). JDBC of the same form. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
On Fri, 19 Mar 2004 15:18:50 + "Nuno Lucas" <[EMAIL PROTECTED]> wrote: > I don't think there is the need to go so far. What I believe is in separation > of the os.c file for the diferent platforms supported. > A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will >make the code for each port more readable and easy to set new ports > (for example, ifdefing the incompatible code in os_win.c and adding a os_wince.c). > When compiling for windows, the os_mac.c and os_unix.c would simply be >ifdefed out, like when using SQLITE_OMIT_AUTHORIZATION and the auth.c file. > I didn't do this to the WinCE port because I think a port should be the closest >possible to the original, including the design, making it very simple >to use a program like WinMerge to update the sources to a new version. >For WinCE I had to also to implement atof() (for some WinCE versions), and >having it on a separate os_wince.c file would make the code cleaner. So, what you want to do basically falls in maintaining ports, but internally in SQLite codebase, isn't it? Actually, I don't care specific breed of Windows, but only have concern on the aspect (you can associate it with aspect-oriented programming) that they have same characteristics in necessary interfaces (ANSI/wide). Therefore I thought it would be advantage for SQLite to extract and abstract this aspect, ANSI/wide, to adapt it to unknown future platforms. If you only care about problems of short-range, just port and let it go, but I believe it won't produce maintainable and reusable code. My own usage model of SQLite is, I incorporate SQLite as source code in my C++ codebase of an application with UNICODE defined. Since UNICODE is defined all over SQLite code, to match Windows API and SQLite const char* zFilename interface and make it pass through the compiler, I have to modify os.c to add 'A' postfix to all file-handling APIs. Because I only use source code of SQLite, I can agree with your somewhat light-weight solution. However, SQLite is provided in binary .dll form, too. For users of .dll, only one dll for all Windows and unchanged interfaces would be some kind of merit, at least I'd thought so looking sqlite.org for years. I would like to hear the opinion of the designer himself on this point. If you assume ANSI/wide version APIs coexistence in SQLite is too fat and takes in a few unwanted kilobytes of code memory which is too big in embeded platform, then there should be a macro like LEAN_FILE_API or something to remove unwanted part from resulted binary, but it is only for Windows Embedded developers, not for mainstream desktop/server Windows developers. -- KL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] SQL engine on our file formats
Hi, We have our own files containing data for our automatic testing line. We would be interested to serve these informations through SQL. One idea would be to put them in an SQL database but we would like to stick with our text only files: easy to manage, to edit, to version. Would SQLite be easy to customize to serve those files instead of the SQLite files? Of cours, only SELECT must be implemented, so only a SQL parser and the SELECT handler are requested. All other SQL commands can be ignored. Do you think that SQLite would do it? Thanks. -jec -- Jean-Eric Cuendet Riskpro Technologies SA Av du 14 avril 1b, 1020 Renens Switzerland Principal: +41 21 637 0110 Fax: +41 21 637 01 11 Direct: +41 21 637 0123 E-mail: jean-eric.cuendet at rptec.ch http://www.rptec.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] moving from mySQL to SQLite - A guidance request
> -Original Message- > From: Darren Duncan [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 12:39 AM > To: SQLite > Subject: RE: [sqlite] moving from mySQL to SQLite - A guidance request > > > On Fri, 19 Mar 2004, Fred Williams wrote: > > Yes, about that c.firstname thing... > > > > Do we need to turn in some kind'a formal "enhancement request?" > Seems the > > feeling of those responding was that a configurable option was > most desired. > > Perhaps a PRAGMA? > > > > So Richard, in all your spare time, what'd y'a think? > > I would say that if this were implemented then is should indeed be PRAGMA > triggered and not be the default option. A default of "leave it the way > you found it" as is done now seems best for a default. It's certainly > more descriptive. The "AS" directive in SQL for explicit renaming seems > the best way to rename for serious work. > > Also, an auto-rename as was asked for could have a side-effect of losing > retrieved data in some cases. For example, see the following: > > SELECT a.foo, b.foo ... > > If the "a." and "b." were stripped off, we would have two > returned columns > with identical names. Any application which actually references the > returned data by name and not by column number would only be able to see > one of them. And if the application layer puts a row in an associative > array (a "hash" in Perl talk) of field name/value, then only one column > value would be stored and the other lost. > > So you can see how the requested new behaviour would only be useful in > specialized cases and isn't good for a default. > > On the other hand, a good way around this problem is that the SQL parser > will throw an error when said behaviour is used, in situations where > the SQL writer does what I demonstrated, citing the fact that > multiple same-named return value columns aren't allowed, requiring the > application writer to use "AS" at least once to get around the error. You have raised some vaild concerns for sure. But, the rest of the known SQL database universe (Oracle, SQL Server, MySQL, Advantage, Access(?), and etc.) does it the other way round. The only reason I prefer the change is to allow for greater cross platform migration. If there are those who obviously have a great deal invested in the current implementation, then something like a sticky PRAGMA would be a very good solution. This would allow the existing code base be protected, but future migration to be more "industry standard." In the old IBM days the "c.foo" would require a "gray area" in the manual:-) We all hope, as users and developers, that SQLite will continue to evolve and gain acceptance, but realistically I don't see Oracle et all coming around to SQLite's way of thinking on this one! Fred - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] OT: bush misquote (was Re: [sqlite] more performance questions)
Hey guys (and gals) let's not turn this into "SQLite politics" I can read that kind of [EMAIL PROTECTED]@ S#$#$ millions of other places on the net :-( Fred Joe Bob Briggs for President committee member. > -Original Message- > From: Christian Smith [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 6:22 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [sqlite] OT: bush misquote (was Re: [sqlite] more > performance questions) > > > On Thu, 18 Mar 2004 [EMAIL PROTECTED] wrote: > > >On Mar 18, 2004, at 11:28 AM, David Morel wrote: > > > >> Le jeu 18/03/2004 à 15:42, Christian Smith a écrit : > >> | "The problem with the French is that they don't have a word for > >> entrepreneur" > >> | George W. Bush > >> > >> did the man realy SAY that? > > > >Nah: > > > > http://www.snopes.com/quotes/bush.htm > > > >It's a variation on the old joke where Reagan says he doesn't trust the > >Russians because they don't have a word for detente.. > > What I find worrying is that it was Alastair Campbell who denied that the > quote is true. If you believe HIM, then you'll believe any old wive's tale > (Iraq dossier, anyone?) It smacks of political cover up to me, helping > Bush save face. > > Still, in light of this new 'evidence', I shall search for a new quote. > > :) > > > > >-D > > > > Christian > > -- > "The problem with the French is that they don't have a word for > entrepreneur" > George W. Bush (Allegedly, being investigated:) > > -- > /"\ > \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL > X - AGAINST MS ATTACHMENTS > / \ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] some optimisation help?
Do you have the tables in the FROM listed in descending order of size?
> -Original Message-
> From: Jake Skinner [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 19, 2004 1:40 AM
> To: [EMAIL PROTECTED]
> Subject: [sqlite] some optimisation help?
>
>
> The following query is very slow. I don't know how to improve my query,
> and I'm sure I'm doing this just about the slowest way possible!! :(
>
> begin sql query
> ==
> select t1.time, t1.units_processed,
> round((t1.units_processed+t2.units_processed+t3.units_processed+t4
> .units_processed)/4)
> as ave
> from location_stats as t1,
> location_stats as t2,
> location_stats as t3,
> location_stats as t4
> where t1.time=t2.time
> and t3.time=t4.time
> and t4.time=t2.time
> and t1.date=date("2004-02-24",'-7 days')
> and t2.date=date("2004-02-24",'-14 days')
> and t3.date=date("2004-02-24",'-28 days')
> and t4.date=date("2004-02-24",'-35 days')
> ===
> end sql query
>
> If anyone has any sort of suggestions I would be very greatful...
>
> cheers
> Jake
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
On Mar 19, 2004, at 7:18 AM, Nuno Lucas wrote: What I believe is in separation of the os.c file for the diferent platforms supported. A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will make the code for each port more readable and easy to set new ports (for example, ifdefing the incompatible code in os_win.c and adding a os_wince.c). Yes, I think this is a great idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
plz see below...
=== On 2004-03-19, sword wrote ===
>On Thu, 18 Mar 2004 16:01:39 -0500
>"Clark, Chris" <[EMAIL PROTECTED]> wrote:
>> > -Original Message-
>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> > Sent: Tuesday, March 16, 2004 11:58 PM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: [sqlite] SQLite for Win32 TCHAR
>> >
>> >
>> > So finally Ticket 239 http://www.sqlite.org/cvstrac/tktview?tn=239,2
>> > will be fixed soon, after 1 year the ticket was submit? (by adding 'A'
>> > to all file handling API in OS_WIN)
>>
>> If you do that you break the WinCE port. WinCE only has the wide versions (but we
>>have char and wide char). That's why the previuos posts have mentioned
>>mbstowcs()/wcstombs().
>>
>> Chris
No, the WinCE port will not be broken. It is a separate project and not using the same
code for windows, so a merge with the windows sources of sqlite (what I do for each
new version) will not break WinCE. Probably one or two fixes will be implied, but
nothing serious.
>OK, WinCE doesn't have CreateFileA symbol in its binary from the
>beginning.
>
>There will be 2 different scenarios for SQLite to adapt itself
>to Windows overall.
>
>1) Separate OS_WIN to OS_WINNT, OS_WIN9X, OS_WINCE, and
>maintain different SQLite binaries for them as ports.
I don't think there is the need to go so far. What I believe is in separation of the
os.c file for the diferent platforms supported.
A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will make
the code for each port more readable and easy to set new ports (for example, ifdefing
the incompatible code in os_win.c and adding a os_wince.c).
When compiling for windows, the os_mac.c and os_unix.c would simply be ifdefed out,
like when using SQLITE_OMIT_AUTHORIZATION and the auth.c file.
I didn't do this to the WinCE port because I think a port should be the closest
possible to the original, including the design, making it very simple to use a program
like WinMerge to update the sources to a new version.
For WinCE I had to also to implement atof() (for some WinCE versions), and having it
on a separate os_wince.c file would make the code cleaner.
>2) Put ASCII/wide version of those APIs side-by-side in os.c
>of SQLite, like sqliteOsOpenReadWriteA and
>sqliteOsOpenReadWriteW, and add user interfaces as sqlite_openA
>and sqlite_openW, then put CreateFileA and CreateFileW (CreateFileW,
>not CreateFile, is present as a symbol in WinCE binary as listed in
>http://www.xs4all.nl/~itsme/projects/xda/wince-systemcalls.html,
>right? ) in each versions, just like WindowsNT itself does. This way
>is what I suggested in the last paragraph of Ticket 239 comment of
>1 year before.
>
>http://www.sqlite.org/cvstrac/tktview?tn=239,2
I don't see the need for this. It will just complicate the code with litle value (not
the ticket, offcourse).
I will not detail myself here, as I think you were not well informed about the WinCE
port (I think I informed you now).
I wanted to see the ticket better, but it seems the tracker is down at the moment
(Richard ?).
If this helps, here is the error (http://www.sqlite.org/cvstrac/timeline):
-
Query failed
Database query failed:
REPLACE INTO access_load(ipaddr,load,lastaccess)
VALUES('213.205.69.139',1,1079709118)
Reason: attempt to write a readonly database
--
Well, regards,
~Nuno Lucas
>
>"Another way is, add to SQLite its own ANSI/Unicode(UCS-2) version
>APIs as Windows does, in Windows SQLite build. For example "open" is
>translated in sqlite.h to openA/openW which exists in dll. Fortunately
>SQLite has os.c as abstraction filter for its body, several changes in
>os.c will be sufficient."
>
>For sqlite.h,
>
>#ifdef UNICODE
>#define sqlite_open sqlite_openW
>#else
>#define sqlite_open sqlite_openA
>#endif
>
>this translation is sufficient, as you won't remove UNICODE symbol
>in Windows Embedded development.
>
>Win95 has CreateFileA (if you have installed Microsoft Unicode Layer
>to Win9X it also has CreateFileW), WinNT has both CreateFileA and
>CreateFileW, and WinCE has only CreateFileW. In current SQLite dll
>binary at http://www.hwaci.com/sw/sqlite/sqlitedll.zip contains only
>CreateFileA symbol as you can see it with Dependency Walker.
>
>Performance-wise for WinNT, when it takes CreateFileA it internally
>translates ASCII arguments to wide and passes it to CreateFileW, so
>it's recommended that you use Unicode filenames consistently in
>WinNT platforms.
>
>By the way, please don't confuse the argument above with TCHAR
>support all over SQLite, because SQLite won't support UTF-16 until
>SQLite 3.0 as its storable data. And I don't like simple ASCII/wide
>implicit translation wrapper to be incorporated in SQLite since it
>becomes unwanted overhead. Here I only talk about TCHAR filename
>and abstraction of file-handling interfaces.
>
>-- KL
>
>
>---
Re: [sqlite] phpSQLiteAdmin
Hi there! Everybody from the list is invited to test the original phpSQLiteadmin at http://phpsqliteadmin.sourceforge.net/ cheers Felipe Lopes Em 19 Mar 2004, Kenneth Lo escreveu: >Lay András >>Anybody use phpSQLiteAdmin? >>(http://www.phpguru.org/phpSQLiteAdmin.html) >>Because it don't works for me, no error, only it >>redirects to a login.php?SessionID=..., and nothing. > >Have you tried SQLiteManager http://sqlitemanager.sourceforge.net/ ? It's >extremely simply to install. > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >-- Felipe Lopes. _ Voce quer um iGMail protegido contra vírus e spams? Clique aqui: http://www.igmailseguro.ig.com.br Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] moving from mySQL to SQLite - A guidance request
On Mar 19, 2004, at 12:38 AM, Darren Duncan wrote: On Fri, 19 Mar 2004, Fred Williams wrote: Yes, about that c.firstname thing... Do we need to turn in some kind'a formal "enhancement request?" Seems the feeling of those responding was that a configurable option was most desired. Perhaps a PRAGMA? So Richard, in all your spare time, what'd y'a think? I would say that if this were implemented then is should indeed be PRAGMA triggered and not be the default option. A default of "leave it the way you found it" as is done now seems best for a default. It's certainly more descriptive. The "AS" directive in SQL for explicit renaming seems the best way to rename for serious work. Also, an auto-rename as was asked for could have a side-effect of losing retrieved data in some cases. For example, see the following: SELECT a.foo, b.foo ... If the "a." and "b." were stripped off, we would have two returned columns with identical names. Any application which actually references the returned data by name and not by column number would only be able to see one of them. And if the application layer puts a row in an associative array (a "hash" in Perl talk) of field name/value, then only one column value would be stored and the other lost. So you can see how the requested new behaviour would only be useful in specialized cases and isn't good for a default. On the other hand, a good way around this problem is that the SQL parser will throw an error when said behaviour is used, in situations where the SQL writer does what I demonstrated, citing the fact that multiple same-named return value columns aren't allowed, requiring the application writer to use "AS" at least once to get around the error. I would second this last option... I (personally) would prefer if there was "auto-aliasing" (serious work or not so serious work), and if there was a case where we had a.foo, b.foo then the SQL parser would croak saying, uh huh! so I could go in and add the necessary AS. Many thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Can't open database
On Thu, 18 Mar 2004, Brian Marler wrote: >I have a database I have been running for someone else that I have always >been able to view/edit with one of the various GUI interfaces for SQLite. >Unfortunately the latest db update I have, I can't find a program to view >the db - I've tried everyone I could get my hands on, including the >command line version. The program that is accessing it still runs fine >(It's heavily dependent on the db), so I know its not corrupted. When I >try to view it using a quick view program, I see a comment saying "**This >file contains an SQLite 2.1 database**" with some gibberish afterwards. >Any thoughts on how I can access the data? I need to add some more user >accounts and the programmer is on vacation for the next 2 weeks. http://www.sqlite.org/sqlite-2.1.7.tar.gz > >Thanks in advance, >Brian -- "The problem with the French is that they don't have a word for entrepreneur" George W. Bush -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OT: bush misquote (was Re: [sqlite] more performance questions)
On Thu, 18 Mar 2004 [EMAIL PROTECTED] wrote: >On Mar 18, 2004, at 11:28 AM, David Morel wrote: > >> Le jeu 18/03/2004 à 15:42, Christian Smith a écrit : >> | "The problem with the French is that they don't have a word for >> entrepreneur" >> | George W. Bush >> >> did the man realy SAY that? > >Nah: > > http://www.snopes.com/quotes/bush.htm > >It's a variation on the old joke where Reagan says he doesn't trust the >Russians because they don't have a word for detente.. What I find worrying is that it was Alastair Campbell who denied that the quote is true. If you believe HIM, then you'll believe any old wive's tale (Iraq dossier, anyone?) It smacks of political cover up to me, helping Bush save face. Still, in light of this new 'evidence', I shall search for a new quote. :) > >-D > Christian -- "The problem with the French is that they don't have a word for entrepreneur" George W. Bush (Allegedly, being investigated:) -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] some optimisation help?
At 6:10 PM +1030 3/19/04, Jake Skinner wrote:
The following query is very slow. I don't know how to improve my
query, and I'm sure I'm doing this just about the slowest way
possible!! :(
begin sql query
==
select t1.time, t1.units_processed,
round((t1.units_processed+t2.units_processed+t3.units_processed+t4.units_processed)/4)
as ave
from location_stats as t1,
location_stats as t2,
location_stats as t3,
location_stats as t4
where t1.time=t2.time
and t3.time=t4.time
and t4.time=t2.time
and t1.date=date("2004-02-24",'-7 days')
and t2.date=date("2004-02-24",'-14 days')
and t3.date=date("2004-02-24",'-28 days')
and t4.date=date("2004-02-24",'-35 days')
===
end sql query
If anyone has any sort of suggestions I would be very greatful...
cheers
Jake
I'm not quite sure if this is what you want, but it should be in the
right ball park:
SELECT time, AVG(units_processed) AS ave
FROM location_stats
WHERE date=DATE("2004-02-24",'-7 DAYS')
OR date=DATE("2004-02-24",'-14 DAYS')
OR date=DATE("2004-02-24",'-28 DAYS')
OR date=DATE("2004-02-24",'-35 DAYS')
GROUP BY time
If it is correct, then it should run a lot faster, as it is simpler.
For added clarity, I made the SQL keywords uppercased in my version
and your identifiers lowercased, as I understood them.
Personally, I wouldn't give my table columns names that looked like
key words, like 'time' or 'date' as it appears you did.
If you were wanting to compare your number of units just this last
week to the average of the previous several weeks, then you may have
to take the whole expression I wrote and use it as a sub-query in the
FROM clause of a larger one that joins the results with a simpler
select just fetching the newer day's numbers.
-- Darren Duncan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
