Re: [sqlite] Output in currency format

[Fred Williams]

That has always been my most effective last resort when attempting to do 
business math with many databases and development environments.

> Thanks for all the advice on this.  Just to be clear, I wasn't  
> referring to the accuracy of calculations when I compared the sqlite  
> date/time formatting capabilites to the lack of similar functionality  
> for currency, just the fact that there is a precedent for sqlite  
> providing output formatting capability for some types of data.
>
> Just to be sure I get my calculations correct, the suggestion is that  
> all currency amounts should be stored in the database as whole numbers  
> in fields of type INTEGER.  Calculations would be done using the whole  
> numbers and I'll need some routines to convert between the database  
> format and the display format.  Do I have that right?
>
> Pete Haworth
>
>
>
>
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>   
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Output in currency format

[Fred Williams]

The best (safest?) way I have found to handle non scientific math is to 
work strictly with integers and multiply and divide using ROUND/TRUNC as 
required to gain the precision required.  This includes way more than 
SQLite situations as well.  Borland (Code Gear) seem to be the only 
developer tools producer to recognize the need for "business" math with 
their native BCD data type.

Fred
> Seems like I should handle the formatting in my application.  Not sure  
> I agree that sqlite is not the place to do output formatting - it  
> provides lots of date and time formatting features so at least in that  
> area, output formatting is available.
>
> Thanks also for the info re accuracy/REAL formatting.  I will change  
> my db design accordingly.
>
> Thanks,
>
> Pete Haworth
>
>
>
>
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>   
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] low-level view of data values?

[Fred Williams]

- Original Message - 
From: "Dan Phillips" 
To: "General Discussion of SQLite Database" 
Sent: Tuesday, October 13, 2009 2:40 AM
Subject: Re: [sqlite] low-level view of data values?


> On Tue, Oct 13, 2009 at 2:01 AM, Robert Simpson  
> wrote:
>> I'm pretty sure I do store them as strings -- SQLite doesn't have a
>> "decimal" datatype, and "double" doesn't cut the precision mustard for
>> emulating "decimal".
>
> Yes, but I believe the Decimals-as-text will only work if the column
> is declared as TEXT rather than as NUMERIC. If it is NUMERIC, then the
> Decimals will be end up being stored as REALs. You can verify this by
> doing a "select typeof(MyField)" SQL statement.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


The best way I have found to manage decimal (Business math) with most all 
the databases is to use integers and multiply and divide by the decimal 
offset (i.e. 10, 100, 1000) for presentation purposes,  doing my own 
"bankers rounding"  in code.  Big hassle, but transports well.

As long as computer scientists are driving the bus, business math will 
remain a step child, although probably 90+ % of all db apps are business 
related, IMHO.  No offence intended Dr. H!

Fred

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Tedious CSV import question

[Fred Williams]

If you have a file that conforms fully to the RFC, I honestly don't see the
problem.  Your examples do not meet the RFC rules.  If the rule does not
address leading spaces outside the quoted text, then the input file should
not contain spaces there as they will be ignored.

Over the years I have written several CSV parsers in three of four different
languages at least and have never had a problem parsing a VALID CSV file.  I
have never used the SQLite command line utility for such so cannot judge its
functionally.  I use my own parser or someone else's'.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Wilson, Ronald
Sent: Friday, September 25, 2009 1:38 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Tedious CSV import question


> > Still, the RFC does not
> > address how to handle rows like this:
> >
> > 1234,abc"123",abc
> > 1235,""123,abc
>
> Both violate the format as defined.  Generate an error message or
> interpret them any way that suits you.
>
> > What are you supposed to do with those?  It is not clear.  Also, are
> > you
> > supposed to strip the quotes upon consuming the field?  Are you
> > supposed
> > to un-escape escaped quotes?
> >
> > "1234" -> 1234 or "1234" ?
>
> 1234
>
> > "15""" -> 15" or 15"" or "15""" or "15"" ?
>
> 15"
>
> Simon.

I can appreciate common sense answers, but the RFC doesn't specify those
answers.  The RFC seems to only address the formatting of the CSV file,
not the consumption of it.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Fred Williams]

Thanks Dr.

I already read that along time ago and fully understand it 100%.  Seems many
others either do not read or do not understand simple straight forward
descriptions of basic functionality.  Or just maybe they ask anyway hoping
someone will say well why not? :-)

Fred
120% happy with SQLite.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Friday, September 25, 2009 1:12 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLite Suitability for Shopping Cart



On Sep 25, 2009, at 1:13 PM, CityDev wrote:

>
>
> Fred Williams-5 wrote:
>>
>> no further need to ask and answer, "Will SQLite support
>> multi users?
>>
> Maybe it should be covered a bit more specifically on the SQLite site,

http://www.sqlite.org/whentouse.html

> bearing in mind that new people would naturally have the mindset that
> databases are for shared use normally. SQLite does have sharing
> capabilities
> so it would be helpful to profile these for novices.
> --
> View this message in context:
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p256157
24.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Suitability for Shopping Cart

[Fred Williams]

Since SLQite was never intended for multi user databases in the initial
design i.e. the name "SQLite" I would say the design is the reason.

Now can the design be reengineered to allow finer grain locking as an option
without derailing the original design intent?  That is for those that do all
the work for the rest of us to decide.

My only incentive that pops readily to mind would be the enormous bandwidth
reduction here with no further need to ask and answer, "Will SQLite support
mulit users? and etc. ad nauseium..." :-)

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of CityDev
Sent: Friday, September 25, 2009 12:58 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQLite Suitability for Shopping Cart



This is what is says on the SQLite site:

"We are aware of no other embedded SQL database engine that supports as much
concurrency as SQLite. SQLite allows multiple processes to have the database
file open at once, and for multiple processes to read the database at once.
When any process wants to write, it must lock the entire database file for
the duration of its update. But that normally only takes a few milliseconds.
Other processes just wait on the writer to finish then continue about their
business. Other embedded SQL database engines typically only allow a single
process to connect to the database at once."

What that seems to be saying is you can have concurrency but you will suffer
the effects of whole-database locking for update transactions. It seems a
glaring shortcoming, so either SQLite is not normally used by multiple
processes or people find it doesn't matter too much ie you still get
acceptable performance with n users. Which do you think is true?
--
View this message in context:
http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p256068
92.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Tedious CSV import question

[Fred Williams]

Try this:

http://sqliteadmin.orbmu2k.de/

Works great for me.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of J Glassy
Sent: Thursday, September 24, 2009 3:16 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Tedious CSV import question


On c.Mundi's CSV inquiry,
  One way I (interactively) address the need to import CSV data into sqlite
databases is
to use Mrinal Kant's SQL Manager add-in. This offers what I believe are more
robust facilities for performing this type of bulk import. I'm not sure if
SQL Manager is an option for you, but give it a try if you can get by
without a strictly console level scripted solution.

joe

On Thu, Sep 24, 2009 at 2:12 PM, Simon Slavin
wrote:

>
> On 24 Sep 2009, at 8:37pm, C. Mundi wrote:
>
> > Happily, sqlite has a very nice .output mode for CSV.  It correctly
> > double-quotes fields when they contain a space or a comma, and it
> > correctly
> > 'escapes' double-quote literals as "".  Great!  I need to go the
> > other way.
> >
> > I don't see an inverse .import mode in sqlite to handle the completely
> > general CSV syntax.  As anyone who has ever tried knows, parsing
> > compliant
> > CSV is a lot harder than writing compliant CSV.
>
> Sorry, but you didn't miss anything, no such facility exists.
> The .import command does not handle quoted fields correctly, as has
> recently been stated on this list.  Some third-party tools do it fine
> but if you want to import your particular file you'll have to tweak
> your file so that whatever you're using as a separator never appears
> inside a field.
>
> Simon.
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>

Joe Glassy
Research Analyst/Programmer
University of Montana NSF EPSCoR Program
Davidson Honors College Room 013
Missoula, MT 59812
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Simon Slavin
Sent: Monday, September 21, 2009 3:05 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Most wanted features of SQLite ?


On 21 Sep 2009, at 6:53pm, Brad House wrote:

> I definitely don't agree here as we're talking about these additional
> locks existing _only_ in memory, not on disk.

Which requires client/server architecture.  Which SQLite3 doesn't
have.  Once you require concurrent access features in your DBMS (i.e.
multi-user, lots of locking) the things you nned to implement start to
be easier with a client/server architecture, whether it's a standalone
client application that must be launched manually or just a unix-style
daemon running in the background which is launched automatically when
needed and quits when nothing has used it in a while.


On 21 Sep 2009, at 6:44pm, Pavel Ivanov wrote:

> Interesting point, Simon. Are you saying that all developers of big
> database engines that implemented row-level locks are just idiots
> because there's no benefit from it at all? They had to implement just
> database-level locks and all users would be a lot happier because
> they'd received a significant performance boost?

Nope.  They chose to implement a big database engine and that meant
they chose client/server architecture, which makes locking (and all
other things that require centralised control) less difficult.  It's
just that this is not how SQLite works.

Simon.

With "optional" fine grained locking would SQLite not work as the "back end"
for a client server (wrapper) implementation that did the multi process (or
whatever) lock management up one level so to speak?

Sybase bought a small DB company a while back.  The company was known as
"Advantage DB" prior to the acquisition.  They, and Sybase still does I
believe, offered a "Local" and "Server" implementation of their DB.  That is
what I'm really thinking of here, with SQLite.dll used as the "Local" and
SQLite.dll +  as the "Server."

Fact is Advantage was what I was using for my "Local" DB implementations
before discovering SQLite.

Fred

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

Dr. Hip,

As I stated before, I do not have a detailed understanding of the core
source.  Therefore I do not know how difficult or even possible adding a
pragma controlled(?) finer grained locking "hook" or related API calls for
those who might wish to "wrap" a server layer around the core.

SQLite has proven to be a very fast, small, reliable, and bullet proof DB
engine, for a single instance.  I prefer to keep it true to its heritage.
My real motive for the locking solution and API's would be to take the multi
user pressure off the core.  Leave us that want it to remain small, fast,
and tight, a core that can either be used as is or embedded in a bigger
picture.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Monday, September 21, 2009 8:14 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Most wanted features of SQLite ?



On Sep 21, 2009, at 8:58 AM, Fred Williams wrote:

>
> Fine for me.  It seems to be everybody else that wants their favorite
> feature imbedded in the core :-)
>
> Fine grained locking would be a great "asset" I feel.  Notice I did
> not
> request a "feature."


On my to-do list is to write a paper that explains why fine-grain
locking is not practical without either (1) a dedicated server process
to manage the locks or (2) enhancements to OS locking primitives that
are not currently available on any OS that I am aware of.  There is a
widely held belief that since OSes provide byte-level locking of files
it should be a simple matter to provide row-level locking in a
serverless database engine.  The proposed paper will explain why that
belief is incorrect.


D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

Fine for me.  It seems to be everybody else that wants their favorite
feature imbedded in the core :-)

Fine grained locking would be a great "asset" I feel.  Notice I did not
request a "feature."

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Alexey Pechnikov
Sent: Monday, September 21, 2009 1:54 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Most wanted features of SQLite ?


Hello!

On Monday 21 September 2009 01:45:07 Fred Williams wrote:
> With the background of the never ending drumbeat of "feature, feature,
> feature..." on this list as a reason, I wonder if the structure of
> SQLite could be "enhanced" to better support the "plug-in" concept, aka:
> as with Firefox, IGoogle, and the like for instance.

SQLite does have the best extensibility of known to me DBMS. You can bind
function or collation from any programming lang. And you can easy write
extension with a new functions and collations. You can use SQLite functions
in any programming lang and create wrappers.

Is it not enought for you?!

Best regards, Alexey Pechnikov.
http://pechnikov.tel/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

Can you say Oracle? :-)

Along this same line, and based on a few years of using SQLite and
following the messages on this list, here's my two cents worth.

First a disclaimer: I have no knowledge of the detailed implementation
and architecture of SQLite, other than by inference from discussions on
this list. I did look at the source once long, long ago, and quickly
decided, life is too short.

With the background of the never ending drumbeat of "feature, feature,
feature..." on this list as a reason, I wonder if the structure of
SQLite could be "enhanced" to better support the "plug-in" concept, aka:
as with Firefox, IGoogle, and the like for instance.

This would allow SQLite (the module) to remain true to its roots (i.e.
the "three choices") but better support those who desire to enhance
SQLite through the use of both plug-ins and wrappers. This could better
address a broader range of applications and allow the developer to
selectively "bloat" the final result with only those features required
for the project at hand.

One thing that would greatly enhance concurrency (the most heard feature
request?) would be to implement a finer grained locking structure in the
base module. Currently you can either lock or unlock the database,
period.

All modern database implementations lock to, at a minimum, the the
"record" (row) level. The implications of record level locking is pretty
obvious related to concurrency. With finer grained locking implmenting
multi user "server" wrappers and plug-ins would be better facilitated
and allow the base SQLite module to remain true to the three choices.

Fred

-Original Message-

From: sqlite-users-boun...@sqlite.org

[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of sub sk79

Sent: Sunday, September 20, 2009 9:16 AM

To: General Discussion of SQLite Database

Subject: Re: [sqlite] Most wanted features of SQLite ?

...


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

Can you say Oracle? :-)

Along this same line, and based on a few years of using SQLite and following
the messages on this list, here's my two cents worth.

First a disclaimer: I have no knowledge of the detailed implementation and
architecture of SQLite, other than by inference from discussions on this
list.  I did look at the source once long, long ago, and quickly decided,
life is too short.

With the background of the never ending drumbeat of "feature, feature,
feature..." on this list as a reason, I wonder if the structure of SQLite
could be "enhanced" to better support the "plug-in" concept, aka: as with
Firefox, IGoogle, and the like for instance.

This would allow SQLite (the module) to remain true to its roots (i.e. the
"three choices") but better support those who desire to enhance SQLite
through the use of both plug-ins and wrappers.  This could better address a
broader range of applications and allow the developer to selectively "bloat"
the final result with only those features required for the project at hand.

One thing that would greatly enhance concurrency (the most heard feature
request?) would be to implement a finer grained locking structure in the
base module.  Currently you can either lock or unlock the database, period.

All modern database implementations lock to, at a minimum, the the "record"
(row) level.  The implications of record level locking is pretty obvious
related to concurrency.  With finer grained locking implmenting multi user
"server" wrappers and plug-ins would be better facilitated and allow the
base SQLite module to remain true to the three choices.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of sub sk79
Sent: Sunday, September 20, 2009 9:16 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Most wanted features of SQLite ?


>> 1.  Generate a loadable SQLite extension and distribute it with DB.
>
> We can write C extension without any wrapper. Why we need to learn
> your extension for getting the same result and possible new bugs?

PL/SQL has a very wide user-base and a huge repository of existing
code-base in the world. Using StepSqlite PL/SQL compiler this huge
base can use SQLite by reusing their code as well as reusing their
skills - no learning curve for this set of users.

For those who do need to learn PL/SQL, it is still worthwhile to
utilize StepSqlite because:

PL/SQL is specially designed for and very suitable for handling
database operations, while other general purpose languages like TCL,
lua, C , C++ etc are very suitable indeed for application programming.
  StepSqlite enables combining the respective power of these two sets
of languages in writing apps with SQLite back-ends by using the
concept of Stored Procedures/Functions and Packages.
All big databases operate this way as well: for ex, Oracle lets apps
written in C++ to call stored procedures written in PL/SQL.

StepSqlite is committed to bringing this power and convenience from
the big database world to the small database world while preserving
the small, fast and reliable.

More benefits of StepSqlite described here:
http://www.metatranz.com/stepsqlite/benefits.html

http://www.metatranz.com/stepsqlite

regards,
-sk
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Most wanted features of SQLite ?

[Fred Williams]

We don't really need that "SQLite."  We already have it.  It is commonly
called MySQL.  It take well over 150MB of disk space and major management
efforts to maintain any level of performance.  Just what the client/server
guys love to play with.

SQLite is way too small and Bring to catch their eye.  If it ain't big
and overly complex it must be a toy.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Simon Slavin
Sent: Friday, September 18, 2009 2:56 PM
To: General Discussion of SQLite Database
Subject: [sqlite] Most wanted features of SQLite ?


So if you had a team of programmers to write something like SQLite
which didn't have the drawbacks SQLite has, which drawbacks would you
identify ?  I'm asking not about minor faults with specific SQLite
library calls, but about the sort of things which require rewriting
from the ground up.  The ones that seem to come up most often here are

* Some sort of synchronisation support
* Support for multiple concurrent clients/processes
* Unicode support from the ground up

Please note: I am not suggesting that any of these problems are easy
to solve.  I'm just interested in what problems people want solved.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] MySQL makes me wish for SQLite

[Fred Williams]

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Darren Duncan
Sent: Friday, September 11, 2009 3:49 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] MySQL makes me wish for SQLite


Fred Williams wrote:
> I've already eaten up the better part of 150MB of disk space, run
> installation repair once, (of many?) and still trying to find the
> "admin" logon and password.  Damn!  It has been too long!
>
> Please, is someone working on a good straight forward .PHP SQLite
> interface?  I might even pay for it!

PHP 5 has a SQLite3 extension, which is documented at
http://ca3.php.net/manual/en/book.sqlite3.php .  This is bundled and active
by
default as of PHP 5.3.0.  I would naively think that's what you seek, and if
not
then I'd ask why.

Also, a comment in the introduction for the above, at
http://ca3.php.net/manual/en/intro.sqlite3.php#89809 , says that the current
recommended way to *natively* use SQLite 3 with PHP 5 is using a PDO object,
which lets you call any function that the SQLite library exposes.

Of course.  If you weren't stuck on PHP I would also recommend using a
different
program language with strong or superior SQLite support, such as Perl's
DBD::SQLite.


-- Darren Duncan

Please!  Just one new language at a time! As mentioned in my last message,
I'm stuck with PHP because of a prepackaged web app I don't have the time,
patience, or experience to write from scratch.

You guys are going to make me read yet another d+++m technical manual it
looks like.

Thanks for the "awakening."  Now where did I leave that, "Learn PHP In
Twenty Minutes" book?

Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] MySQL makes me wish for SQLite

[Fred Williams]

Hummm...

Perhaps I should do a little more homework.

I'm looking at a packaged "Shopping Cart" and wishing I could boot out the
MySQL.  Next release is promising broader database support.  BUT, it has
been getting ready for Beta "real soon" for about nine months now.

Besides, I just got back from Big Lots! where I bought some cheap Chinese
tools and I feel better now :-)

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Jay A. Kreibich
Sent: Friday, September 11, 2009 3:41 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] MySQL makes me wish for SQLite


On Fri, Sep 11, 2009 at 03:24:09PM -0500, Fred Williams scratched on the
wall:

> Please, is someone working on a good straight forward .PHP SQLite
> interface?  I might even pay for it!

  *Confused*

  SQLite is built-in to the standard PHP5 distribution.

http://php.net/sqlite

  Is the native interface really that bad or something?

   -j

--
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] MySQL makes me wish for SQLite

[Fred Williams]

Not sure yet.  It would need to implemented on the host machine I think.
I'm super timeframe compressed right now.  In the future I hope to have some
"research" time available.

I have found a rather simple .PHP SQLite "object" and hope to look a little
closer at it when I get that 25 hour day I've been needing.

I think my previous message was a bit of a vent.  But one does often wish
for "White Knights", like when I found Dr. Hip's little less than 500K bit
of code.

Fred


-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Hoover, Jeffrey
Sent: Friday, September 11, 2009 3:24 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] MySQL makes me wish for SQLite


I saw something about an ODBC module for SQLite.
Could you workaround the PHP-SQLite issues via ODBC?

-Jeff

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Fred Williams
Sent: Friday, September 11, 2009 4:24 PM
To: General Discussion of SQLite Database
Subject: [sqlite] MySQL makes me wish for SQLite

Just began coming back to speed on MySQL after many years. (Thanks to
SQLite)  Boy does it SUCK!

I've already eaten up the better part of 150MB of disk space, run
installation repair once, (of many?) and still trying to find the
"admin" logon and password.  Damn!  It has been too long!

Please, is someone working on a good straight forward .PHP SQLite
interface?  I might even pay for it!

Need a "drop in" SQLite implementation for a website database.  I'll
endure MySQL for the meantime.  Like I use to prostitute myself with MS
Server.  BUT, I'm already ready to JUMP!

Sorry, I guess you might have noticed my frustration is showing a bit...

Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] MySQL makes me wish for SQLite

[Fred Williams]

Just began coming back to speed on MySQL after many years. (Thanks to
SQLite)  Boy does it SUCK!

I've already eaten up the better part of 150MB of disk space, run
installation repair once, (of many?) and still trying to find the
"admin" logon and password.  Damn!  It has been too long!

Please, is someone working on a good straight forward .PHP SQLite
interface?  I might even pay for it!

Need a "drop in" SQLite implementation for a website database.  I'll
endure MySQL for the meantime.  Like I use to prostitute myself with MS
Server.  BUT, I'm already ready to JUMP!

Sorry, I guess you might have noticed my frustration is showing a bit...

Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLJet - pure Java implementation of SQLite

[Fred Williams]

I think you are talking "Open Source" world now.  In the late 80's, early
90's things like Open Source Databas/Datashare compilers weren't even in
anyone's dreams.  What you saw was what you got.  With no open source
compilers to monkey with you just did what you had to, pretty or not.

Somebody did later write a Databus/Datashare to C translator and the
Datapoint world beat a very deep pathway to his door!  Shortly after that
Datapoint was no more and his market evaporated.

Sorry, this ain't SQLite at all.  I'm done here.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of John Stanton
Sent: Thursday, August 13, 2009 1:32 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite


In this situation it has been our approach to never try to translate
source in one language into another.  It is a  pointlesss activity when
you think about it.  Much better to have the C or whatever compiler have
a different code generator, for example Java target code.

You are not rev locked that way and if your C compiler optimizes well
you have an efficient executable.  Your JIT compiler still works.

People would spend months translating program into error ridden monsters
instead of spending less time working on a compiler and ending up with
unchanged source with no added errors and which can be easily maintained
in the origibal code with the comments still meaningful.

Fred Williams wrote:
> Having had the unfortunate opportunity to use a couple of language
> translators as well as spending about six fruitless months developing one
> which in the end was no better, I say there is no known translation that
> would allow the three SQLite, "Small, Fast, Reliable" adjectives to
> translate into any regurgitated language output, with the exception of
> compiling SQLite source with a C++ compiler :-)
>
> Fred
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns
> Sent: Tuesday, August 11, 2009 7:15 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alexander Kitaev wrote:
>
>> Not to depend on native SQLite binaries or
>> opaque NestedVM code,
>>
>
> As a matter of interest what problem exactly do you have with NestedVM?
> It's output is indeed opaque (not human comprehensible) but the same is
true
> of Java source versus bytecode.  In both cases the input source is
readable.
>
> It would also be interesting if anyone has built something that
comprehends
> the SQLite C source and then does the conversion into other languages
based
> on that.  It would make updates a lot easier, the generation of
instrumented
> and test code easier, and the search for issues or optimisations easier.
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkqCCWgACgkQmOOfHg372QQXqwCeJ4pqKa89vcCAxTQOelMyoPU6
> cuQAoK6Feey6AL3pdzMgv983tn8Yg1ML
> =TKoq
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi] Reading list of tables?

[Fred Williams]

That's all you are suppose to get when querying the Master table for table
names.

You ask how to get a list of tables.  That is what you got.

What you are asking for now is more complex.

Try:

Select Name, SQL from "SQLite_master";

for even more fun try:

Select * from "SQLite_master"

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Gilles Ganault
Sent: Thursday, August 13, 2009 3:28 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] [Delphi] Reading list of tables?


On Tue, 11 Aug 2009 11:35:16 +0100, Simon Slavin
 wrote:
>SELECT sql FROM sqlite_master WHERE type='table'

Thanks Simon.

To get only the name of the tables instead of the SQL command that was
used to create them:

SELECT tbl_name FROM sqlite_master WHERE type="table"';

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLJet - pure Java implementation of SQLite

[Fred Williams]

Actually that makes a lot of sense.  At the machine code level most of the
programmer "style" is winnowed out.  Even translating to Assembler code
would be "better" than going from one high level language to another.

The translator I wrote was from Databus/Datashare (Children there use to be
a network of computers back in the dark ages, (Before PC) called Datapoint -
Arc Net.) to Wang BASIC (Yes my sons, they built a line of general purpose
computers once.  Unsuccessfully I might add.) (IBM syntax).  Bad choice, but
the customer was just a little desperate.

I seem to remember, haven't done it in years, Borand's C and C++ compilers
could output Assembler source.  One could conceivably take that output and
translate it into almost any foreign CPU's native Assembler with great
efficiency I would think.

Opps!  Straying a long way from SQLite!

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Jim Showalter
Sent: Wednesday, August 12, 2009 10:26 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite


Perhaps it would be better to translate the object code.

It's also possible to translate bytecode (for example, from Java to
.NET).

- Original Message -
From: "Fred Williams" <f.willi...@verizon.net>
To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
Sent: Wednesday, August 12, 2009 5:42 AM
Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite


> That's the problem any more it seems.  Everyone "assumes" unlimited
> CPU and
> memory :-)
>
> Give a guy a Cray and he'll write one hell of a "Solitaire"!
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns
> Sent: Wednesday, August 12, 2009 12:09 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Fred Williams wrote:
>> I say there is no known translation that
>> would allow the three SQLite, "Small, Fast, Reliable" adjectives to
>> translate into any regurgitated language output, with the exception
>> of
>> compiling SQLite source with a C++ compiler :-)
>
> If you read Bernstein's retrospective on qmail, one of his
> suggestions is to
> write code in a higher level language (especially more secure in the
> sense
> that C isn't such as preventing buffer & integer overflows etc) that
> is then
> transcoded to C.  (Some conspiracy theorists looking at his code
> claimed he
> actually did do this :-)
>
> So in theory given unlimited CPU and memory it should be possible to
> take
> the SQLite C code and turn it into something higher level and then
> turn that
> back into the more verbose platforms (.NET, Java).  The big
> advantage of
> this approach (after the upfront work) is that keeping up with
> SQLite
> progress is easy.
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE
> U9cAoIzXPblugsswnhbgnmTNYSrkdMj7
> =VYQ3
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLJet - pure Java implementation of SQLite

[Fred Williams]

That's the problem any more it seems.  Everyone "assumes" unlimited CPU and
memory :-)

Give a guy a Cray and he'll write one hell of a "Solitaire"!

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns
Sent: Wednesday, August 12, 2009 12:09 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite


-BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fred Williams wrote:
> I say there is no known translation that
> would allow the three SQLite, "Small, Fast, Reliable" adjectives to
> translate into any regurgitated language output, with the exception of
> compiling SQLite source with a C++ compiler :-)

If you read Bernstein's retrospective on qmail, one of his suggestions is to
write code in a higher level language (especially more secure in the sense
that C isn't such as preventing buffer & integer overflows etc) that is then
transcoded to C.  (Some conspiracy theorists looking at his code claimed he
actually did do this :-)

So in theory given unlimited CPU and memory it should be possible to take
the SQLite C code and turn it into something higher level and then turn that
back into the more verbose platforms (.NET, Java).  The big advantage of
this approach (after the upfront work) is that keeping up with SQLite
progress is easy.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE
U9cAoIzXPblugsswnhbgnmTNYSrkdMj7
=VYQ3
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLJet - pure Java implementation of SQLite

[Fred Williams]

Having had the unfortunate opportunity to use a couple of language
translators as well as spending about six fruitless months developing one
which in the end was no better, I say there is no known translation that
would allow the three SQLite, "Small, Fast, Reliable" adjectives to
translate into any regurgitated language output, with the exception of
compiling SQLite source with a C++ compiler :-)

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns
Sent: Tuesday, August 11, 2009 7:15 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexander Kitaev wrote:
> Not to depend on native SQLite binaries or
> opaque NestedVM code,

As a matter of interest what problem exactly do you have with NestedVM?
It's output is indeed opaque (not human comprehensible) but the same is true
of Java source versus bytecode.  In both cases the input source is readable.

It would also be interesting if anyone has built something that comprehends
the SQLite C source and then does the conversion into other languages based
on that.  It would make updates a lot easier, the generation of instrumented
and test code easier, and the search for issues or optimisations easier.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqCCWgACgkQmOOfHg372QQXqwCeJ4pqKa89vcCAxTQOelMyoPU6
cuQAoK6Feey6AL3pdzMgv983tn8Yg1ML
=TKoq
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] ANN: SQLite 3.6.16.C#

[Fred Williams]

Thank you for your understanding.  And best of luck with XXLite?

I know you have a large captive audience out there.  It is the only reason I
swallow my pride and admit knowledge of the most pervasive OS currently on
the planet.  Not the "best" technically, but best "marketed."

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Noah Hart
Sent: Sunday, August 02, 2009 7:58 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#



Richard sent me a gentle reminder that read in part:


Please also note that the SQLite source code is in the public domain, but
the "SQLite" name is not.  SQLite is a registered trade mark.  If I don't
defend the trademark, then I could lose it.  So, I really do need to insist
that you not use the name "SQLite" for your product.



This is an excellent reminder, and until this is done, I've removed access
to the source code and will terminate this google code project.  I'll post
an announcement in the future when the new project is ready.

Also, if anyone has an ideal about what to call it ...
Regards,

Noah Hart



Noah Hart wrote:
>
> I am pleased to announce that the C# port is done to the point where
> others can look at it.
>
> The project is located at http://code.google.com/p/sqlitecs
>
> Enjoy,
>
> Noah Hart
>

--
View this message in context:
http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24777619.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] ANN: SQLite 3.6.16.C#

[Fred Williams]

I have at least a screwdriver and monkey wrench to go with my hammer in my
computer software tool bag.  Observing the fastener at hand allows me to
pick the proper tool.  Then if that doesn't work, there's always the hammer.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Kosenko Max
Sent: Sunday, August 02, 2009 6:32 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#



I don't know why you have decided that C# or Java isn't competitive to
native
compiled code.
After JIT there is no VM between Java/.NET and OS.

While C has better compiler than C# it still don't have JIT engine that can
optimize your code for specific hardware you're running on right now. Or it
can recompile code based on statistics. Options unavailable to native code.
And after all having managed implementation gives better control on code,
simpler code and so on. So in reality there should be strong reason for NOT
using managed implementations for whatever. But it's only rising now...


Jim Showalter-4 wrote:
>
> Could we not disparage different OSs and languages?
>
> A fair comparison of performance isn't between a C and C#
> implementation of SQLite, but between a C# and Java implementation of
> SQLite. Both C# and Java are managed languages that run atop a VM that
> runs atop an OS. C is down on the metal. I would expect the C version
> to be faster.
>
> I don't know the background of why this programmer did a port directly
> to C# instead of binding C# to the existing C library, but I assume he
> had his reasons.
>
> - Original Message -
> From: "Fred Williams" <f.willi...@verizon.net>
> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
> Sent: Saturday, August 01, 2009 6:08 AM
> Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#
>
>
>>
>> Hummm... Guess there is a reason there are no implementations of C#
>> external
>> to the Mickeysoft world :-)
>>
>> Guess if I had a lot of time to kill I could port it to Delphi...
>>
>> BTW, what's the memory footprint?
>>
>> Fred
>>
>> -Original Message-
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Kosenko Max
>> Sent: Saturday, August 01, 2009 6:22 AM
>> To: sqlite-users@sqlite.org
>> Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#
>>
>>
>>
>> Seems like I've misunderstood your performance results. And they are
>> 3-5times
>> slower than original...
>>
>> -
>> Best Regards.
>> Max Kosenko.
>> --
>> View this message in context:
>> http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24768252.html
>> Sent from the SQLite mailing list archive at Nabble.com.
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>


-
Best Regards.
Max Kosenko.
--
View this message in context:
http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24777007.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] ANN: SQLite 3.6.16.C#

[Fred Williams]

No I'm not proud of what a lot of OS providers produce.  Microsoft in
particular.  Sun's Java is becoming such a resource pig, I won't mess with
it either.

SQLite was and has always been designed to be extremely cross platform
portable, bare bones in both footprint and implementation.  It is, and
should remain so.  If someone wants to take the open source and implement it
in something like C# or Java, I think Dr. Hipp should contact them and
politely ask them to change the name, because the end result will be neither
that portable (C#) or efficient (Java.) MHO.

Lucky for most, SQLite has not suffered the extreme feature creep that is
inherent in most software projects.  And it appears a constant battle to
keep it true to its roots.  If I want a multi-user, full featured database I
have a multitude of very successful products to pick from.  I won't keep
asking the SQLite developers for just one more feature.  I tend to use a
product for which it was designed.  I'm not the kind of guy that just
because I own a hammer everything in the world looks like a nail.  I guess
that is why I can write in more than 10 programming languages.

A place for everything, and every thing in its place, so to speak.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Jim Showalter
Sent: Saturday, August 01, 2009 1:06 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#


Could we not disparage different OSs and languages?

A fair comparison of performance isn't between a C and C#
implementation of SQLite, but between a C# and Java implementation of
SQLite. Both C# and Java are managed languages that run atop a VM that
runs atop an OS. C is down on the metal. I would expect the C version
to be faster.

I don't know the background of why this programmer did a port directly
to C# instead of binding C# to the existing C library, but I assume he
had his reasons.

- Original Message -
From: "Fred Williams" <f.willi...@verizon.net>
To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
Sent: Saturday, August 01, 2009 6:08 AM
Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#


>
> Hummm... Guess there is a reason there are no implementations of C#
> external
> to the Mickeysoft world :-)
>
> Guess if I had a lot of time to kill I could port it to Delphi...
>
> BTW, what's the memory footprint?
>
> Fred
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Kosenko Max
> Sent: Saturday, August 01, 2009 6:22 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#
>
>
>
> Seems like I've misunderstood your performance results. And they are
> 3-5times
> slower than original...
>
> -
> Best Regards.
> Max Kosenko.
> --
> View this message in context:
> http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24768252.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] ANN: SQLite 3.6.16.C#

[Fred Williams]

Hummm... Guess there is a reason there are no implementations of C# external
to the Mickeysoft world :-)

Guess if I had a lot of time to kill I could port it to Delphi...

BTW, what's the memory footprint?

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Kosenko Max
Sent: Saturday, August 01, 2009 6:22 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] ANN: SQLite 3.6.16.C#



Seems like I've misunderstood your performance results. And they are
3-5times
slower than original...

-
Best Regards.
Max Kosenko.
--
View this message in context:
http://www.nabble.com/ANN%3A--SQLite-3.6.16.C--tp24764742p24768252.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] .lib file?

[Fred Williams]

Good!  I just told my wife to put the gun down... But she's not listening...

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Paul Claessen
Sent: Saturday, July 25, 2009 4:35 PM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] .lib file?


Actually, I was able to generate a .lib file from the DLL using Doug's
suggesting (link /lib /def:sqlite3.def).
Works fine now!

Thanks all!

~ Paul Claessen

> -Original Message-
> From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Fred
> Williams
> Sent: Saturday, July 25, 2009 4:44 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] .lib file?
>
> Hum.  So Mickeysoft does not supply a lib converter/creator utility?  I
even
> have a "Make" and "Grep" utility when I get nostalgic for my limited Unix
> days.
>
> My generator has an "-a" option to, "Add '_' alias for MS flavor cdecl
> functions."
>
> Is that what you mean?
>
> Someday if I can find someone to hold a big enough caliber gun to my head,
> I'm going to learn something about the "Visual" development world.  I
> installed the C++ "Express" version and was so underwhlmed by the
> performance I started look for that person with a giant gun :-(
>
> Fred
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Mihai Limbasan
> Sent: Saturday, July 25, 2009 1:13 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] .lib file?
>
>
> Fred,
>
> Unfortunately, .lib (or, for that matter, .obj) files created by Borland
> compilers are not compatible with the Microsoft toolchain, and
> vice-versa. Borland uses a variant of the OMF object format, and
> Microsoft uses a variant of COFF.
>
> On 07/25/2009 08:09 PM, Fred Williams wrote:
> > Paul,
> >
> > If you wish I can send yoou a SQLite3.lib file I just generated using my
> old
> > Borland C++ Builder 5 Lib utility.  Can't attach it here so contact me:
> >
> > fwillia...@gmail.com
> >
> > And I'll attach it to a reply.
> >
> > Fred
> >
> >
> > -Original Message-
> > From: sqlite-users-boun...@sqlite.org
> > [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Doug
> > Sent: Saturday, July 25, 2009 11:24 AM
> > To: 'General Discussion of SQLite Database'
> > Subject: Re: [sqlite] .lib file?
> >
> >
> > Hi Paul --
> >
> > When I build SQLite (from the amalgamation) into a DLL VS2008 (and
earlier
> > as I recall) automatically creates an import library in the same
directory
> > as the .DLL file.  I also _used_ to run the following command separately
> to
> > create the import lib:
> >
> > link /lib /def:sqlite3.def
> >
> > I haven't kept my sqlite3.def file up to date, but it's fairly recent if
> you
> > want to use it.  Since we can't post files to the newsgroup, I'll append
> it
> > here.
> >
> > Doug
> >
> > 
> > EXPORTS
> > sqlite3_aggregate_context
> > sqlite3_aggregate_count
> > sqlite3_auto_extension
> > sqlite3_bind_blob
> > sqlite3_bind_double
> > sqlite3_bind_int
> > sqlite3_bind_int64
> > sqlite3_bind_null
> > sqlite3_bind_parameter_count
> > sqlite3_bind_parameter_index
> > sqlite3_bind_parameter_name
> > sqlite3_bind_text
> > sqlite3_bind_text16
> > sqlite3_bind_value
> > sqlite3_bind_zeroblob
> > sqlite3_blob_bytes
> > sqlite3_blob_close
> > sqlite3_blob_open
> > sqlite3_blob_read
> > sqlite3_blob_write
> > sqlite3_busy_handler
> > sqlite3_busy_timeout
> > sqlite3_changes
> > sqlite3_clear_bindings
> > sqlite3_close
> > sqlite3_collation_needed
> > sqlite3_collation_needed16
> > sqlite3_column_blob
> > sqlite3_column_bytes
> > sqlite3_column_bytes16
> > sqlite3_column_count
> > sqlite3_column_decltype
> > sqlite3_column_decltype16
> > sqlite3_column_double
> > sqlite3_column_int
> > sqlite3_column_int64
> > sqlite3_column_name
> > sqlite3_column_name16
> > sqlite3_column_text
> > sqlite3_column_text16
> > sqlite3_column_type
> > sqlite3_column_value
> > sqlite3_commit_hook
> > sqlite3_complete
> > sqlite3_complete16
> > sqlite3_create_collation
> > sqlite3_create_collation16
> > sqlite3_create_collation_v2
> > sqlite3_create_function
> > sqlite3_create_function16
> > sqlite3_create_module
> > sql

Re: [sqlite] .lib file?

[Fred Williams]

Hum.  So Mickeysoft does not supply a lib converter/creator utility?  I even
have a "Make" and "Grep" utility when I get nostalgic for my limited Unix
days.

My generator has an "-a" option to, "Add '_' alias for MS flavor cdecl
functions."

Is that what you mean?

Someday if I can find someone to hold a big enough caliber gun to my head,
I'm going to learn something about the "Visual" development world.  I
installed the C++ "Express" version and was so underwhlmed by the
performance I started look for that person with a giant gun :-(

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Mihai Limbasan
Sent: Saturday, July 25, 2009 1:13 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] .lib file?


Fred,

Unfortunately, .lib (or, for that matter, .obj) files created by Borland
compilers are not compatible with the Microsoft toolchain, and
vice-versa. Borland uses a variant of the OMF object format, and
Microsoft uses a variant of COFF.

On 07/25/2009 08:09 PM, Fred Williams wrote:
> Paul,
>
> If you wish I can send yoou a SQLite3.lib file I just generated using my
old
> Borland C++ Builder 5 Lib utility.  Can't attach it here so contact me:
>
> fwillia...@gmail.com
>
> And I'll attach it to a reply.
>
> Fred
>
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Doug
> Sent: Saturday, July 25, 2009 11:24 AM
> To: 'General Discussion of SQLite Database'
> Subject: Re: [sqlite] .lib file?
>
>
> Hi Paul --
>
> When I build SQLite (from the amalgamation) into a DLL VS2008 (and earlier
> as I recall) automatically creates an import library in the same directory
> as the .DLL file.  I also _used_ to run the following command separately
to
> create the import lib:
>
> link /lib /def:sqlite3.def
>
> I haven't kept my sqlite3.def file up to date, but it's fairly recent if
you
> want to use it.  Since we can't post files to the newsgroup, I'll append
it
> here.
>
> Doug
>
> 
> EXPORTS
> sqlite3_aggregate_context
> sqlite3_aggregate_count
> sqlite3_auto_extension
> sqlite3_bind_blob
> sqlite3_bind_double
> sqlite3_bind_int
> sqlite3_bind_int64
> sqlite3_bind_null
> sqlite3_bind_parameter_count
> sqlite3_bind_parameter_index
> sqlite3_bind_parameter_name
> sqlite3_bind_text
> sqlite3_bind_text16
> sqlite3_bind_value
> sqlite3_bind_zeroblob
> sqlite3_blob_bytes
> sqlite3_blob_close
> sqlite3_blob_open
> sqlite3_blob_read
> sqlite3_blob_write
> sqlite3_busy_handler
> sqlite3_busy_timeout
> sqlite3_changes
> sqlite3_clear_bindings
> sqlite3_close
> sqlite3_collation_needed
> sqlite3_collation_needed16
> sqlite3_column_blob
> sqlite3_column_bytes
> sqlite3_column_bytes16
> sqlite3_column_count
> sqlite3_column_decltype
> sqlite3_column_decltype16
> sqlite3_column_double
> sqlite3_column_int
> sqlite3_column_int64
> sqlite3_column_name
> sqlite3_column_name16
> sqlite3_column_text
> sqlite3_column_text16
> sqlite3_column_type
> sqlite3_column_value
> sqlite3_commit_hook
> sqlite3_complete
> sqlite3_complete16
> sqlite3_create_collation
> sqlite3_create_collation16
> sqlite3_create_collation_v2
> sqlite3_create_function
> sqlite3_create_function16
> sqlite3_create_module
> sqlite3_create_module_v2
> sqlite3_data_count
> sqlite3_db_handle
> sqlite3_declare_vtab
> sqlite3_enable_load_extension
> sqlite3_enable_shared_cache
> sqlite3_errcode
> sqlite3_errmsg
> sqlite3_errmsg16
> sqlite3_exec
> sqlite3_expired
> sqlite3_extended_result_codes
> sqlite3_file_control
> sqlite3_finalize
> sqlite3_free
> sqlite3_free_table
> sqlite3_get_autocommit
> sqlite3_get_auxdata
> sqlite3_get_table
> sqlite3_global_recover
> sqlite3_interrupt
> sqlite3_last_insert_rowid
> sqlite3_libversion
> sqlite3_libversion_number
> sqlite3_load_extension
> sqlite3_malloc
> sqlite3_memory_alarm
> sqlite3_memory_highwater
> sqlite3_memory_used
> sqlite3_mprintf
> sqlite3_mutex_alloc
> sqlite3_mutex_enter
> sqlite3_mutex_free
> sqlite3_mutex_leave
> sqlite3_mutex_try
> sqlite3_open
> sqlite3_open16
> sqlite3_open_v2
> sqlite3_overload_function
> sqlite3_prepare
> sqlite3_prepare16
> sqlite3_prepare16_v2
> sqlite3_prepare_v2
> sqlite3_profile
> sqlite3_progress_handler
> sqlite3_realloc
> sqlite3_release_memory
> sqlite3_reset
> sqlite3_reset_auto_extension
> sqlite3_result_blob
> sqlite3_result_double
> sqlite3_result_error
> sqlite3_result_error16
> sqlite3_result_error_nomem
> sqlite3_result_error_toobi

Re: [sqlite] .lib file?

[Fred Williams]

Paul,

If you wish I can send yoou a SQLite3.lib file I just generated using my old
Borland C++ Builder 5 Lib utility.  Can't attach it here so contact me:

fwillia...@gmail.com

And I'll attach it to a reply.

Fred


-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Doug
Sent: Saturday, July 25, 2009 11:24 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] .lib file?


Hi Paul --

When I build SQLite (from the amalgamation) into a DLL VS2008 (and earlier
as I recall) automatically creates an import library in the same directory
as the .DLL file.  I also _used_ to run the following command separately to
create the import lib:

link /lib /def:sqlite3.def

I haven't kept my sqlite3.def file up to date, but it's fairly recent if you
want to use it.  Since we can't post files to the newsgroup, I'll append it
here.

Doug


EXPORTS
sqlite3_aggregate_context
sqlite3_aggregate_count
sqlite3_auto_extension
sqlite3_bind_blob
sqlite3_bind_double
sqlite3_bind_int
sqlite3_bind_int64
sqlite3_bind_null
sqlite3_bind_parameter_count
sqlite3_bind_parameter_index
sqlite3_bind_parameter_name
sqlite3_bind_text
sqlite3_bind_text16
sqlite3_bind_value
sqlite3_bind_zeroblob
sqlite3_blob_bytes
sqlite3_blob_close
sqlite3_blob_open
sqlite3_blob_read
sqlite3_blob_write
sqlite3_busy_handler
sqlite3_busy_timeout
sqlite3_changes
sqlite3_clear_bindings
sqlite3_close
sqlite3_collation_needed
sqlite3_collation_needed16
sqlite3_column_blob
sqlite3_column_bytes
sqlite3_column_bytes16
sqlite3_column_count
sqlite3_column_decltype
sqlite3_column_decltype16
sqlite3_column_double
sqlite3_column_int
sqlite3_column_int64
sqlite3_column_name
sqlite3_column_name16
sqlite3_column_text
sqlite3_column_text16
sqlite3_column_type
sqlite3_column_value
sqlite3_commit_hook
sqlite3_complete
sqlite3_complete16
sqlite3_create_collation
sqlite3_create_collation16
sqlite3_create_collation_v2
sqlite3_create_function
sqlite3_create_function16
sqlite3_create_module
sqlite3_create_module_v2
sqlite3_data_count
sqlite3_db_handle
sqlite3_declare_vtab
sqlite3_enable_load_extension
sqlite3_enable_shared_cache
sqlite3_errcode
sqlite3_errmsg
sqlite3_errmsg16
sqlite3_exec
sqlite3_expired
sqlite3_extended_result_codes
sqlite3_file_control
sqlite3_finalize
sqlite3_free
sqlite3_free_table
sqlite3_get_autocommit
sqlite3_get_auxdata
sqlite3_get_table
sqlite3_global_recover
sqlite3_interrupt
sqlite3_last_insert_rowid
sqlite3_libversion
sqlite3_libversion_number
sqlite3_load_extension
sqlite3_malloc
sqlite3_memory_alarm
sqlite3_memory_highwater
sqlite3_memory_used
sqlite3_mprintf
sqlite3_mutex_alloc
sqlite3_mutex_enter
sqlite3_mutex_free
sqlite3_mutex_leave
sqlite3_mutex_try
sqlite3_open
sqlite3_open16
sqlite3_open_v2
sqlite3_overload_function
sqlite3_prepare
sqlite3_prepare16
sqlite3_prepare16_v2
sqlite3_prepare_v2
sqlite3_profile
sqlite3_progress_handler
sqlite3_realloc
sqlite3_release_memory
sqlite3_reset
sqlite3_reset_auto_extension
sqlite3_result_blob
sqlite3_result_double
sqlite3_result_error
sqlite3_result_error16
sqlite3_result_error_nomem
sqlite3_result_error_toobig
sqlite3_result_int
sqlite3_result_int64
sqlite3_result_null
sqlite3_result_text
sqlite3_result_text16
sqlite3_result_text16be
sqlite3_result_text16le
sqlite3_result_value
sqlite3_result_zeroblob
sqlite3_rollback_hook
sqlite3_set_authorizer
sqlite3_set_auxdata
sqlite3_sleep
sqlite3_snprintf
sqlite3_soft_heap_limit
sqlite3_sql
sqlite3_step
sqlite3_thread_cleanup
sqlite3_threadsafe
sqlite3_total_changes
sqlite3_trace
sqlite3_transfer_bindings
sqlite3_update_hook
sqlite3_user_data
sqlite3_value_blob
sqlite3_value_bytes
sqlite3_value_bytes16
sqlite3_value_double
sqlite3_value_int
sqlite3_value_int64
sqlite3_value_numeric_type
sqlite3_value_text
sqlite3_value_text16
sqlite3_value_text16be
sqlite3_value_text16le
sqlite3_value_type
sqlite3_version
sqlite3_vfs_find
sqlite3_vfs_register
sqlite3_vfs_unregister
sqlite3_vmprintf



> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Paul Claessen
> Sent: Saturday, July 25, 2009 10:49 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] .lib file?
>
> Thanks Pavel.
>
> Two points though:
>
> 1. The amalgated sources were, apparently, not written with MS Visual
> Study in mind, since compiling it results in over 100 errors
> (mostly invalid pointer conversions)
> 2. If I have a number of apps, it would really be more efficient to use
> the DLL.
>
> I'm sure I can fix all the pointer casts (shouldn't be necessary if the
> code used more consistent types!), but that would take me a
> lot of time, plus, there should be a way to simply use the .dll: since
> there IS a windows console app, there must be either a .lib
> file somewhere, or there is an alternative way of using DLL's from a
> windows console app, that I'm not aware of.
>
> Kind regards,
>
> ~ Paul Claessen
>
>
> > -Original Message-
> > From: Pavel 

Re: [sqlite] Installing SQLite

[Fred Williams]

That might be an option to consider.  But, I think there might be a rather
small number of potential SQLite users interested.  I would think the group
with the greatest benefit of that kind of package would be students and
serious rookies.

Most users I feel either pre possess the required expertise to work with the
current source package or, like me, prefer to leave the implementation
details to those supplying the pre packaged .DLL's.  I could work from
source, but why bother?  I guess I'm getting lazy or am too willing to
accept what is prepackaged.

My main purpose is to utilize a small tightly implemented database that I do
not have to deal with below the prepackaged level.  If that was not possible
with SQLite, I would still be looking I suppose.  I would suspect that the
majority of users are pretty much in my camp.  I'll go so far as to say
20/80, the golden rule of most everything in life.  With 20 being the Gurus
or wana'bes and 80 the rest of us.

BTW, I'll go further and say that fewer than 20 of the above 80 even know
about this mailing list ;-)

Dr. Hipp may be able to back this up with some general numbers if he wishes
to totally waste his time...

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Vance E. Neff
Sent: Thursday, July 23, 2009 1:06 PM
To: j...@kreibi.ch; General Discussion of SQLite Database
Subject: Re: [sqlite] Installing SQLite


If there was a zip file that included an open source compiler and linker
and a well commented makefile along with SQLite's source code so that
anyone (at least under Windows) can generate the version SQLite dll and
command shell that they want without having to search for tools, I think
more people would be more likely to experiment with some of the non
standard features.

Vance

Jay A. Kreibich wrote:
>   Grrr I didn't meant to send this just yet.  But since I did, I
>   guess I need to finish it.
>
> On Thu, Jul 23, 2009 at 10:50:37AM -0500, Jay A. Kreibich scratched on the
wall:
>> On Thu, Jul 23, 2009 at 09:46:24AM -0400, Wilson, Ron P scratched on the
wall:
>>
>>> I think the OP just has the wrong expectations.
>>   Yes, and no.  While SQLite doesn't have a one-click-to-install
>>   download, I have to agree that the current build and distribution
>>   state of SQLite is... let's just say "less than ideal."  I've been
>>   writing a lot of documentation on just this issue, and unless you
>>   want a perfect vanilla install, there are definitely a lot of hoops
>>   you have to jump through compared to most open-source projects of
>>   similar design.
>>
>>   A few versions ago we transitioned from a traditional UNIX style
>>   project, complete with "configure" script, to having the amalgamation
>>   be the "standard" distribution.  I've always felt like that
>>   transition is incomplete, and we've never gotten back to where we
>>   were before.
>>
>>   The amalgamation works well enough if what you want is mostly
>>   defaults.  The issue is that, while you can change a few of the
>>   #defines for numeric defaults, most of the more interesting build
>>   options won't work with the amalgamation.  Only that's it.  As the
>>   website clearly states, there is no other supported option.
>
>   The "by the file" distribution is bad enough, but you're totally out
>   of luck if you need to go to the tree for some of the really complex
>   build options.  Of course, the "by the file" distribution is there
>   and available for download because a lot of people still need it, but
>   apparently not enough to justify keeping it updated.  That's a bit of
>   a contradiction... for a piece of software that prides itself on its
>   testing systems, the end-users sees a whole lot of "there but not
>   supported; it might work it might not; you're on your own" stuff.
>   That's normally a big red flag in my book.  Stuff should be there, be
>   supported, and be documented, or it shouldn't.  The current situation
>   is only easily understandable if you've been following SQLite for a few
>   years.
>
>   And the OP is right... the build docs suck.  There are no build docs
>   for most downloads, just a archive file with source.  No Makefiles, no
>   nothing.  There is no "how to build" on the documentation page (just
>   docs on build options) and the Wiki pages on building and the
>   amalgamation are so out of date that they have negative value, doing
>   little more than confusing people.
>
>   I realize that you might take the argument that anyone smart enough
>   need to build the SQLite engine into an application should be able to
>   figure that out, and with enough time, maybe that's right a fair
>   percentage of the time.  On the other hand, the whole point of moving
>   to the amalgamation was to simplify putting SQLite into an
>   application.  I think overall it does this, but only if you're
>   working from the default everything.  The amalgamation might be
>   

Re: [sqlite] Installing SQLite

[Fred Williams]

I think you guys are most likely feeding a Troll, or the original poster
might ought to contact his IS support department, or enroll in some
introductory basic home computer continuing education courses in his local
area.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of John Machin
Sent: Thursday, July 23, 2009 10:02 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Installing SQLite


On 23/07/2009 6:48 AM, Rich Shepard wrote:
> On Wed, 22 Jul 2009, scabral wrote:
>
>> When i download the sqlite-amalgamation-3_6_16.zip i get 3 text files:
>>
>> sqlite3   C File
>> sqlite3   H File
>> sqlite3ext H File
>
>> what am i supposed to do with those?
>
>  Well, based on what others wrote about your initial comments, I suggest
> that you replace XP with a linux distribution. Then you can compile that
> source code all by yourself.

No need. One can compile sqlite on Windows all by ones's own self using
a variety of $-free C/C++ compilers (gcc/mingw32 (FOSS), Borland, and
there's a command-line compiler somewhere inside the 100Mb VS2009
Express download from the dark tower of Redmond).

> On the other hand, if you insist on sticking
> with Microsoft, download one of the pre-built Winduhs .zip files as I
> indicated in my previous message.

The pre-built Windows .zip files are paralleled one-to-one by pre-built
linux .gz files ... someone must consider that inability to compile
one's way out of a wet paper bag is platform-independent :-)
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] The SQL Guide to SQLite

[Fred Williams]

Reminds me of the old days BTW (Before The Web) when the News Net's main
recreation was "C" language curly brackets formatting flame wars :-)

I was kind'a wondering what on earth is so complicated in SQLite that would
take an entire book to cover?  Is it a thin book?  How 'bout big print for
us old _arts.

Fred

Miss the old signature "Tag line" message terminators as well, as most times
they were much more entertaining than the post they were attached to.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of P Kishor
Sent: Sunday, July 19, 2009 8:06 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] The SQL Guide to SQLite


On Sat, Jul 18, 2009 at 8:55 PM,  wrote:
> Rick,
> This a very comon way for citations in ACM and IEEE papers.
> Others such as ESA use "Lname" year.
>
..

Good grief... this is the most ridiculous thread. Poor Rick. All he
said was that there were weird looking citations in a computer
software "how-to" book. He ended up getting a treatise on citation
styles. In solidarity with Rick, I have almost 10 computer how-to
books, and while they do have footnotes, none of them have citations
of any sort whatsoever.

Now, can we please have a new thread where Rick tells us whether the
book is any good or not?


--
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
---
Assertions are politics; backing up assertions with evidence is science
===
Sent from Madison, WI, United States
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Columns] Keeping internal + beautified names?

[Fred Williams]

For overall performance and efficiency, I recommend you keep the "pretty" in
the GUI where such things are traditionally implemented.  Pick two of three:
"COOL, Fast, Tight."

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Gilles Ganault
Sent: Tuesday, July 14, 2009 11:02 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] [Columns] Keeping internal + beautified names?


On Sat, 11 Jul 2009 09:38:27 -0700, Jim Dodgen
 wrote:
>I would just use:
>
>SELECT id AS Identification FROM foobar

Thanks. This is what I already use for displaying the results, but
then I'm stuck when I need to perform INSERT/UPDATES because I need to
get the actual columns names :-/

It'd be cool if each column in a table could have an internal name and
an external name.

Is there a better way than either using the very first row in each
table or keeping a table for this purpose?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Datatypes (D. Richard Hipp)

[Fred Williams]

I'm aware of the limitations of the 92 Standard, as I too have suffered the
same fate.  But one thing for sure, conforming to the standard certainly
makes migration between "Standard" implementations somewhat simpler.

I'm not speaking standardally but speaking logically. (i.e. Mr. Spock,
logical) I still feel an error message rather than an unrequested result to
be much more palatable and much less potentially destructive.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Simon Slavin
Sent: Tuesday, June 16, 2009 12:23 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Datatypes (D. Richard Hipp)



On 16 Jun 2009, at 5:32pm, Fred Williams wrote:

> Still think, logically speaking, the construct should throw an error
> message, rather than make stealth changes to the expected result.

I suppose it might be possible to provide SQLite with a 'conform to
standard' mode you could select using a PRAGMA.  However, I used to
have to work entirely within SQL92 (working for a big client which
insisted on standard conformance) and it was a pain: the standard
lacks many features we find very useful.

Simon.
--
  http://www.hearsay.demon.co.uk | I'd expect if a computer was involved
 | it all would have been much worse.
No Buffy for you.|-- John "West" McKenna
Leave quickly now. -- Anya   |  THE FRENCH WAS THERE

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Datatypes (D. Richard Hipp)

[Fred Williams]

I'll settle for wishful thinking if that is what it takes to clone a table
schema with a Create...Select...statement.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Igor Tandetnik
Sent: Tuesday, June 16, 2009 12:23 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Datatypes (D. Richard Hipp)


Fred Williams <f.willi...@verizon.net>
wrote:
> What!  The standard is lacking?  Will wonders never cease?
>
> Thanks, you saved me from some boring reference reading.
>
> Still think, logically speaking, the construct should throw an error
> message, rather than make stealth changes to the expected result.

But why do you expect a particular result different from the one you
actually get? What basis do you have for your expectations, other than
wishful thinking?

Igor Tandetnik



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Datatypes (D. Richard Hipp)

[Fred Williams]

What!  The standard is lacking?  Will wonders never cease?

Thanks, you saved me from some boring reference reading.

Still think, logically speaking, the construct should throw an error
message, rather than make stealth changes to the expected result.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Igor Tandetnik
Sent: Tuesday, June 16, 2009 10:57 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Datatypes (D. Richard Hipp)


Fred Williams <f.willi...@verizon.net>
wrote:
> Is this a violation of SQL Standards?  Seems like it should be.

As far as I can tell, CREATE TABLE AS SELECT is not part of SQL92
standard at all. If you want to work within the standard, don't use this
construct in the first place.

Igor Tandetnik



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Datatypes (D. Richard Hipp)

[Fred Williams]

Is this a violation of SQL Standards?  Seems like it should be.

I'm not for dumbing down the system to compensate for the occasional idiot
programmer.  After all, we are not the government, nor should we strive to
act like it (IMHO).

If someone chooses to attempt to create a column/table/database name that is
incorrect perhaps they should receive a refreshing error message pointing
out their verbal shortcomings?  Otherwise I think this could break a lot of
good code for the sake of "maybe"...

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Tuesday, June 16, 2009 9:36 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Datatypes (D. Richard Hipp)



>
>
> Ok, I can see this. But I cannot forsee the real implications
> though. If I
> have a statement like
>
> create table mytable(pnumber integer, name varchar(20), primary
> key(pnumber))
>
> what are the reported datatypes? still integer and varchar(20)?


Yes.  But if you do

CREATE TABLE t2 AS SELECT * FROM mytable;

Then the reported datatypes for t2 will be INT and TEXT.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Datatypes (D. Richard Hipp)

[Fred Williams]

Is this a violation of SQL Standards?  Seems like it should be.

I'm not for dumbing down the system to compensate for the occasional idiot
programmer.  After all, we are not the government, nor should we strive to
act like it (IMHO).

If someone chooses to attempt to create a column/table/database name that is
incorrect perhaps they should receive a refreshing error message pointing
out their verbal shortcomings?  Otherwise I think this could break a lot of
good code for the sake of "maybe"...

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Tuesday, June 16, 2009 9:36 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Datatypes (D. Richard Hipp)



>
>
> Ok, I can see this. But I cannot forsee the real implications
> though. If I
> have a statement like
>
> create table mytable(pnumber integer, name varchar(20), primary
> key(pnumber))
>
> what are the reported datatypes? still integer and varchar(20)?


Yes.  But if you do

CREATE TABLE t2 AS SELECT * FROM mytable;

Then the reported datatypes for t2 will be INT and TEXT.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Topics 1 - Re: sqllogictest tool - please help :-)

[Fred Williams]

I think your problems have nothing to do with SQLite, yet.

To begin you need some help related to the "C" programming language.  The
three files you have listed are the "Make", "Source" and "Header" files for
a C program.  You must compile these to develop an executable program.

Once you have accomplished this, you can start learning SQLite.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of tsachi ofir
Sent: Wednesday, June 10, 2009 2:27 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Topics 1 - Re: sqllogictest tool - please help :-)


>
> Hi,

   we are working with SQLite in our company.
   we need a tool that check if SQL returns the correct answer and to
compare with MySQL.
   I got a new job and its my first  assignment ( to start working on
sqlogictest) , and I don't understand much about sqllogictest.
   Please help.

   Tsachi


>
> --
>
> Message: 1
> Date: Tue, 9 Jun 2009 16:12:30 -0400
> From: "D. Richard Hipp" 
> Subject: Re: [sqlite] sqllogictest tool - please help :-)
> To: General Discussion of SQLite Database 
> Message-ID: <511286c3-5b52-4f01-8f74-3448d23d8...@hwaci.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Jun 9, 2009, at 10:38 AM, tsachi ofir wrote:
>
> > Hi ,
> > I wont to use the "sqllogictest" program.
>
> Let's start with the basics.  Why do you think you want to use this
> program? What do you think it will accomplish for you?
>
> >
> > I'm using SQLite.
> >
> > I have read the "About Sqllogictest" and didn't fully understand how
> > to work
> > with it.
> > Can you please help on how I can use it? I will be very grateful for
> > your
> > help.
> >
> >   - Where are the files of the program? is it those three files?
> >
> >
> >   1. sqllogictest.mk
> >   2. sqllogictest.h
> >   3. sqllogictest.c
> >
> >
> >   - How can I install it?
> >   - Just to migrate the files to which folder?
> >
> > Thanks for your help.
> >
> > Tsachi Ofir
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Db design question (so. like a tree)

[Fred Williams]

Nothing to do with relational databases, but if you are developing for a
future animal husbandry environment I would plan on supporting clones.  Like
it philosophically or not.

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Ibrahim A
Sent: Thursday, June 04, 2009 5:59 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Db design question (so. like a tree)


Jan schrieb:
> Hi,
>
> I am planning a database for animal breeding. I need to store the
> relations between individuals and therefore I have to build something
> like a tree structure. But of course with two parents (There wont be
> cloned animals in the database .-) afaik)
>
> I read a little bit about
>
> - adjacency list (not very difficult to understand)
> - nested sets (hm, more difficult)
> - b tree (to difficult)
> - ? (something I missed?)
>
> Could anyone give me an advice what to use or what else to read? Maybe
> someone has already done something similar e.g. genealogy.
>
> Bye
> Jan
>
...

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite programmed in C++

[Fred Williams]

Well said!

C++ provides the average programmer "automated" Object Orientation, or
better stated, good programming practices, at a price.  A good C programmer
can equal and most times exceed the results of a C++ programming project.
As previously stated C is really just a lazy man's Assembler, and you can't
get any closer to the hardware, unless you are into machine language,
independently wealthy, with no need for sleep.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Ibrahim A
Sent: Wednesday, June 03, 2009 6:25 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] sqlite programmed in C++


Hi all,

I'd like to comment this topic as well.

I think C is a very good choice for projects like sqlite. The point is
that C is in contrary to C++ very easily portable. If you have the bad
luck that you have to port a programm on a new plattform for which no
compiler suites exist than the choice of C for such a project pays of.

You'll find a few short understandable and editable C-Compiler
implementations on the internet. As an example TCC, LCC or PCC. They are
short enough to port to a new plattform. To port TCC to a new plattform
as an example needs about one week when you have to start from zero
because you only need to refine the code generation interface for the
destined target system.

sqlite uses a few dozen standard function calls and the most of them are
easily to implement in C itself. And don't forget that C is designed as
a portable assembly language so it's really fast.

If you now look at C++ you'll find only two mentionable Compiler
implementations which you can use for a porting task. And these
toolchains require more than the knowledge of C with which you could
port TCC or PCC.

When you look closer to the sqlite code you'll find, that the code uses
objectoriented techniques on many places. Many of the interfaces to
different functionality like vfs or fts are objects in a portable way. A
C++ object is nothing different than a table of functions and data
pointers and this is used in sqlite as well but the difference is, that
this implementation is portable and interchangeable between compilers.
If you would start to use C++ than you would end up compiling a
interface with one compiler and being unable to use this interface from
another compiler or even a compiler with a newer release date. C++ only
supports compile time modularity and no runtime compatibility between
libraries written in this language and compiled with different versions.
The binary implementation of OOP abilities is always proprietary. The
support of the code would be horrible because you'd have to deal with
incompatibilities between different implementations.

To summarize my opinion :

C is the best choice for portable projects like sqlite. C is fast enough
and if you don't have a compiler you can create one. If you don't have a
standard library you can use free libraries.

I would wish that drh would go a step further and avoid using awk and
tcl for the code creation process. This would solve the problem with
Preprocessor definitions which can be set during compile time but where
some have also to be set while you create lemon. It is possible to
exchange each of the awk and tcl scripts which are used during code
generation and the generation of the amalgamation with only C this would
make the whole thing simpler to port and more independent from any
external tools or plattforms and it would also make it possible to use
all of the creation makros while you create the sourcecode.

Ibrahim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite programmed in C++

[Fred Williams]

I figure the only reasons it is written in C is for portability and
Assembler programming is a bitch!

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of P Kishor
Sent: Tuesday, June 02, 2009 10:36 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] sqlite programmed in C++


On Tue, Jun 2, 2009 at 10:33 AM, Sylvain Pointeau
 wrote:
> I didn't mean to program with sqlite in C++ ...
> I just meant to introduce C++ inside SQLite instead of C...
> I would like to understand why SQLite is programmed only in C 

Definitively only DRH can answer. My speculation is -- because ANSI
standard C is the cleanest, most portable language across all the
variety of hardware/OS platforms to which SQLite is ported.

It works, fast, quick, cheap as is evident by, well, by evidence. Why
bother with something more complex, as unnecessary complexity is a
sure recipe for disaster.

>
> Cheers,
> Sylvain
>
> On Tue, Jun 2, 2009 at 5:15 PM,  wrote:
>
>> One of the best and worst things about C++ is its ability to use C code
>> (almost) transparently.  Best because it allows you to use things like
>> SQLite seamlessly in your C++ code. Worst because it allows some
>> programming idioms that are in opposition to good object oriented
>> design.  But let's concentrate on the up-side.
>>
>> There are C++ wrappers to SQLite out there if you care to look for them,
>> but depending upon the complexity of your application you may find you
>> don't need them.  It is easy to contain a SQLite connection inside a
>> class object, easy to compose your queries in a std::string (or a
>> CString depending on your environment and preferences) and fairly easy
>> to get your query results into a container class.
>>
>> While I would never dream of starting from scratch on anything of the
>> size and complexity of SQLite without C++, the STL, and probably Boost,
>> I also would never advocate fixing something that ain't broke. As an
>> applications programmer you can get all the advantages of C++ without
>> any changes to SQLite as written.
>>
>> Just my $0.02 worth.
>>
>> Logan Ratner | Software Engineer | Gas Chromatographs
>> Emerson Process Management | 5650 Brittmoore | Houston | TX | 77041 |
>> USA
>> T +1 713 839 9656 | F +1 713 827 3807
>>
>>
>> logan.rat...@emerson.com-original Message-
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Sylvain Pointeau
>> Sent: Tuesday, June 02, 2009 9:58 AM
>> To: sqlite-users@sqlite.org
>> Subject: [sqlite] sqlite programmed in C++
>>
>> Hello,
>> I would like to know if someone already though about to introduce C++ in
>> SQLite?
>> I just think about a minimal subset of C++ that will not make any
>> performance penalty
>> (like C with classes)
>>
>> is it a performance issue?
>> is it a deployment/compiler issue?
>> or any issue?
>>
>> Please don't make any aggressive reply, I am a very nice guy :-)
>>
>> Cheers,
>> Sylvain
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



--
Puneet Kishor
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Windows XP: How Can I Get Higher CPU usage from SQLite

[Fred Williams]

That's the reason in memory databases are so fast.  If a DB is small enough
you can spool the whole thing into RAM on open and spool it back out on
close.

If you are attempting to use the DB in any kind of multi user environment
client system large cache sizes are going to play H--- with concurrency.

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of jose isaias cabrera
Sent: Sunday, February 22, 2009 10:41 PM
To: pechni...@sandy.ru; General Discussion of SQLite Database
Subject: Re: [sqlite] Windows XP: How Can I Get Higher CPU usage from
SQLite



"Alexey Pechnikov" wrote...

> Hello!
>
> On Sunday 22 February 2009 22:56:36 jose isaias cabrera wrote:
>> I have left everything default, so I have not set any PRAGMA settings.
>
> Try this:
> pragma cache_size=1;
> pragma page_size=16384;
> vacuum;

Wow, thanks.  That did help. Cool, so there was something that I could do.
Here is a question: this DB is shared by other folks, do they each need to
set this when they open or if I set it, it would apply to everyone that
connects to it?

thanks,

josé

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Windows XP: How Can I Get Higher CPU usage from SQLite

[Fred Williams]

Since the dawn of digital computers the CPU has been waiting on the I/O.
Want to go faster?  Get a faster mass storage device.  Then your CPU usage
will most likely jump all the way up to 9% - 14%!

You can't believe what a 300 card per minute 80 column card reader does to
throughput when you use it to replace a 100 card per minute reader!  I know,
been there, done that! :-)

Sit back and watch the flashing lights.  BUT, keep your hands in your
pockets!

Fred

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of jose isaias cabrera
Sent: Sunday, February 22, 2009 1:57 PM
To: General Discussion of SQLite Database
Subject: [sqlite] Windows XP: How Can I Get Higher CPU usage from SQLite



Greetings!

I have a very small database, well, 62.1 MB (65,150,976 bytes), and when I
do a search on it, the CPU only goes to 7% and 12% at the most.  Sometimes
it takes a few seconds to return with the results.  I am not complaining
about the 5-10 seconds of the returning of the result, but I believe that if
the CPU would be used more, the result would return in 1-4 seconds.

I have left everything default, so I have not set any PRAGMA settings.

Any ideas on how to make SQLite use the CPU more since it is sitting there
with System Idle Process 93%.

Any help would be greatly appreciated.

thanks,

josé

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT issue with SQLite 3.6.10

[Fred Williams]

That's what I have always loved about standards!  They are so flexible :-)

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Tuesday, January 27, 2009 9:30 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SELECT issue with SQLite 3.6.10



On Jan 27, 2009, at 10:08 AM, Fred Williams wrote:

>
> Should not the GENERAL.ID be enclosed in double quotes?  Or did I  
> misread
> the SQL Standard?

You can use double-quotes to conform to the SQL standard.  But SQLite  
also allows some non-standard quoting mechanisms for compatibility  
with other database engines.   [...] is used by MS SQL Server.   `...`  
is used by MySQL.


D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT issue with SQLite 3.6.10

[Fred Williams]

Should not the GENERAL.ID be enclosed in double quotes?  Or did I misread
the SQL Standard?

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org]on Behalf Of D. Richard Hipp
Sent: Tuesday, January 27, 2009 8:06 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SELECT issue with SQLite 3.6.10



On Jan 27, 2009, at 5:24 AM, KurDtE wrote:

>
> Dear all,
>
> Yesterday I upgraded my SQLite version from version 3.5.9 to 3.6.10,
> and I
> now experience an issue while making a SELECT on one of my view :
>
> This query was previously working on version 3.5.9 :
> SELECT [GENERAL.ID] FROM VIEW_GENERAL;
>
> where "GENERAL.ID" is the name of a column in the view.
>
> I now get this error : GENERAL.ID : no such column.
> I think it gets confused with the dot, how to make the query
> understand it
> as column name, and not table name + column name ?
>
> Thanks for help,


This is probably due to a change (many would say a "bug fix") in
version 3.6.0:

"The result column names generated for compound subqueries have been
simplified to show only the name of the column of the original table
and omit the table name. This makes SQLite operate more like other SQL
database engines."


D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] seeking storage design assistance

[Fred Williams]

One rule used in basic systems design is: Define the input, define the
output, and the rest will become obvious.  If only it were that simple:-)
But, a point to ponder.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jeff Godfrey
Sent: Wednesday, October 01, 2008 9:10 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] seeking storage design assistance


Stephen Woodbridge wrote:
> It also helps to know how you want to access/manipulate your data and
> what you want to do with it in SQL versus with your application. For
> instance, you could just store all the cad data as a blob, along with
> the attributes in columns.
Steve,

Hmmm... That's an interesting thought.  My initial reaction was "No, I
really need direct SQL access to the coordinate data".  But, thinking
about that a bit more, maybe that's not really true.  As you mentioned,
I guess I really need to work more on the details of what I want to do
with SQL and what I want to do within my application code...

Thanks for the input.

Jeff
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Vista frustrations

[Fred Williams]

I never said a word aboout SQLite.  You ass U Me too much I suspect.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Mark Spiegel
Sent: Thursday, September 18, 2008 11:25 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Vista frustrations


I'm sorry, I have to take issue with that statement.  The design of the
file system/cache manager is not "pitiful".  It strives to provide good
performance in the entire application space, not just your little corner
of it.  It is doing the best it can with the "hint" you've given it.  If
another (or no) hint provides better performance in your application,
who's fault is that?  Do you realize that without the cache manager,
fast I/O would not be possible?  Run on a debug system where only IRP
based I/O is possible any you will be singing another tune in a hurry.
Why do you think these hints are even available?  It is to help you
optimize your application.

The SQLite memory subsystem doesn't work well on my platform  I don't
run around calling SQLite "pitiful".  I recognize that the authors'
implementation(s) is probably a good performance compromise in the
generic case.  If it is a big enough problem (which it is for me), I
write my own version to optimize my performance.  While better, the
integer encoding is not as good as it could be for me.  Does that mean
the SQLite is pitiful?

I should also note that as of the last time I talked to her, Molly is no
longer handling the cache manager.  I believe she has moved back into
the kernel group after a brief departure, but is working on something
else.  I haven't seen the talks that Robert refers to, but suspect they
are close to the versions I have seen in person.  I would bet they are
still very useful and relevant.

Fred Williams wrote:
> Is a sad day when an application program is forced to compensate for
pitiful
> OS design and performance :-(
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Robert Simpson
> Sent: Thursday, September 18, 2008 10:31 AM
> To: 'General Discussion of SQLite Database'
> Subject: Re: [sqlite] Vista frustrations
>
>
> After watching Molly Brown's Channel9 videos on the cache manager, I'm
> convinced the behavior for SQLite should be to not give the filesystem any
> hints about caching and let the cache manager itself figure it out.  The
> exception being Windows CE, where we can confirm that when this flag is
not
> set, the device will use compression in memory and degrade performance.
>
> If that's the general consensus, I'll open a ticket.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Spiegel
> Sent: Thursday, September 18, 2008 7:56 AM
> To: [EMAIL PROTECTED]; General Discussion of SQLite Database
> Subject: Re: [sqlite] Vista frustrations
>
> FILE_FLAG_RANDOM_ACCESS and FILE_FLAG_SEQUENTIAL_SCAN are hints to the
> cache manager (CC) in Windows and the underlying file system(s).  With
> respect to the cache manager, it is going to affect whether or not there
> is read ahead, how much read ahead will be used, and how long data will
> remain in the cache (or another way, how quickly it will be dropped).
> It has been some time since I've talked to the Queen of Cache Manger
> about this, but as I recall CC will try to figure out what you are doing
> if you don't give it a hint.  If you do give it a hint, then it is going
> to run with that hint no matter what the cost.  Note that CC or the file
> system are perfectly within their right to ignore your hints.  CC
> generally does honor them.  NTFS, well that's another matter.
>
> It has been MY experience (YMMV) that database and temp file reads are
> fairly random.  Database files also have the "nice" property that read
> and writes are often sector (page) aligned.  Journal files should be
> opened for sequential scan and are generally not sector (page) aligned.
> Setting SQLite aside for a moment, for very large files that are only
> going to be touched in a few places FILE_FLAG_RANDOM_ACCESS can show
> huge performance gains.  However, if most or all of a file is going to
> be touched, even in random order, then it doesn't get you much and can
> hurt you.  Most SQLite data bases _probably_ fall into that second
> case.  If you have enough memory and a small enough file such that the
> cache manager can hold the entire file, you are golden.  That's why some
> people see such great SQLite performance by just sequentially reading
> their DB files before running their SQLite application.
>
> The elephants in the room with that previous paragraph is 1) the amount
> of RAM in the system and 2) the other applications running.  Windows
> will try to share its resources among all the 

Re: [sqlite] Vista frustrations

[Fred Williams]

Is a sad day when an application program is forced to compensate for pitiful
OS design and performance :-(

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert Simpson
Sent: Thursday, September 18, 2008 10:31 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Vista frustrations


After watching Molly Brown's Channel9 videos on the cache manager, I'm
convinced the behavior for SQLite should be to not give the filesystem any
hints about caching and let the cache manager itself figure it out.  The
exception being Windows CE, where we can confirm that when this flag is not
set, the device will use compression in memory and degrade performance.

If that's the general consensus, I'll open a ticket.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Spiegel
Sent: Thursday, September 18, 2008 7:56 AM
To: [EMAIL PROTECTED]; General Discussion of SQLite Database
Subject: Re: [sqlite] Vista frustrations

FILE_FLAG_RANDOM_ACCESS and FILE_FLAG_SEQUENTIAL_SCAN are hints to the
cache manager (CC) in Windows and the underlying file system(s).  With
respect to the cache manager, it is going to affect whether or not there
is read ahead, how much read ahead will be used, and how long data will
remain in the cache (or another way, how quickly it will be dropped).
It has been some time since I've talked to the Queen of Cache Manger
about this, but as I recall CC will try to figure out what you are doing
if you don't give it a hint.  If you do give it a hint, then it is going
to run with that hint no matter what the cost.  Note that CC or the file
system are perfectly within their right to ignore your hints.  CC
generally does honor them.  NTFS, well that's another matter.

It has been MY experience (YMMV) that database and temp file reads are
fairly random.  Database files also have the "nice" property that read
and writes are often sector (page) aligned.  Journal files should be
opened for sequential scan and are generally not sector (page) aligned.
Setting SQLite aside for a moment, for very large files that are only
going to be touched in a few places FILE_FLAG_RANDOM_ACCESS can show
huge performance gains.  However, if most or all of a file is going to
be touched, even in random order, then it doesn't get you much and can
hurt you.  Most SQLite data bases _probably_ fall into that second
case.  If you have enough memory and a small enough file such that the
cache manager can hold the entire file, you are golden.  That's why some
people see such great SQLite performance by just sequentially reading
their DB files before running their SQLite application.

The elephants in the room with that previous paragraph is 1) the amount
of RAM in the system and 2) the other applications running.  Windows
will try to share its resources among all the applications running as
best it can.

I have not seen any "bugs" in SQLite in this area.  It gives a
reasonable hint for the general case.  To be fair however, I should note
that I have my own VFS.  It does unbuffered I/O for database files and
sequential, cached I/O for journal files.  If you think you can get
better performance with different flags, create your own VFS, starting
with the Windows VFS and make the changes.  You can get as sophisticated
with your hints as you want.  You can write your own caching system if
you've ingested way too much caffeine.  (Did I mention that the VFS
stuff is great!)

I would not as a general rule advise people (customers) to change the
way their Windows system caches globally for the benefit of one of your
applications.  Eventually, that is going to bite you with some support
calls.

Jay A. Kreibich wrote:
> On Wed, Sep 17, 2008 at 06:00:45PM -0700, Roger Binns scratched on the
wall:
>
>
>> The second is that SQLite when opening a file under Windows explicitly
>> tells Windows that the file will be used for random access even though
>> that is not the case.  Windows uses this hint to override its builtin
>> heuristics which can cause bug #1.
>>
>
>
>> Bug #2 is that SQLite is lying to the operating system and could result
>> in performance degradation if the operating system actually pays
>> attention to the hint.
>>
>
>   SQLite is not "lying."  After poking around a bit to refresh my
>   understanding of SQLite's file structure, I think it is safe to say
>   that SQLite will almost never do a sequential file read, even if
>   you're doing a sequential table scan.
>
> sequential table scan != sequential file access
>
>   There are some specific situations when you might get bursts of
sequential
>   reads, but only for very specific page layouts with very specific
>   types of queries.  In short, not the common case.  Furthermore, even
>   those patterns can get broken up and shuffled around depending on the
>   state of SQLite's page cache-- especially if it is bumped up a few
>   dozen megs.  So simply running different types of queries can 

Re: [sqlite] Vista frustrations

[Fred Williams]

Have you ever actually used a version of Windows?

ANY OS that attempts to read in a xGigibyte file into real memory to the
detriment of the entire system load is not working correctly.  Call it a bug
or a feature it still sucks.

I expect nothing less from Microsoft with each new version.  I recommend you
wait for, it looks like, maybe, Service Pack 6 before you get serious about
Vista.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Roger Binns
Sent: Wednesday, September 17, 2008 4:02 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Vista frustrations


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Simpson wrote:
> The purpose of a cache is to improve performance and responsiveness.  Any
> cache that uses all physical memory, forces all other apps to the paging
> file

All current operating systems do this, using heuristics to determine how
much of each running application to leave in memory while using "spare"
memory for filesystem cache and dynamically changing allocation based on
demand.  Sometimes they mess up to the detriment of idle applications.
However that is not the bit I am talking about as it is not controlled
by flags when opening files and instead is part of the core operating
system code.  (You often see this issue when copying files larger than RAM).

What is under discussion is how the operating system is using the cache
that it does decide to allocate for SQLite.  If you tell it that a file
is sequential access then that means that read ahead is good and that
data already read can be discarded.  If you tell it that a file is
random access then read ahead is bad (it has the disk occupied when the
next random request comes in) and already read data should be kept.
SQLite does not know and should be leaving it up to the operating
system.  Your tests prove that when that is done on Vista, performance
of SQLite is better and other applications are less adversely affected.

> The real frustration is that this seems to be a rather obvious bug in
Vista,
> and definitely not SQLite's responsibility.

This is conflating two issues.  One is the tradeoff between RAM usage
for cache vs idle applications.  You can argue that is a bug, or more
accurately there are circumstances under which the tradeoff picks wrong
values, and is very hard to get right.  Example underlying details are
at http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

The second issue is the performance differences when random access,
sequential and no flags are given while opening the file and the
resulting performance.  In this case a file is accessed mostly
sequentially but the random access flag is given.  Performance was worse
than letting the operating system use its own heuristics.  That is
hardly surprising or a bug.

Roger

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI0XBYmOOfHg372QQRAmKfAJ4pWVfZ8LS2ET+Y55FGT3Am9wCfZg4e
McaZrcLUXQJhU7i1Gw5+cRk=
=CQg5
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Vista frustrations

[Fred Williams]

Possibly the reason a large number of us are still running Win 2000 :-)

It seems to be the least Windows like Windoze ever released...

When follow on support degrades to an untenable level, I'll either switch to
Linux with a Windoze emulator or maybe run whatever the future ruler of the
Universe (Google) tells me to :-)

By then, I figure to be carrying around a holographic 42" 3-D display,
surround sound cell phone anyhow.  BTW, that will have the same form factor
as the "Star trek Next Generation", Communicator.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert Simpson
Sent: Wednesday, September 17, 2008 9:54 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Vista frustrations


The real frustration is that this seems to be a rather obvious bug in Vista,
and definitely not SQLite's responsibility.  IMO setting the flag is the
"right thing to do" -- but at the same time, I don't expect any favors from
Microsoft in fixing this any time soon.  Meanwhile all those poor Vista
people need SQLite to work well with their OS.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roger Binns
Sent: Wednesday, September 17, 2008 1:18 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Vista frustrations

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Simpson wrote:
> To me this seems like an obvious bug in Vista,

Actually I'd argue that it is behaving as designed.  Generally
filesystem code will try to detect what is going on under the hood.  In
particular if it looks like you are doing sequential access(*) then they
will start doing read ahead, whereas read ahead is a waste for random
access.  By using the sequential or random flags you are explicitly
telling the filesystem to ignore its heuristics and do as you say only.

Since SQLite cannot tell in advance whether access is almost entirely
random or almost entirely sequential, it makes far more sense to let the
operating system use its builtin heuristics and optimise accordingly.

(*) Sun's ZFS can even detect strided sequential access - ie reading X
amount of data every Y kilobytes.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI0L0vmOOfHg372QQRAk+7AKCEloS0d+xB+M2C/Bap38ilZZ8tVACfciC4
vMfbYMNVV9k6CNR7hpSQo6A=
=AXGU
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] best language match for SQLite?

[Fred Williams]

I haven't met a real programmer since I wrote my last TASM program quite a
few years ago. :-(

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of palmer ristevski
Sent: Tuesday, September 16, 2008 11:19 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] best language match for SQLite?



"And of course, Perl is always best. :)"

That's  right brother!
Educate them , Educate them i say!

P.

> Date: Tue, 16 Sep 2008 11:13:27 -0500
> From: [EMAIL PROTECTED]
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] best language match for SQLite?
>
> SQLite is written in C, and its creators seem to be fond of TCL, so
> those are 2 good choices, but I don't think there is a most ideal
> language for anything - it all depends on balancing what you need to do
> and what you want to learn.
>
> And of course, Perl is always best. :)
>
> g
>
> -Original Message-
> From: Patrick [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 16, 2008 10:51 AM
> To: General Discussion of SQLite Database
> Subject: [sqlite] best language match for SQLite?
>
> I am a beginner to intermediate Python Programmer. I can use SQLite with
>
> it just fine but it is my understanding that relational database and
> object oriented programming our not the perfect marriage.
>
> I was just wondering if anyone had an opinion on the most ideal language
>
> to use with SQLite?
>
> I love Python but I LOVE SQLite, I would learn another language just to
> use it better-Patrick
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_
See how Windows connects the people, information, and fun that are part of
your life.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Entity Relationship Diagram Tool for SQLite

[Fred Williams]

What is so unique to SQLite that it would require its very own Entity
Relationship engine?

Relational databases are relational databases.  Granted some are "more"
relational than others, but that is where the designer's mind is required to
function above a video game level.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Abrames
Sent: Wednesday, September 03, 2008 12:55 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] Entity Relationship Diagram Tool for SQLite


Hello,

I am looking for an Entity Relationship Diagram Tool for SQLite.  Thank you
in advance.

David Abrames


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 2 Questions from a newbie

[Fred Williams]

1.  Third Normal, as in "Database normalization."  (Database 101)  No
offence intended, you said you are a beginner.

2.  Right.  My "unlimited" stock and prices advantage.  No creating a table
for each new stock.  No creating a table or adding columns (Both time and
logically intensive.) for each new stock or price.  And just generally
FLEXIBILITY without extreme pain!

3.  The date and time the price was quoted.

4.  Exactly.

A good book:  Oracle,  "Case Method, Entity Relationship Modeling."

Good luck!

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of cstrader
Sent: Tuesday, August 19, 2008 12:24 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] 2 Questions from a newbie


OK, this seems really helpful, but I'm afraid you've lost me a bit.

1.  Third normal??? :)

2.  Your idea would be to have one table that's relatively static, with the
names (and perhaps other data) of the stocks, a 2nd table that holds prices?
I'm not sure I see the advantage of this approach.

3.  What's "Instance DateTime?"

4.  Are you saying that I could use "GROUP BY" to get daily, monthly,
yearly, etc?

Thanks, very helpful...just what I'm needing!


> Third normal says:
>
> Table:  Stock
> ID Integer Primary Key,
> Symbol Varchar(n),
> ... Other stuff 
>
> Table: DaylyPrice (I'd call it "Price")
> StockID Integer  (Foreign key: Stock:ID)
> Instance DateTime
> Price Integer (Price times 100/1000/1, Your choice)
>
> Then you can have virtually unlimited stocks with virtually unlimited
> prices.  Price sampling can be done at any rate (i.e. seconds, hourly,
> daily, weekly, etc.)  Your queries would determine "closing price" hourly,
> dally, monthly, etc.
>
> Thoughts to ponder:  How to handle stock "splits", Mergers, and ?
>
> Fred
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of cstrader
> Sent: Tuesday, August 19, 2008 11:53 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] 2 Questions from a newbie
>
>
> OK, cool idea... let me try that.
>
>
> - Original Message -
> From: "Jeff Hamilton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "General Discussion of SQLite Database"
> 
> Sent: Tuesday, August 19, 2008 12:51 PM
> Subject: Re: [sqlite] 2 Questions from a newbie
>
>
>> If all 2,400 tables have the same 9 columns you could try using a
>> single table and adding a column for the ticker of the stock and then
>> add an index to that column to allow quick lookups based on the
>> ticker.
>>
>> -Jeff
>>
>> On Tue, Aug 19, 2008 at 9:44 AM, .:UgumugU:. <[EMAIL PROTECTED]> wrote:
>>> Hi cstrader,
>>>
>>> Just send some table structure and the explain what you are trying todo.
>>> In my opinion it is not a good way to deal with 2400 tables :)
>>>
>>> ugumugu
>>>
>>> cstrader yazm?s,:
 I'm just starting with SQLite (from vb.net) and could use some advice.

 I have a set of 2400 (could get substantially higher) tables in a
 single
 database (each table contains daily stock prices for a different
 stock).
 Each table has 9 columns (all text for now) and some several thousand
 rows.
 So far so good.

 I need to read those tables sequentially and operate on them.  It takes
 about 18 seconds to open each of  the tables in sequence.  (i.e. loop
 through 2400 tables with a select command opening each one)

 First question... does that sound about right in terms of speed?  Is
 there a
 way to store the data that might be faster?  The data are primarily
 single
 precision -- I'm using text format, but perhaps that's not best?

 Second question:

 When I open each table I need to add some blank columns to it.  So I
 include
 some "0 as NewCol" lines to create the new columns with initial 0s.

 However, adding 20 new columns in this manner increases the total time
 for
 the loop from 19 seconds to  49 seconds.  This seems like a long time.
 Is
 there a faster way to get these empty columns in?

 More questions later I'm sure...

 Thanks in advance

 cs

 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing 

Re: [sqlite] 2 Questions from a newbie

[Fred Williams]

Third normal says:

Table:  Stock
ID  Integer Primary Key,
Symbol  Varchar(n),
... Other stuff 

Table: DaylyPrice (I'd call it "Price")
StockID Integer  (Foreign key: Stock:ID)
InstanceDateTime
Price   Integer (Price times 100/1000/1, 
Your choice)

Then you can have virtually unlimited stocks with virtually unlimited
prices.  Price sampling can be done at any rate (i.e. seconds, hourly,
daily, weekly, etc.)  Your queries would determine "closing price" hourly,
dally, monthly, etc.

Thoughts to ponder:  How to handle stock "splits", Mergers, and ?

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of cstrader
Sent: Tuesday, August 19, 2008 11:53 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] 2 Questions from a newbie


OK, cool idea... let me try that.


- Original Message -
From: "Jeff Hamilton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "General Discussion of SQLite Database"

Sent: Tuesday, August 19, 2008 12:51 PM
Subject: Re: [sqlite] 2 Questions from a newbie


> If all 2,400 tables have the same 9 columns you could try using a
> single table and adding a column for the ticker of the stock and then
> add an index to that column to allow quick lookups based on the
> ticker.
>
> -Jeff
>
> On Tue, Aug 19, 2008 at 9:44 AM, .:UgumugU:. <[EMAIL PROTECTED]> wrote:
>> Hi cstrader,
>>
>> Just send some table structure and the explain what you are trying todo.
>> In my opinion it is not a good way to deal with 2400 tables :)
>>
>> ugumugu
>>
>> cstrader yazm?s,:
>>> I'm just starting with SQLite (from vb.net) and could use some advice.
>>>
>>> I have a set of 2400 (could get substantially higher) tables in a single
>>> database (each table contains daily stock prices for a different stock).
>>> Each table has 9 columns (all text for now) and some several thousand
>>> rows.
>>> So far so good.
>>>
>>> I need to read those tables sequentially and operate on them.  It takes
>>> about 18 seconds to open each of  the tables in sequence.  (i.e. loop
>>> through 2400 tables with a select command opening each one)
>>>
>>> First question... does that sound about right in terms of speed?  Is
>>> there a
>>> way to store the data that might be faster?  The data are primarily
>>> single
>>> precision -- I'm using text format, but perhaps that's not best?
>>>
>>> Second question:
>>>
>>> When I open each table I need to add some blank columns to it.  So I
>>> include
>>> some "0 as NewCol" lines to create the new columns with initial 0s.
>>>
>>> However, adding 20 new columns in this manner increases the total time
>>> for
>>> the loop from 19 seconds to  49 seconds.  This seems like a long time.
>>> Is
>>> there a faster way to get these empty columns in?
>>>
>>> More questions later I'm sure...
>>>
>>> Thanks in advance
>>>
>>> cs
>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Proposed removal of (mis-)feature

[Fred Williams]

Henceforth and forward:  Let the standards violator suffer his just
rewards!" :-)

Dr., your just trying to supply the worlds greatest database, not take a
bunch of slovenly coders to raise...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of D. Richard Hipp
Sent: Thursday, August 07, 2008 12:26 PM
To: General Discussion of SQLite Database
Subject: [sqlite] Proposed removal of (mis-)feature


String literals in SQL are suppose to be enclosed in single-quotes -
Pascal-style.  Double-quotes are used around table and/or column names
in cases where the name would otherwise be a keyword or when the name
contains non-standard characters.

But SQLite tries to be flexible and accommodating.  To this end, it
accepts some non-standard quoting mechanisms:

1.  Names can be enclosed in [...] for compatibility with Access
and SQLServer.
2.  Names can be enclosed in grave accents for compatibility with
MySQL.
3.  Double-quoted names fall back to being string literals if
there is no matching table or column name.

In retrospect, (3) seems to be a bad idea.  It is accident-prone and
leads to all kinds of confusion.  For example, if double-quotes are
being used correctly (which is to say to quote table or column names)
but a misspelling occurs in the name, the token reverts to being a
string literal rather than throwing an error.  Or if a double-quoted
string really is being used as a string literal, but later a new
column is added to a table that has the same name as the string text,
the string literal will suddenly take on the value of the column.  It
seems like we have one or two problem reports per month on this
mailing list that involve people using double-quoted names where they
should be using single-quoted string literals instead.

So I'm giving some thought to removing feature (3) above and
disallowing double-quoted string literals.  My concern is, though,
that this might break many existing applications.

What opinion do you, gentle users, have of this matter?

D. Richard Hipp
[EMAIL PROTECTED]



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQL understanding problem

[Fred Williams]

If all the collum contents are identical why should it matter wich one is
modified?  Just do a select ... Limit 1  subquery in the update.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of c.panel
Sent: Thursday, June 26, 2008 4:57 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQL understanding problem



OK! so rowid should be ok !
thank you!
--
View this message in context:
http://www.nabble.com/SQL-understanding-problem-tp18142381p18144242.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] transaction recovery question

[Fred Williams]

That's why I continue to monitor SQLite messages even when I'm not actively
developing with SQLite.  There is an inherent entertainment value that
appears built in.

Over time I'm certain I have been guilty of posting some shall we say
"entertaining" messages myself.

Sometimes I think SQLite is so perfect a solution that many users just sit
around bored and come up with some off the wall subject just for the pure
potential entertainment value.

I find most of the "feature" requests and subsequent whining both for and
against most entertaining.  Many users must work for US auto makers.  When a
US auto maker builds a successful small car the first thing they do is start
making it bigger, to the point it loses all its original market share and
subsequent value.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of P Kishor
Sent: Tuesday, June 03, 2008 10:06 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] transaction recovery question


On 6/3/08, Federico Granata <[EMAIL PROTECTED]> wrote:
> 2008/6/3 Darko Filipovic <[EMAIL PROTECTED]>:
>
>
>  > But, what happen if journal file is deleted before starting B process?
>  >
>
> what if a UFO stole your pc ? :-D
>
>  try to delete journal file and see what happens ...
>


my vote for the funniest message in a long time.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Virtual tables declaration statements

[Fred Williams]

Don't think that will happen.  "Dot" notation is used as in
"databasename.tablename" and is therefore a restricted use notation.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Aladdin Lampe
Sent: Monday, May 05, 2008 8:57 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Virtual tables declaration statements



Hi list!

I've just finished a set of sqlite3 virtual tables and I would like to name
them with a "dot notation", ie "data.source1", "data.source2" created like
that:
sqlite3_create_module(db, "data.source1", , 0);
sqlite3_create_module(db, "data.source2", , 0);

... and then use the following calling convention:
create virtual table tab1 using data.source1(arg1, arg2);
create virtual table tab2 using data.source2(arg1, arg2, arg3);

... but the parser claims a  syntax error near "." :-(

Note that the following three notations just work, but I find them a bit
weird and not very user-friendly:
create virtual table tab1 using 'data.source1'(arg1, arg2);
create virtual table tab1 using "data.source1"(arg1, arg2);
create virtual table tab1 using [data.source1](arg1, arg2);

Is there any chance that this would be solved in a future version of SQLite,
ie considering adding the "." to the authorized characters in an identifier
following the key word "using"?

BTW, I do not see lots of virtual tables out there. I find it's a really
great and distinctive feature and I think that, following the recent
tutorial ideas, our SQLite community should set up a sharepoint with users
contributions (just like the "/contrib" area, but in a more user friendly,
collaborative and "visible" way). Same thing for user-defined functions,
aggregates, collations...
That would help people starting with sqlite and allow us to build some
useful tools/examples that everybody could use or inspire of...

Have a nice day,
Aladdin

_
Retouchez, classez et partagez vos photos gratuitement avec le logiciel
Galerie de Photos !
http://www.windowslive.fr/galerie/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Delphi dbExpress driver for SQLite3 ?

[Fred Williams]

Try this:

http://www.aducom.com/sqlite/

You can dump DBExpress completely.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of LacaK
Sent: Tuesday, April 22, 2008 2:15 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Delphi dbExpress driver for SQLite3 ?


Hi All,
I have downloaded dbExpress driver  for SQLite3 from
http://www.bcp-software.nl/artikelen/sqlite.html

When I am using it under Delphi6 (also in Turbo Delphi Explorer)
I receive often error "Library used incorrectly" ...

I have uploaded reproducible test case (+sources - very simple) at 
http://www.mint.sk/download/sqlite_problem.zip

Can anyone confirm that problem or provide some feedback , solution or 
link to other
(free or LGPL) dbExpress (Delphi6) driver for SQLite3?

TIA

-Laco
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Populating and scrolling the Listbox using query

[Fred Williams]

Might want to download the free source for the Delphi VCL set for Sqlite DB
access componenets provided at Aducom.com and review the releven source
code. Sorry, it is written that highly "inelegant" Object Pascal.  But I'm
an old "C" coder from way back and do read and write Object Pascal more so
than "C".  Just think of it as a wordy "C" without a real need for those
pesky pointers.  I have never looked that deep in that particular area of
the source so have no direct suggestions.  I just let Delphi VCL's do the
scrolling in either direction.

Fred

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Igor Tandetnik
Sent: Monday, April 14, 2008 6:36 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Populating and scrolling the Listbox using query


"Farzana" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> We are working in eVC++ environment with SQLite database.We need to
> populate the listbox with the values obtained by executing the query.
> We were able to get the values of the query by using the API's
> sqlite3_prepare and sqlite3_step.
> But we were able to populate and move the listbox in the downward
> direction only

http://www.sqlite.org/cvstrac/wiki?p=ScrollingCursor

Igor Tandetnik



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Fred Williams]

You might want to test a little further with Aducom's stuff. I'm using
Aducom and have the following working code in at least one app:

begin
  AList.Fields.FieldByName(FldName[j+1]).Value :=
Trim(ExtractData(RS));
  if RP >= Length(RS) then
   break;
end;

Fred

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Gilles Ganault
> Sent: Tuesday, March 04, 2008 4:08 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?
>
>
> On Tue, 4 Mar 2008 13:43:46 -0800 (PST), Rael Bauer
> <[EMAIL PROTECTED]> wrote:
> >  3. Add code in this event like the following:
> >Text := qryContacts.FieldByName('MyField').AsString;
>
> Thanks for the tip, but Aducom's Table component doesn't have a
> FieldByName property.
>
> procedure TForm1.ASQLite3Table1phones_parentGetText(Sender: TField;
>   var Text: String; DisplayText: Boolean);
> begin
>   //Text := qryContacts.FieldByName('MyField').AsString;
>   Text := ASQLite3Table1.F
> end;
>
> BTW, is there a way to have this event called for all fields, so as
> not to have to copy/paste for every column?
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Updatable views

[Fred Williams]

I agree very much with your suggestion.  Although all those vendor
specific "extensions" generally make the designers and coders lives
easier, the wheels tend to come off in onerous ways when a heavily
extended project migration is attempted.

Even when using a given vendor's product I have, based on past
experiences, made every effort to avoid the "gray" areas (IBM manuals
highlight extensions with gray background) of a particular vendor's
product.  In the long run it will serve a project well no matter the
project's size or level of complexity.

I have single user PC based projects that I have, over their life,
migrated to more than one vendors database. (Do I know how to pick a
loser?)  And I have participated in projects where a migration from the
likes of Oracle to SQL Server (no matter how ill advised) have been
made.

Therefore I strongly adhere to the SQL Standard whenever possible.  This
tends to cause less future work in the long run.  Although that approach
does not eliminate all conversion efforts, because most DB vendors can't
even get the SQL Standard right :-(

Fred

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Dennis Cote
> Sent: Tuesday, February 12, 2008 9:41 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Updatable views
>
>
> John Stanton wrote:
> > That ia a nice idea.  To have a pragma which specied the
> dialect.  There
> > could be "strict" or "ansi" and "mysql", "oracle",
> "sqlserver" etc etc.
> >   It would give tighter control over hard to track annoying
> minor syntax
> > errors.
> >
>
> I don't think we need anything that involved. Just a simple
> standard SQL
> mode and a the current SQLite mode with all its extensions in
> place. The
> second is needed as the default case for backward compatibility. The
> first would let those who care move to standard SQL syntax.
>
> I would further suggest that SQLite could change its behavior
> when the
> next major version release happens, and make the standard mode the
> default, since it is allowed to break backwards compatibility
> at that time.
>
> Users migrating from other databases generally have to make some
> modifications to their schema and SQL code since none of
> these systems
> are fully standard compliant, and most have some extensions
> that are not
> supported elsewhere. It would be relatively easy to make the changes
> needed to use standard SQL quoting when migrating to SQLite
> at that point.
>
> All these database products are continually moving to better
> support for
> the SQL standard. This would simply be another step along that road.
> Once the database is converted to use standard quoting in SQLite it
> would be portable to any of the other databases since they
> all support
> standard quoting. Similarly, databases created in SQLite
> using standard
> quoting would be more easily portable to any of these other databases
> if the need arises.
>
> Dennis Cote
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

RE: [sqlite] Next Version of SQLite

[Fred Williams]

> -Original Message-
> From: Nicolas Williams [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 14, 2008 10:29 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Next Version of SQLite
>
>
> On Sun, Jan 13, 2008 at 08:46:03PM -0600, Rick Langschultz wrote:
> > I was wondering what would constitute the creation of SQLite 4.0?
>
> IMO major implementation details changes are not necessarily a good
> rationale for bumping the major version number, not from a
> user's p.o.v.

...
>
> My guess is that the 3.x APIs are plenty good enough that incremental
> evolution is far better than incompatible revolution, so I
> bet they are
> here to stay.  Which means that if the major version number changes,
> then it'll be for marketing purposes.
>
> Nico
> --

Well seeing how SQLite is FREE, it does its own "marketing" with one
word, so to speak.  Therefore I doubt marketing will have much impact on
versioning.  What a quandary develops when one goes against the grain of
commercial software deployment :-)

Fred


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] SQLite --> PostGres

[Fred Williams]

I like the idea of keeping SQLite strictly SQL Standard compliant.  With
strict compliance one has a very strong and highly transportable
development platform to migrate a finished application to any SQL
Standard compliant database.  If all those vendor specific SQL Standard
"extensions" are really required on arrival at the target, perhaps one
has hit the wrong "target" :-)

I would like "Flame retardant suit on!" to see development continue
toward things like stored procedures, extended SQL Standard compliance,
enhanced Triggers, and anything that enhances support of user
implemented multi seat access.

But, if SQLite opens the multi user door too wide that will invite in a
heard of those that want even "more!" (Bloat) IMHO.  Perhaps it is time
to consider, as some databases have, a "Local" and a "Server"
implementation of SQLite.  Easy for someone like me to ask for, as a non
code contributor "user." :-)

Fred

> -Original Message-
> From: P Kishor [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 11, 2008 1:19 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] SQLite --> PostGres
>
>
> I have been writing an app using SQLite (great to develop with, and to
> serve with to an extent), always with the intent of one day upsizing
> it to PostGres (pain in the tush to develop with, but great to serve
> with to any extent). Much to my delight, I am finding that y'all (the
> SQLite developers) have made many things (for example, datatypes)
> similar to PostGres (yes, I know most all about how SQLite datatypes).
> My question -- why not take it all the way, and make SQLite almost a
> mini-PostGres... wait, before you chide me -- I don't mean in the "add
> more features" way, but in the "make syntax and datatypes as similar
> as possible" way.
>
> For example, why have the "INTEGER PRIMARY KEY" when it could just as
> easily be called "SERIAL"?
>
> One way might be to allow for aliases -- so, SERIAL would mean the
> same as INTEGER PRIMARY KEY, or CHAR(3) would mean the same as TEXT
> with a CHECK CONSTRAINT, and so on.
>
> Wouldn't that increase the already wildly popular appeal of SQLite
> even more so without subtracting or weighing anything down?
>
> By the way, I didn't find a BLOB kind in PostGres -- is that the same
> as BYTEA? If yes, that would be another candidate for such an alias.
>
>
> --
> Puneet Kishor
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Re: "always-trim" - feature suggestion

[Fred Williams]

> -Original Message-
> From: Aristotle Pagaltzis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 09, 2008 1:27 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Re: "always-trim" - feature suggestion
> 
> 
> * Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 18:15]:
> > On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote:
> > > and adding bloat will not contribute to its future success.
> > 
> > Of course, any feature, which *you* aren't especially fond of,
> > you can describe as "bloat". Even the most useful feature
> > (which is useful FOR ME) - can be "bloat" for you. And vice
> > versa. No, I'm not using *all*available* features of SQLite.
> > Are they "bloat"? Answer yourself.
> 
> Yes, actually, almost all requested and many implemented features
> are by definition bloat. Linus Torvalds once said that his most
> important job as the maintainer of the kernel is to say no to
> most suggested additions. I’m sure Dr. Hipp could give a list of
> things he would remove from SQLite if backward compatibility was
> not a concern.
> 
> Regards,
> -- 
> Aristotle Pagaltzis // 


I think one central issue related to SQLite does cause the most friction in the 
community. It is the never ending quest for "more features."  I feel the 
majority of users did not select SQLite for "the features" as SQLite by design 
avoids features to remain true to its history, culture, and place in the 
universe.  I did not select SQLite for the features.  I selected SQL Server, 
Oracle, and a couple of others for the features.  I selected SQLite for the 
lack of features.

I think none of the generated friction is intentional or divisive in nature.  
Some of us do a better job of communicating than others no matter what the base 
reason.  "Technical Computer" types have also had the historical if not 
accurate legacy of, "not playing well with others."  Since we aint in Marketing 
or Advertising I suspect a certain amount of truth to that perception.  And we 
usually have the unpopular duty of telling others what the Marketing and 
Advertising crowd has failed to mention, after they have left the building and 
the ink on the contract is not even dry.

Given all that, I have been guilty of being less than a perfect communicator on 
many occasions.  But I have found the participants on this list on a whole to 
be one of the better groups of technical types I have been associated with.  
Unfortunately there are instances where, normally a very passionate individual 
or idea is presented and is perceived as was unintended.

I pulled that "failure to communicate" trick recently with VB coder references. 
 Fortunately that thread died a well deserved death earlier than this one.  
But, it did little to change my opinion of BASIC as a computer "language." :-)  

Fred




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] "always-trim" - feature suggestion

[Fred Williams]

> -Original Message-
> From: Zbigniew Baniewski [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 09, 2008 11:08 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] "always-trim" - feature suggestion
>
>
> On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote:
>
> > You know, I believe that an "embedded" SQL has a philosophy
> which is
> > inherently minimalist.
>
> ...yes, I know.
>
> > Your request specifically goes against the
> > philosophy of what SQLite was designed to be. DRH is
> working hard to
> > protect an ideal which has appealed to millions, and
> continues to do so,
>
> Of course, I appreciate work of dr. Hipp
>
> > and adding bloat will not contribute to its future success.
>
> Of course, any feature, which *you* aren't especially fond of, you can
> describe as "bloat". Even the most useful feature (which is
> useful FOR ME)
> - can be "bloat" for you. And vice versa. No, I'm not using
> *all*available*
> features of SQLite. Are they "bloat"? Answer yourself.
>
>
> I'm not quite sure, what is the point in continuing this thread, when
> *yesterday* already I responded to the denial sent by Darren
> Duncan, that
> it's OK, and I can understand, that the devs didn't share my
> point of view.
> If it's going to convince me, that I don't need what I need - it's
> pointless, because I know my own needs much better. Otherwise
> I've got no
> idea, where should it going to, when I already wrote "OK, no problem".
> --
>   pozdrawiam / regards
>
>   Zbigniew Baniewski

I have been very effectively using SQLite for quite some time now, and
have watched with great reservation as it has "swelled" over that time.
My use of the product is to provide very simple SQL enabled backend
storage for any application not to be implemented in an "enterprise"
environment.  My applications do all the business rule, data prettying,
validation, and any other "feature" not provided by SQLite.  This allows
me to tailor my application (Mostly using "Cut and Paste" like efforts.)
to fit on most any platform environment from PDA to File Server.  That
is the reason I use SQLite, and for that reason only.

If I need a greater feature set than SQLite provides, I have a multitude
of database engines at my disposal with greater feature sets and price
range beginning with MySQL and ending with Oracle.  I do not beat a dead
horse trying to get the entire SQLite world and Dr. Hipp in particular
to "see it MY way."  Give it up and look for a more feature rich DB and
leave us poor dumb Bas--rds using SQLite alone!

Fred


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] database column attributes

[Fred Williams]

Answers in line.

> -Original Message-
> From: arbalest06 [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 21, 2007 9:23 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] database column attributes
>
>
>
> good day!
>
> i want to create a database with a table that has a column which is a
> TEXT..i want to specify the maximum length of the text..but i cant do
> TEXT(20)( ie., 20 characters max )..how can i do this?..
>

MyText  VARCHAR(20)  (SQLite will not enforce the column size limit.
That's the programmer's job:-)

> also i would like to specify that this column should be a
> required field..so
> if the column was not given a value during insert, it would
> return an sqlite
> error code..how can i implement this?..
>

MyText  VARCHAR(20) Not Null  (SQLite will enforce this one.)


> thanx and God bless!
> --
> View this message in context:
> http://www.nabble.com/database-column-attributes-tp14457206p14
457206.html
Sent from the SQLite mailing list archive at Nabble.com.



-
To unsubscribe, send email to [EMAIL PROTECTED]

-


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Improving performance of SQLite. Anyone heard ofDevice SQL?

[Fred Williams]

Went south in a rush.  Agreed.  BTW, I can drive a forklift, and a back
hoe...

Fred

> -Original Message-
> From: James Steward [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 17, 2007 6:43 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Improving performance of SQLite. Anyone heard
> ofDevice SQL?
>
>
> On Mon, 2007-12-17 at 19:22 -0500, John Elrick wrote:
> > John Elrick wrote:
> >
> > SNIP
> > > When you can hire a forklift operator to program (well, that is),
> >
> >
> > To avoid a misunderstanding...I mean - right off the
> forklift.  I'm sure
> > anyone with the proper motivation can learn to program, but
> it took me
> > 25 years to realize how little I really knew.
>
> I didn't write the original about forklift operators.  It was Fred
> Williams, AFAIK.
>
> I am in agreement with you, and I have nothing against forklift
> operators either.
>
> IMHO, this has gone completely off topic, and I shall hence
> forth cease
> to contribute to this, and related threads.
>
> Regards,
> James.
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Improving performance of SQLite. Anyone heard ofDevice SQL?

[Fred Williams]

It's the ones who never figure out how little they know that do all the
damage...

Fred

> -Original Message-
> From: John Elrick [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 17, 2007 6:22 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Improving performance of SQLite. Anyone heard
> ofDevice SQL?
>
>
> John Elrick wrote:
>
> SNIP
> > When you can hire a forklift operator to program (well, that is),
>
>
> To avoid a misunderstanding...I mean - right off the
> forklift.  I'm sure
> anyone with the proper motivation can learn to program, but
> it took me
> 25 years to realize how little I really knew.
>
>
> John
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Improving performance of SQLite. Anyone heard ofDeviceSQL?

[Fred Williams]

There you go!  Thinking like an engineer (logical) and not management
:-)

I have met a few $100K+ programmers out there, but none were VB'ers.
Just a bunch of "namby pamby" C and C++ wizards :-)


Fred

> -Original Message-
> From: John Elrick [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 17, 2007 6:16 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Improving performance of SQLite. Anyone heard
> ofDeviceSQL?
>
>
> James Steward wrote:
> > On Mon, 2007-12-17 at 15:30 -0600, Fred Williams wrote:
> >
> >> A hundred or so Visual Basic programmers are cheaper to replace and
> >> "maintain" than one good Delphi/C++ programmer. ;-)  That
> is the reason
> >> management likes "Visual ."  Been there, learned that.
>  Hire the
> >> staff from the largest pool, not the most effective.
> Besides it's damn
> >> hard to be a prima donna, when your replacement is ready
> to jump off
> >> that forklift and learn a cushy job.
> >>
>
> For some reason your original never showed up in my mailbox.  Pity
>
> When you can hire a forklift operator to program (well, that is), you
> can just as likely have the computer program itself at zero
> labor cost.
>
> Oh (100 * $45,000/year = $450,000.  I'll be happy if someone
> would pay
> me that much  I should ask for a raise.)  It's also an exponential
> growth rate in management costs to manage one hundred people
> instead of
> one
>
>
> John
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Improving performance of SQLite. Anyone heard of Devic eSQL?

[Fred Williams]

I doubt it, you are obviously aggressive enough to learn more than the
Mickysoft studio.

Honestly, how many Visual X programmers do you know that have come
from the "rank and file?"  As a consultant, I have seen a very large
proportion who have.  I admire anyone who has the desire and ambition to
better himself.  I just don't agree with management when they take the
least cost approach to their technical hiring.

But, that is one of the main reasons there are so many "place holders"
in companies.  Those same companies readily hire outside expertise to
accomplish their technical tasks, because internally they lack the
technical strength.

Fred

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 17, 2007 3:40 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Improving performance of SQLite. Anyone heard of
> Devic eSQL?
>
>
> Wow, I know this isn't really the point of your comment, but
> I always have to jump in when I see VB programmers
> "attacked".  So as a Delphi / C++ / VB programmer, where do I
> fit into your analogy?  Do I end up replacing myself :)
>
> --
> Eric Pankoke
> Founder / Lead Developer
> Point Of Light Software
> http://www.polsoftware.com/
>
>  -- Original message --
> From: "Fred Williams" <[EMAIL PROTECTED]>
> > A hundred or so Visual Basic programmers are cheaper to replace and
> > "maintain" than one good Delphi/C++ programmer. ;-)  That
> is the reason
> > management likes "Visual ."  Been there, learned that.  Hire the
> > staff from the largest pool, not the most effective.
> Besides it's damn
> > hard to be a prima donna, when your replacement is ready to jump off
> > that forklift and learn a cushy job.
> >
> > Fred
> >
> > > -Original Message-
> > > From: John Elrick [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, December 16, 2007 7:36 PM
> > > To: sqlite-users@sqlite.org
> > > Subject: Re: [sqlite] Improving performance of SQLite.
> Anyone heard of
> > > Devic eSQL?
> > >
> > >
> > > John Stanton wrote:
> > > > This also is an anecdote from some time back.  As we
> were signing a
> > > > fairly significant software contract with a large
> > > organization their
> > > > manager told us "You guys know nothing about marketing.  Your
> > > > presentation was unprofessional, no glossy brochures, no
> > > audio visuals
> > > > and we would not have bought except that you were the
> only ones who
> > > > convinced us you could do the job".  We just smiled and
> watched the
> > > > ink dry while we pondered "where did we go right?".
> > > >
> > > > The simple truth is that if you hype a product and sell
> it into an
> > > > area where it is inadequate your triumph is short lived and
> > > the scorn
> > > > and litigation enduring.  On the other hand if you deliver
> > > a solution
> > > > which works as well, or preferably better, than
> proposed you have
> > > > generated raving fans who will buy again and endorse your
> > > product to
> > > > all and sundry.  Which is the better model?
> > >
> > > To quote a former programs manager for Bank of America "the first
> > > solution which meets my business needs and performs the job
> > > adequately".  In this case, adequately can be defined as
> loosely as
> > > "doesn't crash too often" or as stringently as "positively no
> > > errors",
> > > depending on the business use.
> > >
> > > Keeping the discussion academic, "hype a product..." is a
> > > business model
> > > that apparently has been used to at least some degree by a company
> > > called Microsoft.  It tends to work because the model permits
> > > them such
> > > an early lead that even better products have difficulty
> catching up.
> > >
> > > I do most of my programming in Delphi, a Borland product
> > > which remains
> > > in my opinion, even in its shadow of former glory state,
> a far more
> > > straightforward and powerful product than Visual Studio.
> Borland has
> > > always been a technical company, not a market driven one and its
> > > flagship product is surviving only because it remains a more well
> > > rounded Windows solution than its competition.  However,
> it is only
> > > s

RE: [sqlite] Improving performance of SQLite. Anyone heard of Devic eSQL?

[Fred Williams]

A hundred or so Visual Basic programmers are cheaper to replace and
"maintain" than one good Delphi/C++ programmer. ;-)  That is the reason
management likes "Visual ."  Been there, learned that.  Hire the
staff from the largest pool, not the most effective.  Besides it's damn
hard to be a prima donna, when your replacement is ready to jump off
that forklift and learn a cushy job.

Fred

> -Original Message-
> From: John Elrick [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 16, 2007 7:36 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Improving performance of SQLite. Anyone heard of
> Devic eSQL?
>
>
> John Stanton wrote:
> > This also is an anecdote from some time back.  As we were signing a
> > fairly significant software contract with a large
> organization their
> > manager told us "You guys know nothing about marketing.  Your
> > presentation was unprofessional, no glossy brochures, no
> audio visuals
> > and we would not have bought except that you were the only ones who
> > convinced us you could do the job".  We just smiled and watched the
> > ink dry while we pondered "where did we go right?".
> >
> > The simple truth is that if you hype a product and sell it into an
> > area where it is inadequate your triumph is short lived and
> the scorn
> > and litigation enduring.  On the other hand if you deliver
> a solution
> > which works as well, or preferably better, than proposed you have
> > generated raving fans who will buy again and endorse your
> product to
> > all and sundry.  Which is the better model?
>
> To quote a former programs manager for Bank of America "the first
> solution which meets my business needs and performs the job
> adequately".  In this case, adequately can be defined as loosely as
> "doesn't crash too often" or as stringently as "positively no
> errors",
> depending on the business use.
>
> Keeping the discussion academic, "hype a product..." is a
> business model
> that apparently has been used to at least some degree by a company
> called Microsoft.  It tends to work because the model permits
> them such
> an early lead that even better products have difficulty catching up.
>
> I do most of my programming in Delphi, a Borland product
> which remains
> in my opinion, even in its shadow of former glory state, a far more
> straightforward and powerful product than Visual Studio.  Borland has
> always been a technical company, not a market driven one and its
> flagship product is surviving only because it remains a more well
> rounded Windows solution than its competition.  However, it is only
> surviving and is unlikely to actually thrive ever again.
>
> So my suggested answer is, the proven model is "dominate the market
> early with an adequate product".  If your product is very
> good and even
> better than proposed, all the better.  But if you are "Johnny come
> lately", you will likely lose unless your product is very,
> very good.
> And, whether we like it or not, a big part of market domination is to
> convince all the decision makers (management) and decision breakers
> (engineers with influence) that yours is the safest choice to make.
>
> FWIW
>
>
> John Elrick
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Improving performance of SQLite. Anyone heard of DeviceSQL?

[Fred Williams]

This discussion reminds me of another long, long ago in a galaxy far,
far away. (When I worked on "Mainframes" with 32 K or less "core"
memory.)

Discussing the then lopsided world with my non-IBM salesman, in a local
watering hole, after a particularly trying day of dealing with
"management."  The topic was the state of the computer industry at that
time. (And yet today.)

I was complaining of managements' complete lack of ability to see the
superior to IBM technology, (IMHO) and cost effectiveness we had
installed.  That is when I learned of the non bits and bytes "real
world."  My late salesman friend said,  "Fred, don't you understand that
the computer industry is a Marketing industry based on technology, and
not a technology industry?"

Thirty years later nothing could be truer.  No matter how much things
change, they still stay the same...

Fred

Running Windoze  on a "PC".
I know, I know it should be Linux on a Mac.  But I live in the "real
world" today.
I rest my case.

> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 15, 2007 7:04 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Improving performance of SQLite. Anyone heard of
> DeviceSQL?
>
>
>
> On Dec 14, 2007, at 9:24 PM, Lynn Fredricks wrote:
>
> > That's true. A lot of those kinds of sales presentations
> are correctly
> > targeted at decision makers that make financial decisions. I don't
> > consider
> > it a bad thing - it's really a necessity to be competitive.
> >
>
> My intent is  to provide complete detailed technical information
> about SQLite, including its limitations and faults, and honest
> comparisons and even recommendations of other products
> (including, but not limited to DeviceSQL).  My intent is to avoid
> sophistry, misrepresentation, exaggeration,  and hype.
> This intent is sometimes imperfectly executed, but it is my goal.
>
> If that means that SQLite is uncompetitive, then so be it.
>
>
> D. Richard Hipp
> [EMAIL PROTECTED]
>
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Should the next release be 3.5.4 or 3.6.0?

[Fred Williams]

If you suspect "Group By" also may be broken, why not to an interim "bug
fix" release and then do the version number change when both "Order By"
and "Group By" are fixed?  I seem to remember instances where both Order
BY and Group By have given me "unexpected" results.  But then again, my
logical thinking is not on Mr. Spock's level, unfortunately.

Fred

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 13, 2007 10:41 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Should the next release be 3.5.4 or 3.6.0?
>
>
> Ticket number #2822
>
>   http://www.sqlite.org/cvstrac/tktview?tn=2822
>
> has provoked extensive changes to the way SQLite handles
> ORDER BY clauses.  The current algorithm goes like this:
>
>
>(1)  If an ORDER BY term is a constant integer k
> then sort by the k-th column of the result set.
>
>(2)  If an ORDER BY term is a simple identifer
> (like "x", not "x.y" and not "x.y.z") and if
> there if the k-th column uses that same identifer
> as an AS alias, the sort by the k-th column.
>
>(3)  Otherwise, evaluate the expression which is
> in the ORDER BY term and sort by the resulting
> value.
>
> For a compound query, the expression in step (3) must
> exactly match one of the result columns.  Also, the
> three steps are attempted first on the left-most SELECT.
> If there is a match, the process stops there.  If no
> match is found, the next SELECT to the right is tried.
> This repeats as necessary until a match is found or
> until you run out of SELECT statement in which case there
> is an error.
>
> This algorithm differs from all prior versions of SQLite
> (1.0.0 through 3.5.3) by the addition of step (2).
> Adding step (2) brings SQLite much closer to the SQL
> standard.  I believe that SQLite is now a superset of
> the SQL standard.  SQL has no concept of step (3).  And
> in a compound query, SQL only looks at the left-most
> SELECT and does not fail over to SELECT statements to
> the right looking for a match.  But these changes can
> be considered extensions.
>
> The revised algorithm is mostly compatible with the
> way SQLite has always operated before.  But there
> are a few obscure corner cases where there is a difference.
> An example of the difference is the following:
>
> CREATE TABLE a(x,y);
> INSERT INTO a VALUES(1,8);
> INSERT INTO a VALUES(9,2);
>
> SELECT x AS y FROM a ORDER BY y;
>
> In older versions of SQLite, the SELECT statement above
> would return 9, 1 since the ORDER BY term evaluated to
> the expression a.y by rule (3)  In the next release,
> because of the addition of rule (2) above, the result
> will be 1, 9.
>
> My question to the community is this:  Are these
> differences sufficient to justify going with version
> 3.6.0 in the next release?  Or can we call the change
> a "bug fix" and number the next release 3.5.4?
>
> Other information to consider:
>
>*  We do not have a lot of time to debate the merits
>   of this change since we need to get out a release
>   to fix critical bug #2832.
>
>*  We have taken no steps toward fixing GROUP BY.
>   If I got ORDER BY wrong, I'm guessing GROUP BY
>   is wrong too.
>
> Thanks for your input.
>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Re: Different between BEGIN, END and "begin transaction", "

[Fred Williams]

Actually the first looks like Pascal and the second COBOL  (Well, it
should be all upper case)...

> -Original Message-
> From: Igor Tandetnik [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 29, 2007 12:47 PM
> To: SQLite
> Subject: [sqlite] Re: Different between BEGIN, END and "begin
> transaction", "
>
>
> Joanne Pham
>  wrote:
> > What is the different between
> >  BEGIN
> >  insert .
> >  END
> >
> > and
> >begin transaction
> >insert ...
> >end transaction
>
> None whatsoever.
>
> Igor Tandetnik
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Suggests for improving the SQLite website

[Fred Williams]

Great idea!  Why don't we give them little printable chits for free
chips and beer as well?!

Just the facts m'am. -- Jack Webb

> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 09, 2007 5:51 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Suggests for improving the SQLite website
>
>
> James Dennett wrote:
> > Joe Wilson wrote:
> >
> >> --- "Samuel R. Neff" <[EMAIL PROTECTED]> wrote:
> >>> I hope this doesn't offend, but perhaps the best solution is to
> >> outsource
> >>> the website to someone or a company that specializes in
> websites and
> >> design
> >>> (with your stated simplicity goals in mind of course).
> We certainly
> >>> wouldn't want a graphic designer hacking away at the
> SQLite engine,
> > so
> >> isn't
> >>> the reverse also true?
> >>>
> >>> Sam
> >> +1
> >>
> >> Also, non-technical people would be a better judge of which website
> >> design is appealing.
> >
> > Appealing *to* non-technical people?  Why would a website
> on an embedded
> > database wish to appeal primarily to such an audience?  I'd think it
> > would be best to present information in a way that appeals
> to its likely
> > viewers.
> >
> > -- James
> >
>
> How about having adding a social networking capability so that
> non-technical people will have a reason to use the website.
> You cannot
> expect to attract them with a frugal and highly functional embedded
> database library.
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Suggests for improving the SQLite website

[Fred Williams]

For what reason would "non-technical" types need to look on the SQLite
website? :-)

I kind'a like it the way it is. Plain and simple, with no over wrought
graphics and other worthless fluff.
It is a website for a very bare bones, plain and simple database.  Those
who access it are not looking for entertainment, just plain and simple
results.

Fred

> -Original Message-
> From: Joe Wilson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 09, 2007 4:25 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Suggests for improving the SQLite website
>
>
> --- "Samuel R. Neff" <[EMAIL PROTECTED]> wrote:
> >
> > I hope this doesn't offend, but perhaps the best solution
> is to outsource
> > the website to someone or a company that specializes in
> websites and design
> > (with your stated simplicity goals in mind of course).  We certainly
> > wouldn't want a graphic designer hacking away at the SQLite
> engine, so isn't
> > the reverse also true?
> >
> > Sam
>
> +1
>
> Also, non-technical people would be a better judge of which website
> design is appealing.
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Proper way to transfer a live sqlite database

[Fred Williams]

It would most likely be much quicker (and simpler) just to utilize the
OS's file coping feature to copy the table.  What would be gained with
the attaching databases approach over just a straight file copy?

Fred

> -Original Message-
> From: Rich Rattanni [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 18, 2007 10:20 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Proper way to transfer a live sqlite database
>
>
> I was writing to ask some opinions on how to perform a download of a
> live sqlite database.  Basically I have a device, which stores all
> manner of data in a sqlite database.  Periodically I want to download
> the data to a central server for viewing.  I discussed it with my
> colleagues, and they felt that I should just copy the file to the
> server.  However I was thinking of having a blank database with
> identical schema to the database I am copying.  Then when the download
> occurs, I would ATTACH the live database to the blank database, and
> query the data from one to the other.  Then I would close the cloned
> version and offload that to the server.
>
> The standard questions now follow...
> Is this an acceptable way?
> Is there a better/best way?
>
> Thanks for any input,
> Rich Rattanni
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Trigger update of multiple columns

[Fred Williams]

I think maybe "Normalization" could be one of the best underutilized
features of modern database design by most practicing "Database
Consultants."  Never have I seen such a rule with so many exceptions!
Each normalization decision must be prefaced with "It Depends" in every
instance.  Ah the potential billable time that can be spent with each
normalization effort boggles the mind :-)

If the subject record is be looked on as a "history" record documenting
the exact circumstances of a "sales" transaction then it is no longer a
dynamic entity subject to the variegations of the ever changing data
items within the related "master" tables.  Therefore, the data items
contained in each row of this table should be a permanent reflection of
the master tables' data content at an exact point in time and must not
remain linked to the related dynamic master tables.  (i.e. the subject
table is no longer a "transaction" table in the true sense but a static
snapshot of a given physical activity.  The exact definition of a
particular "sales" event and not subject to change.

But then again...

Fred


> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 18, 2007 9:58 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Trigger update of multiple columns
>
>
> If you can automatically enter data then you are violating the
> normalization rules.  Maybe you should get a book on database
> design and
> become familiar with some of the fundamentals.
>
> T wrote:
> > Hi John,
> >
> >> You have a reference data set which is accessed to get the
> current
> >> value of reference elements and store transactions to
> record  events.
> >> The transaction trails provide event history.
> >
> >
> > Yes, agreed.
> >
> >> A price is in the reference data, its value transferred to a
> >> transaction is no longer a price, it is a sale which
> represents the
> >> value of the price at the time the event occurred.
> >
> >
> > Yes.
> >
> >> How about reading your price data etc and just inserting a
> >> transaction into your sales table?
> >
> >
> > Yes, that's what I'm doing. I just want to make it more efficient.
> >
> > Technically it's the sale_products table (since each sale has many
> > products etc), but yes, I want to insert the transactions data
> > (product_id, buy, sell, desc) into the sale_products table.
> But I  want
> > a mechanism whereby if I enter the product_id, then the
> buy,  sell, desc
> > columns are auto entered (copied) from their corresponding
> row in the
> > products table.
> >
> > Tom
> >
> >
> >
> >
> --
> ---
> >
> > To unsubscribe, send email to [EMAIL PROTECTED]
> >
> --
> ---
> >
> >
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Limit statement size?

[Fred Williams]

Wow!  Talk about obfuscated code!  I didn't even try to dig deeper than
a quick scan, but could this abomination be broken into multiple update
queries?  On the surface it looks like each "group" is unique.  If so,
wouldn't a transaction with multiple update statements be much more
efficient and a much lighter load on resources on a step by step basis?
I damn well know it would be much more pleasing to the eye! :-)

Fred

> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 28, 2007 12:07 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Limit statement size?
>
>
> Is there any limit on the size of the SQL statements in SQLite?
> Didn't think this would come into play, but have now come across this
> query and wonder if this needs considering:
>
> UPDATE A3Test115_J SET ENTRY_ID_E2 = (SELECT ENTRY_ID FROM
> GROUP_2 T WHERE
> PATIENT_ID = T.PID), READ_CODE_E2 = (SELECT READ_CODE FROM
> GROUP_2 T WHERE
> PATIENT_ID = T.PID), TERM_TEXT_E2 = (SELECT TERM_TEXT FROM
> GROUP_2 T WHERE
> PATIENT_ID = T.PID), START_DATE_E2 = (SELECT START_DATE FROM
> GROUP_2 T WHERE
> PATIENT_ID = T.PID), ADDED_DATE_E2 = (SELECT ADDED_DATE FROM
> GROUP_2 T WHERE
> PATIENT_ID = T.PID), NUMERIC_VALUE_E2 = (SELECT NUMERIC_VALUE
> FROM GROUP_2 T
> WHERE PATIENT_ID = T.PID), ENTRY_ID_E3 = (SELECT ENTRY_ID
> FROM GROUP_3 T
> WHERE PATIENT_ID = T.PID), READ_CODE_E3 = (SELECT READ_CODE
> FROM GROUP_3 T
> WHERE PATIENT_ID = T.PID), TERM_TEXT_E3 = (SELECT TERM_TEXT
> FROM GROUP_3 T
> WHERE PATIENT_ID = T.PID), START_DATE_E3 = (SELECT START_DATE
> FROM GROUP_3 T
> WHERE PATIENT_ID = T.PID), ADDED_DATE_E3 = (SELECT ADDED_DATE
> FROM GROUP_3 T
> WHERE PATIENT_ID = T.PID), NUMERIC_VALUE_E3 = (SELECT
> NUMERIC_VALUE FROM
> GROUP_3 T WHERE PATIENT_ID = T.PID), ENTRY_ID_E4 = (SELECT
> ENTRY_ID FROM
> GROUP_4 T WHERE PATIENT_ID = T.PID), READ_CODE_E4 = (SELECT
> READ_CODE FROM
> GROUP_4 T WHERE PATIENT_ID = T.PID), TERM_TEXT_E4 = (SELECT
> TERM_TEXT FROM
> GROUP_4 T WHERE PATIENT_ID = T.PID), START_DATE_E4 = (SELECT
> START_DATE FROM
> GROUP_4 T WHERE PATIENT_ID = T.PID), ADDED_DATE_E4 = (SELECT
> ADDED_DATE FROM
> GROUP_4 T WHERE PATIENT_ID = T.PID), NUMERIC_VALUE_E4 = (SELECT
> NUMERIC_VALUE FROM GROUP_4 T WHERE PATIENT_ID = T.PID), ENTRY_ID_E5 =
> (SELECT ENTRY_ID FROM GROUP_5 T WHERE PATIENT_ID = T.PID),
> READ_CODE_E5 =
> (SELECT READ_CODE FROM GROUP_5 T WHERE PATIENT_ID = T.PID),
> TERM_TEXT_E5 =
> (SELECT TERM_TEXT FROM GROUP_5 T WHERE PATIENT_ID = T.PID),
> START_DATE_E5 =
> (SELECT START_DATE FROM GROUP_5 T WHERE PATIENT_ID = T.PID),
> ADDED_DATE_E5 =
> (SELECT ADDED_DATE FROM GROUP_5 T WHERE PATIENT_ID = T.PID),
> NUMERIC_VALUE_E5 = (SELECT NUMERIC_VALUE FROM GROUP_5 T WHERE
> PATIENT_ID =
> T.PID), ENTRY_ID_E6 = (SELECT ENTRY_ID FROM GROUP_6 T WHERE
> PATIENT_ID =
> T.PID), READ_CODE_E6 = (SELECT READ_CODE FROM GROUP_6 T WHERE
> PATIENT_ID =
> T.PID), TERM_TEXT_E6 = (SELECT TERM_TEXT FROM GROUP_6 T WHERE
> PATIENT_ID =
> T.PID), START_DATE_E6 = (SELECT START_DATE FROM GROUP_6 T
> WHERE PATIENT_ID =
> T.PID), ADDED_DATE_E6 = (SELECT ADDED_DATE FROM GROUP_6 T
> WHERE PATIENT_ID =
> T.PID), NUMERIC_VALUE_E6 = (SELECT NUMERIC_VALUE FROM GROUP_6 T WHERE
> PATIENT_ID = T.PID), ENTRY_ID_E7 = (SELECT ENTRY_ID FROM
> GROUP_7 T WHERE
> PATIENT_ID = T.PID), READ_CODE_E7 = (SELECT READ_CODE FROM
> GROUP_7 T WHERE
> PATIENT_ID = T.PID), TERM_TEXT_E7 = (SELECT TERM_TEXT FROM
> GROUP_7 T WHERE
> PATIENT_ID = T.PID), START_DATE_E7 = (SELECT START_DATE FROM
> GROUP_7 T WHERE
> PATIENT_ID = T.PID), ADDED_DATE_E7 = (SELECT ADDED_DATE FROM
> GROUP_7 T WHERE
> PATIENT_ID = T.PID), NUMERIC_VALUE_E7 = (SELECT NUMERIC_VALUE
> FROM GROUP_7 T
> WHERE PATIENT_ID = T.PID), ENTRY_ID_E8 = (SELECT ENTRY_ID
> FROM GROUP_8 T
> WHERE PATIENT_ID = T.PID), READ_CODE_E8 = (SELECT READ_CODE
> FROM GROUP_8 T
> WHERE PATIENT_ID = T.PID), TERM_TEXT_E8 = (SELECT TERM_TEXT
> FROM GROUP_8 T
> WHERE PATIENT_ID = T.PID), START_DATE_E8 = (SELECT START_DATE
> FROM GROUP_8 T
> WHERE PATIENT_ID = T.PID), ADDED_DATE_E8 = (SELECT ADDED_DATE
> FROM GROUP_8 T
> WHERE PATIENT_ID = T.PID), NUMERIC_VALUE_E8 = (SELECT
> NUMERIC_VALUE FROM
> GROUP_8 T WHERE PATIENT_ID = T.PID), ENTRY_ID_E9 = (SELECT
> ENTRY_ID FROM
> GROUP_9 T WHERE PATIENT_ID = T.PID), READ_CODE_E9 = (SELECT
> READ_CODE FROM
> GROUP_9 T WHERE PATIENT_ID = T.PID), TERM_TEXT_E9 = (SELECT
> TERM_TEXT FROM
> GROUP_9 T WHERE PATIENT_ID = T.PID), START_DATE_E9 = (SELECT
> START_DATE FROM
> GROUP_9 T WHERE PATIENT_ID = T.PID), ADDED_DATE_E9 = (SELECT
> ADDED_DATE FROM
> GROUP_9 T WHERE PATIENT_ID = T.PID), NUMERIC_VALUE_E9 = (SELECT
> NUMERIC_VALUE FROM GROUP_9 T WHERE PATIENT_ID = T.PID), ENTRY_ID_E10 =
> (SELECT ENTRY_ID FROM GROUP_10 T WHERE PATIENT_ID = T.PID),
> READ_CODE_E10 =
> (SELECT READ_CODE FROM GROUP_10 T WHERE PATIENT_ID = T.PID),
> TERM_TEXT_E10 =
> (SELECT TERM_TEXT FROM GROUP_10 T WHERE PATIENT_ID = T.PID),
> START_DATE_E10
> = (SELECT START_DATE FROM GROUP_10 T WHERE 

RE: [sqlite] How to conditionally drop a table?

[Fred Williams]

> -Original Message-
> From: G. Roderick Singleton [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 25, 2007 12:06 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] How to conditionally drop a table?
>
>
> On Thu, 2007-01-25 at 11:13 -0600, John Stanton wrote:
> > If you find a way to drop a table which dosn't exist. let
> us know how
> > you do it.
> >
> > G. Roderick Singleton wrote:
> > > On Thu, 2007-01-25 at 10:35 -0500, Anderson, James H (IT) wrote:
> > >
> > >>I need a way to drop a table only if that table exists.
> How would I do
> > >>that?
> > >>
> > >>Thanks,
> > >
> > >
> > > Are you asking if http://sqlite.org/lang_droptable.html
> works or have
> > > you had problems?
> >
> >
>
> Thanks for your insight. However what's your point? That the OP didn't
> check the website, that my reference was incorrect or what?
> --
> G. Roderick Singleton <[EMAIL PROTECTED]>
> PATH tech
>
>

Now you know why there are no software types that are stand up comedians
:-)

I think it was a (bad) attempt at a joke...

Fred


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Sqlite Preprocessor

[Fred Williams]

Or my contempt of code generators in general :-)

Fred

> -Original Message-
> From: Ken [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2007 12:46 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Sqlite Preprocessor
> 
> 
> I think the fact that sqlite is typeless actually is a benefit. 
>  
>  I see what you mean now about connecting to obtain the meta 
> info. Maybe that could be embedded in the code as well for 
> the pre-processor. 
>  
>  Thanks for your input.
> 
> Joe Wilson <[EMAIL PROTECTED]> wrote: ...and I was trying 
> to disagree with you.  ;-)
> 
> PRO*C and all such pre-processing SQL code generators actually
> _do_ need to connect to a database in order to get the table 
> meta-information
> (column types, etc). It is this database meta-information 
> that allows the
> user of the pre-processor to write the succinct code you mentioned.
> Either you have to supply the column type info, or the tool has to 
> obtain it somehow. And considering that SQLite is typeless, 
> you have your 
> work cut out for you.
> 
> But don't let my contempt of SQL code generators disuade you.
> 
> --- Ken  wrote:
> >  yes thats what I'm thinking.. The thing is the amount of 
> code that can be reduced via the
> > preprocessor is enormous. Plus the fact that one could also 
> preprocess into the resulting C code
> > all sorts of wonderful error handling   in a very succinct 
> language construct.
> >  
> >  I hapen to perfer the conept of PRO*C, I don't like all of 
> the weird errors that it generates
> > and the various modes of operation. I'm advocating 
> something that is a build it like I tell you
> > to do, not how you interpret it. Leave out all of the goofy 
> semantic checking etc.. Just let the
> > normal C compiler handle that bit.  There's no real need to 
> connect to a sqlitedb just to verify
> > the table exists.
> >  
> >  Ken
> >  
> > 
> > Joe Wilson  wrote: > Yes, a pre processor, but not a 
> wrapper.  A wrapper as
> > I've seen from the sqlite.org site is
> > > simply a layer on top of the sqlite3 api. I've written my 
> own wrapper.  I'm really looking to
> > > see if instead of inserting an additional layer, the 
> actual code could be compiled inline into
> > > the sourcing C file, thus a pre processor. 
> > 
> > Okay, I see. All the bad memories are coming back now...
> > 
> > I used the PRO*C pre-processor ten years ago.
> > What a disaster that approach is. Never again.
> > The code is a mess and debugging is a nightmare.
> > 
> > You actually need a static database schema to run your 
> code-generating
> > pre-processor against. You change your database schema and 
> your code 
> > generator has some obscure syntax error. If your 
> application crashes 
> > you have to wade through generated code to see WTF is going on. 
> > In the time it takes to chase down problems you could have written 
> > a superior application in a traditional language binding/wrapper.
> > 
> > Just my opinion of course.
> 
> 
>  
> __
> __
> Any questions? Get answers on any topic at 
> www.Answers.yahoo.com.  Try it now.
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 
> 
> 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] sqlite performance, locking & threading

[Fred Williams]

Sounds like a H-- of a plan to me!  

I'll call Larry Ellison and warn him to put the 12 meter yacht up for sale, 
he's about to get steam rolled! :-)

Fred

> -Original Message-
> From: Bill King [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 1:15 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] sqlite performance, locking & threading
> 
> 
> Roger Binns wrote:
> 
> >>Im sorry for being so harsh, and i know im not winning any friends
> >>here,
> >>
> >>
> >
> >So far noone has agreed with you :-)
> >
> >  
> >
> This would be incorrect. The correct statement is "so far no one has 
> vocally agreed with you".
> 
> If people didn't agree, this whole once a month people having 
> multi-threading issues would not be the case. Surely the number of 
> people with exactly the same issues, month after month, 
> should point to 
> something? Perchance illogic?
> 
> Time I think to go off and write my own simple sql engine. 
> People here 
> are far too closed minded, and far too quick to attack others because 
> they don't follow DRH's line of thought, and decisions.
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] sqlite performance, locking & threading

[Fred Williams]

Been following this a while...  You have access to the source, and
apparently are a "threading genius."  Please make the required minor
changes and post a link here so we can all benefit.

Fred

> -Original Message-
> From: Emerson Clarke [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 30, 2006 9:34 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] sqlite performance, locking & threading
>
>
> Roger,
>
> I think sqlite suffers somewhat from a bit of an identity crisis.
> Whilst it is both a library and a piece of code which you embed in a
> project it is often talked about as though it is some external
> component.
>
> Technically sqlite is not thread safe.  Just because the library has
> explicitly disallowed using the same sqlite3 * structure in multiple
> threads on some platforms (i understand this requirement has been
> relaxed on others) does not make it thread safe.  Even on the
> platforms where a single sqlite3 * structure can be used on multiple
> threads (provided it is not at the same time), it is not possible to
> have a transaction which works across these threads.  So even if the
> connection is thread safe, the transactions are not.
>
> By the usual definition, something which is thread safe can be safely
> used across multiple threads, usually with the aid of synchronisation
> but sometimes not.  For instance collections are often considdered
> thread safe only when they manage their own mutexes internally so that
> the user doesnt have to.  But either way, you can use them accross
> multiple threads.  You cannot do this with sqlite, so it is quite
> confusing to say that sqlite is thread safe...
>
> I think a better definition would be that sqlite can be safely used in
> a multithreaded program, but is not thread safe.
>
> I agree that multithreaded programming can be difficult, but its not
> magic and i think that a few simple rules can overcome most of the
> problems.  It certainly is not luck that multithreaded systems work,
> usually its the result of careful design and hard work.
>
> Emerson
>
> On 12/30/06, Roger Binns <[EMAIL PROTECTED]> wrote:
> > Emerson Clarke wrote:
> > > If i have a linked list, i can use it across threads if i want to,
> > > provided that i synchronise operations in such a way that the list
> > > does not get corrupted.
> >
> > And of course you also have to know about memory barriers
> and compiler
> > re-ordering.  That is highly dependent on the libraries
> and/or compiler
> > you are using, as well as underlying hardware
> implementation.  Most of
> > the time, developers just get lucky.
> >
> >   http://en.wikipedia.org/wiki/Memory_barrier
> >
> > > Likewise for most other data structures and libraries.
> >
> > Arguably that is by luck and not design!  Look at the
> effort that to go
> > in an add _r suffixed versions of several functions in the standard
> > libraries.  And many GUI libraries have long had a
> restriction that you
> > can only use them in one thread.
> >
> > > Sqlite does not follow these rules, as something created
> in one thread
> > > does not work in another thread regardless of
> synchronisation and it
> > > is out of my control.
> >
> > SQLite's design was not "luck".  The design expects you to
> create unique
> > sqlite3 objects in each thread.  Effort and thought was put
> into that!
> >
> > http://www.sqlite.org/cvstrac/wiki?p=MultiThreading
> >
> > It was loosened a bit in 3.3.x:
> >
> >   http://www.sqlite.org/faq.html#q8
> >
> > What isn't allowed is multiple statements executing at the
> same time in
> > multiple threads against the same sqlite3* db object.  In order to
> > support that, SQLite would have to have extensive code
> protecting the
> > various internal data structures as well as ensuring concurrency.
> >
> > > This is not a situation that i would expect anyone to purposefully
> > > design becuase it makes multithreaded programming difficult,
> >
> > The purposeful design is that you make sqlite3 objects per
> thread.  That
> > way there is absolutely no danger of corruption or other bad issues.
> >
> > Roger
> >
> >
> >
> --
> ---
> > To unsubscribe, send email to [EMAIL PROTECTED]
> >
> --
> ---
> >
> >
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Using sqlite.exe

[Fred Williams]

Don't know why you are using the "backdoor" approach (Calling the
SQLite.exe module) accessing an SQLite database from Delphi, but you
might want to look at what these people have to offer:

www.aducom.com

I have been using their components for a while now and have been quite
happy with the results.  It would certainly prove to be much more
straight forward and most likely produce much better performance.

Fred

> -Original Message-
> From: Michael Hooker [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 30, 2006 9:22 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Using sqlite.exe
>
>
> Thank you Kees - this works!
>
> I have been running sqlite3.exe simply by clicking on its icon in My
> Computer and I wrongly assumed that doing this would
> automatically make the
> current directory the one where sqlite3.exe is found.  When I
> come to use it
> from within my Delphi program I shall ensure that I "cd" to
> the appropriate
> directory first.
>
> Just a suggestion for the programmers, but it would be helpful if
> sqlite3.exe came back with a response like "Database  opened" or
> "Database  created in directory "  - it would
> give those of us
> who don't often use command line programs a bit of a clue
> what's going on.
> I have forgotten a lot since my DOS days!
>
> Thanks once again - I can get on with my work now!
>
> Michael Hooker
>
> -Original Message-
> From: Kees Nuyt [mailto:[EMAIL PROTECTED]
> Sent: 30 December 2006 12:38
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Using sqlite.exe
>
>
>
> On Fri, 29 Dec 2006 18:46:58 -0600,  Michael Hooker wrote:
>
> >ya, I've found getting to stuff from within the shell program tricky
> >at times. Here is the easiest way, esp. since your db is in the same
> >directory as the .exe (assuming that directory to be C:\sqlite3...
> >replace as needed)
> >
> >C:\sqlite3\sqlite3.exe BaseStation.sqb
> >..
> >that will launch sqlite3 as well as open up your database all in one
> >command.
>
> Make that
>  C:\sqlite3\sqlite3.exe C:\sqlite3\BaseStation.sqb
> or you will end up creating the database in what happens to be
> the current directory,
>
> and then execute
>   .tables
> or
>   .schema
> to check what's in there.
> --
>   (  Kees Nuyt
>   )
> c[_]
>
> --
> --
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> --
> -
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.16.0/609 - Release
> Date: 29/12/2006
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.16.0/609 - Release
> Date: 29/12/2006
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] ETA for SQLite 3.3.9 ?

[Fred Williams]

Sounds like an assumption is being made that the sqlite.h file will always be 
present.  Never have received the *.h file without downloading the source, 
which most wrapper users never do.  And most likely don't want to know what an 
*.h file is anyway.

Fred

> -Original Message-
> From: Roger Binns [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 25, 2006 6:52 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ETA for SQLite 3.3.9 ?
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> [EMAIL PROTECTED] wrote:
> | I was thinking the same thing earlier today.
> | Perhaps sometime next week.
> 
> Another issue is checkin 3545 which disabled the loading of 
> extensions.
> ~ The problem is that those of us building wrappers for other 
> languages
> have no way of telling what SQLITE_OMIT's were active when the library
> was compiled.  I currently just assume the defaults that SQLite ships
> with, but now the default is different between 3.3.8 and 3.3.9.  (ie
> extension loading is present by default in 3.3.8 and not present by
> default in 3.3.9).  Asking users to supply the flags will be 
> fairly hard
> since they'll have to understand C compilation and the 
> autogeneration of
> these files.  Even harder if they get the SQLite library via 
> some other
> mechanism (eg the dll downloads from the SQLite site itself).
> 
> A suggested solution is to have program with code like this:
> 
> #ifdef SQLITE_OMIT_CURSOR
> ~  printf("#define SQLITE_OMIT_CURSOR\n")
> #endif
> #ifdef SQLITE_OMIT_LOAD_EXTENSION
> ~  printf("#define SQLITE_OMIT_LOAD_EXTENSION\n")
> #endif
> 
> As part of the "make install" process or something similar, run the
> binary and insert the output into sqlite3.h.  That way other 
> code using
> sqlite3.h will then know what functions are present in the
> binary/library corresponding to the .h
> 
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFFj8lzmOOfHg372QQRArApAJ4xjSt+W5DGQm66AGczvt/zg3gQKQCfdzyk
> tCXLwgD4r17KzAho7mAD69M=
> =nVsX
> -END PGP SIGNATURE-
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] ETA for SQLite 3.3.9 ?

[Fred Williams]

If it ain't broke, don't "fix" it? 

> -Original Message-
> From: Joe Wilson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 23, 2006 12:33 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] ETA for SQLite 3.3.9 ?
> 
> 
> it's been a while since 3.3.8.
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] calculate age

[Fred Williams]

Unfortunately our Congress seems to have a short memory, on top of
constantly appearing embarrassingly stupid and crooked as a snake.  I
remember the last time they messed with DST.  Seems little Yankee school
munchkins were being squashed by school buses in the resulting early
morning darkness.  Didn't take long for the voter outcry to reverse that
dumb a-- move :-(

Note to silicon designers:  Don't rush to adjust!

Fred

> -Original Message-
> From: Joe Wilson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 23, 2006 11:52 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] calculate age
>
>
> Holiday determination per country (or even per state/city)
> via an algorithm
> can only get you so far because it is at the whim of
> constantly changing
> local laws. You basically need a database of all the dates
> for the exceptions.
> Even getting a reliable source of such information for
> various countries is
> problematic.
>
> On a somewhat related topic, I wonder how many computer
> systems will be affected
> by the new US daylight savings time changes going into effect in 2007.
> What a mess. Son of Y2K - Y2K7DST.
>
> --- Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> > LOL! You should look at a function to determine if a day is
> a holiday.
> > Talk about ugly! In some places you literally need to know
> the weather
> > and the phase of the moon!
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Question about SQLite for Symbian

[Fred Williams]

Just looked and my old link to the Symbian/Borland C++ link is gone.
THere is a new link to something called "Carbide C++"  Must be "Ford
Tough."

Anyhow, here's the link:

http://www.forum.nokia.com/info/sw.nokia.com/id/fd975c95-4c71-4ec2-ad1d-
338f52156503/Carbide_cpp_Express.html


> -Original Message-
> From: Nuno Lucas [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 21, 2006 5:10 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Question about SQLite for Symbian
>
>
> On 12/21/06, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > I'd be surprised if a port to a non-mainstream OS was
> available for free,
> > but you never know. This may be your best bet:
>
> If my memory is not playing tricks, I seem to recall some years ago
> you could download a free development suite, including the Borland C++
> Builder 5.0 IDE.
>
> Regards,
> ~Nuno Lucas
>
> > see 6.0 Custom Modifications
> > http://www.hwaci.com/sw/sqlite/prosupport.html
> >
> > --- panslaw <[EMAIL PROTECTED]> wrote:
> > > I know that SQLite was written in C and I'm sure it's
> possible to port
> > > it for Symbian OS. But I wonder - maybe there is already
> (ready to use
> > > )any SQLite library for Symbian OS? It's really importent
> for to get information
> > > about SQLite and Symbian - thanks in advance for any answers.
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> --
> ---
> > To unsubscribe, send email to [EMAIL PROTECTED]
> >
> --
> ---
> >
> >
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] multiple order by value bug?

[Fred Williams]

I also have an issue with "Order By" with one of my queries as well.  I am 
doing a multi field Order By and the second of the two fields does not sort in 
the correct order.  I do not have the code in front of me, so can't supply any 
details.

I have been killing bigger alligators on that project so the Order By issue is 
on the "to do" list.  I just figured it was my Select statement, although it is 
pretty straight forward, as I remember.  Perhaps there is a bug report in the 
making.

Fred

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 12, 2006 2:41 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] multiple order by value bug?
> 
> 
> Will Leshner írta: 
> 
> > On 12/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 
> > 
> >> This query works fine (I think my collate function too), but if I 
> >> accomodate
> >> it with "ORDER BY szemely.nev,szemely.anyanev,kereset.datum", then 
> >> sorting
> >> is in wrong order.
> > 
> > Do you mean you have two "ORDER BY" clauses? Seems like 
> that would be
> > a syntax error, or, at best, undefined.
> 
> No, I accomodate only te kereset.datum colum to the ORDER BY 
> clause, and 
> then the result come wrong. 
> 
> The two columns (szemely.nev,szemely.anyanev) collated by my 
> func, and the 
> third column that I accomodate is collated by the default 
> sqlite func. 
> 
> I want to sort by szemely.nev and when szemely nev is equal, sort by 
> szemely.anyanev. Then I would like to sort the result by 
> kereset.datum. 
> 
> nev|anyanev|datum
> 1. aaa|bbb|111
> 2. aaa|bbb|112
> 3. aaa|bbc|111
> 4. aaa|bbc|112 
> 
> 
> regards
>  ---
> kiru
>  
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Interbase to SQLite

[Fred Williams]

How about Pascal?  Wordy like Basic, powerful like "C".

Download Turbo Delphi, and give it a look.

Fred

> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 07, 2006 4:11 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Interbase to SQLite
>
>
> OK, I think I get it now.
> There is no ready made dll, but I have to write one in C or C++.
> Trouble is I only know VB/VBA, so not too easy then.
>
> RBS
>
>
> -Original Message-
> From: Fred Williams [mailto:[EMAIL PROTECTED]
> Sent: 07 December 2006 17:43
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Interbase to SQLite
>
> well, now that you have one of the most powerful development platforms
> in the known universe installed, study up a bit (won't
> require much) on
> the "VCL" concept.
>
> There are VCL's available for both Interbase and SQLite.  Install them
> and sail on...  Or, if you are an old "C" coder break out the
> whip with
> nails embedded and slog and flog on through the relevant API's.  You
> will feel right at home :-)
>
> Fred
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 07, 2006 10:19 AM
> > To: sqlite-users@sqlite.org
> > Subject: Re: [sqlite] Interbase to SQLite
> >
> >
> > Hi Dennis,
> >
> > I have installed the whole lot and it went very smoothly.
> > Now though I am not sure what the next step is. Were you
> saying there
> > was a driver to connect to both Interbase and SQLite like an
> > ODBC driver?
> > Or did you have something else in mind?
> >
> > RBS
> >
> > > RB Smissaert wrote:
> > >> Unfortunately it looks it needs installing the .NET
> > framework and J#.
> > >> I will keep it in mind, but for now that has put me off
> this route.
> > >>
> > >>
> > > Yes, since Turbo C++ is based on BDS 2006 which supports C# and
> > > Delphi.Net development. As a result it uses .Net to support
> > the .Net SDK
> > > in the help system used for .Net development. So the .Net
> > framework and
> > > SDK are prerequisites. I am fairly certain the IDE itself
> > (i.e. editor,
> > > project manager, compiler, etc.) does not use .Net, they
> > were just too
> > > lazy to remove the requirements for the new single language Turbo
> > > versions. In fact, I think I saw some instructions for
> > installing BDS
> > > without the .Net framework somewhere on the web, but I
> > don't know where.
> > >
> > > If you are doing straight Win32 development, and Turbo
> C++ only does
> > > Win32, your application will not need .Net.
> > >
> > > I'm not sure why you think you needed J#, but that is not
> > required to
> > > the best of my knowledge.
> > >
> > > Dennis Cote
> > >
> > >
> > --
> > ---
> > > To unsubscribe, send email to [EMAIL PROTECTED]
> > >
> > --
> > ---
> > >
> > >
> > >
> >
> >
> >
> >
> > --
> > ---
> > To unsubscribe, send email to [EMAIL PROTECTED]
> > --
> > ---
> >
>
>
> --
> --
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> --
> -
>
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Interbase to SQLite

[Fred Williams]

well, now that you have one of the most powerful development platforms
in the known universe installed, study up a bit (won't require much) on
the "VCL" concept.

There are VCL's available for both Interbase and SQLite.  Install them
and sail on...  Or, if you are an old "C" coder break out the whip with
nails embedded and slog and flog on through the relevant API's.  You
will feel right at home :-)

Fred

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 07, 2006 10:19 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Interbase to SQLite
>
>
> Hi Dennis,
>
> I have installed the whole lot and it went very smoothly.
> Now though I am not sure what the next step is. Were you saying there
> was a driver to connect to both Interbase and SQLite like an
> ODBC driver?
> Or did you have something else in mind?
>
> RBS
>
> > RB Smissaert wrote:
> >> Unfortunately it looks it needs installing the .NET
> framework and J#.
> >> I will keep it in mind, but for now that has put me off this route.
> >>
> >>
> > Yes, since Turbo C++ is based on BDS 2006 which supports C# and
> > Delphi.Net development. As a result it uses .Net to support
> the .Net SDK
> > in the help system used for .Net development. So the .Net
> framework and
> > SDK are prerequisites. I am fairly certain the IDE itself
> (i.e. editor,
> > project manager, compiler, etc.) does not use .Net, they
> were just too
> > lazy to remove the requirements for the new single language Turbo
> > versions. In fact, I think I saw some instructions for
> installing BDS
> > without the .Net framework somewhere on the web, but I
> don't know where.
> >
> > If you are doing straight Win32 development, and Turbo C++ only does
> > Win32, your application will not need .Net.
> >
> > I'm not sure why you think you needed J#, but that is not
> required to
> > the best of my knowledge.
> >
> > Dennis Cote
> >
> >
> --
> ---
> > To unsubscribe, send email to [EMAIL PROTECTED]
> >
> --
> ---
> >
> >
> >
>
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Query generation

[Fred Williams]

Pusedo code:

set s.sql = 'select a from mytable where (b=0)';
if got.more then 
  set s.sql = s.sql + ' and ' + s.userinput;
...
set s.sql = s.sql + ';';

> -Original Message-
> From: Lloyd [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 07, 2006 2:46 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Query generation
> 
> 
> Hi,
>  I am generating queries dynamically from my program based on 
> the input.
> The primary part of the query is always
> 
> select a from mytable where (b=0) and
> 
> based on the user input I add more where clauses to my query like
> 
> select a from mytable where (b=0) and (x=10)
> 
> but in one case there in no where clause to add, so my final query
> become
> 
> select a from mytable where (b=0) and
> 
> and this is a syntax error.
> 
> Is there any option to add a null clause after the 'and' ?
> 
> Thanks,
>   Lloyd
> 
> 
> __
> Scanned and protected by Email scanner
> 
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
> 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Dealing with dates in the format yyyymmdd

[Fred Williams]

ribe it.
> >>
> >>So, do you reckon I could, given the fact that I have an
> integer number in
> >>SQLite like 20061203, convert this in SQLite to another
> integer number
> >
> > that
> >
> >>would give the number of days since 31 December 1899? Or do
> you think that
> >
> > I
> >
> >>could make accurate dates comparisons in SQLite with
> 20061203 etc.? I
> >>suppose the trouble will be with weeks and days, years and
> months would be
> >>fine. So, for example it won't be that simple to say if
> 20061203 is more
> >>than 10 weeks past 20060920, whereas it will be easy to
> calculate that it
> >
> > is
> >
> >>less than 3 months passed that date.
> >>Is there such a thing as the VB/VBA DateSerial in SQLite?
> This means given
> >>the year, the month number and day number you can make a date?
> >>
> >>RBS
> >>
> >>-Original Message-
> >>From: John Stanton [mailto:[EMAIL PROTECTED]
> >>Sent: 03 December 2006 18:23
> >>To: sqlite-users@sqlite.org
> >>Subject: Re: [sqlite] Dealing with dates in the format mmdd
> >>
> >>What do you mean by "integer format yyymmdd"?  Is it an
> integer based on
> >>an epoch or is it a number like 20061203 stored in a 32 bit word?
> >>
> >>We use Sqlite format dates and times and thereby get good
> SQL capability
> >>and have a small library of date function which interface
> into Unix and
> >>Windows date and time retrieval APIs.  A couple of simple
> Sqlite custom
> >>functions to do some date manipulation made the SQL simpler.
> >>
> >>Custom date functions are very easy to implement using
> Sqlite because
> >>you can use the Sqlite date routines and style as a basis.
> >>
> >>The Sqlite epoch based date format is elegant because it
> permits you to
> >>present date and time not only according to any time zone
> but to comply
> >>with more than just the Gregorian calendar - with Middle
> Eastern and
> >>Oriental ones should the need arise.
> >>
> >>RB Smissaert wrote:
> >>
> >>
> >>>Trouble is I need to import dates from Interbase that have
> the integer
> >>>format mmdd. How would I convert that (at import) to
> the SQLite date
> >>>format? I do the import via an ADO recordset and then move
> the data via
> >>>SQLite inserts.
> >>>
> >>>RBS
> >>>
> >>>-Original Message-
> >>>From: John Stanton [mailto:[EMAIL PROTECTED]
> >>>Sent: 03 December 2006 17:01
> >>>To: sqlite-users@sqlite.org
> >>>Subject: Re: [sqlite] Dealing with dates in the format mmdd
> >>>
> >>>Why not use the internal Sqlite date format.  Then date
> processing is
> >>>straight forward and you can use the conversion routines
> to present it
> >>>in the various national and ISO formats.
> >>>
> >>>Sqlite uses a very correct date storage format based on an
> epoch way
> >>>back in antiquity so that you can present it in any
> national format.
> >>>
> >>>Using the internal format date comparison is just a
> numeric compare,
> >>>which is efficient.
> >>>
> >>>If you need any special date presentation you can add a
> custome function
> >>>to Sqlite to achieve it from your SQL statement.
> >>>
> >>>RB Smissaert wrote:
> >>>
> >>>
> >>>
> >>>>Just thought of one reason why it I need something else
> in SQLite than
> >>>>mmdd in the date field and that is because I need
> date comparisons
> >>>>between different tables. So, I need to do: is fieldA + x
> days > fieldB?
> >>>>etc.
> >>>>This will be difficult with the mmdd format. I could of course
> update
> >>>>all the date fields in a VBA loop, but that might be a
> bit slow. So, if
> >>>>anybody has an idea how to convert integer mmdd to
> the Excel date
> >>>
> >>>format
> >>>
> >>>
> >>>
> >>>>in SQLite I would be interested.
> >>>>
> >>>>RBS
> >>>>
> >>>>-Original Message-
> >>>>From: RB Smissaert [mailto:[EMAIL PROTECTED]
> >>>>Sent: 03 December 2006 15:37
> >>>>To: sqlite-users@s

RE: [sqlite] Dealing with dates in the format yyyymmdd

[Fred Williams]

Still don't understand the issue.  Excel stores the date internally as
the integer as you describe, no matter how you chose to format the
cell's display.  Changing the display format does not change the cell's
internal format.  And to the best of my knowledge changing Excel's
internal cell storage structure is not possible.

Fred

> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 03, 2006 8:56 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Dealing with dates in the format mmdd
>
>
> I am familiar with Excel and I have tried that but it doesn't work.
> I find the only reliable way to put dates in Excel is to put
> the integer
> Excel date in like for example 39054 and then set the date
> format in the
> sheet.
>
> RBS
>
> -Original Message-
> From: Fred Williams [mailto:[EMAIL PROTECTED]
> Sent: 03 December 2006 14:41
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Dealing with dates in the format mmdd
>
> Is there a reason you can use Excel's "Format Cells" to
> accomplish what
> you wish? Enter a "Custom" format of "\mm\dd" in a cell and enter
> "=today()" as a value in that cell.  Have not fooled with Excel much
> lately, but I think you can even format a spreadsheet
> programmatically.
>
> Fred
>
> > -Original Message-
> > From: RB Smissaert [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, December 03, 2006 8:21 AM
> > To: sqlite-users@sqlite.org
> > Subject: [sqlite] Dealing with dates in the format mmdd
> >
> >
> > When moving data from Interbase to SQLite I have to convert
> > integer dates in
> > the format mmdd to Excel dates. These are integer numbers
> > counting the
> > days past 31 December 1899. With substr I can make it
> > dd/mm/ (I am in
> > the UK and that is the normal way to format dates) but the
> > problem is it
> > will be displayed in Excel like mm/dd/ if that would be a
> > possible date.
> > This is due to the US date format of Excel.
> > So, would it be possible in SQLite to make a date format like this:
> > dd/mmm/  so that would be 03/dec/2006
> > This would prevent Excel from putting the month first.
> > or alternatively make it the Excel integer date format so the
> > above date
> > would be: 39054
> >
> > I could handle the date formatting in VBA, but I would like
> > to do as much as
> > possible in SQLite as it will be faster and it would keep the
> > code neater.
> > Thanks for any advice.
> >
> > RBS
> >
> >
> >
> >
> > --
> > ---
> > To unsubscribe, send email to [EMAIL PROTECTED]
> > --
> > ---
> >
>
>
> --
> --
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> --
> -
>
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] Dealing with dates in the format yyyymmdd

[Fred Williams]

Is there a reason you can use Excel's "Format Cells" to accomplish what
you wish? Enter a "Custom" format of "\mm\dd" in a cell and enter
"=today()" as a value in that cell.  Have not fooled with Excel much
lately, but I think you can even format a spreadsheet programmatically.

Fred

> -Original Message-
> From: RB Smissaert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 03, 2006 8:21 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Dealing with dates in the format mmdd
>
>
> When moving data from Interbase to SQLite I have to convert
> integer dates in
> the format mmdd to Excel dates. These are integer numbers
> counting the
> days past 31 December 1899. With substr I can make it
> dd/mm/ (I am in
> the UK and that is the normal way to format dates) but the
> problem is it
> will be displayed in Excel like mm/dd/ if that would be a
> possible date.
> This is due to the US date format of Excel.
> So, would it be possible in SQLite to make a date format like this:
> dd/mmm/  so that would be 03/dec/2006
> This would prevent Excel from putting the month first.
> or alternatively make it the Excel integer date format so the
> above date
> would be: 39054
>
> I could handle the date formatting in VBA, but I would like
> to do as much as
> possible in SQLite as it will be faster and it would keep the
> code neater.
> Thanks for any advice.
>
> RBS
>
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] SELECT on empty fields ??

[Fred Williams]

That is why everything in the world is not painted grey.

There are those of us who find null values distinct and meaningful and
those who don't.  I personally prefer null (Unknown, etc.) values versus
contrived values which in effect mean I don't like dealing with nulls so
here's a blank string, or is that an empty string, missing value?

Or worse, zero vs. unknown?  Damn! there goes the AVG(), Count(), and
etc. function accuracy out the window!  Oh well, it sure is easy to
code!

Fred

> -Original Message-
> From: Darren Duncan [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 27, 2006 6:51 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] SELECT on empty fields ??
>
>
> At 5:36 PM -0600 11/27/06, Jay Sprenkle wrote:
> >On 11/27/06, Isaac Raway <[EMAIL PROTECTED]> wrote:
> >>I'd like to strongly second this. Avoid NULL columns, even
> at apparent cost.
> >>Having a valid default value is always better. If a design
> appears to
> >>require NULL values, then the design is likely critically flawed.
> >
> >Using NULLS is NOT a critical design flaw.
> >NULL means something specific and if you use it correctly it
> works perfectly.
> >NULL indicates when nothing has been entered into a field.
> >Not entering anything, and entering spaces or a default
> value, are different.
> >If you need that information then it's very useful. If you don't then
> >don't use it
> >by assigning default values.
>
> Perhaps an intention behind the existence of NULLs was a useful idea,
> but in practice, they are a big mess in SQL.
>
> The NULL is used in SQL for a multiplicity of unrelated meanings,
> some of which are: value is unknown, no value is applicable here,
> value is at its default / has yet to be assigned to, value can not be
> determined, result of that operation is invalid.
>
> In fact, I read somewhere that there are a good 12 distint meanings
> attached to NULLs, so we don't have 3-valued-logic, its
> 14-valued-logic.
>
> But regardless, if you are given a NULL, how do you know what
> it means?
>
> Moreover, SQL is inconsistent with itself in its treatment of NULLs,
> in some situations treating 2 nulls as being distinct, and in other
> situations treating them as non-distinct.
>
> So NULLs can be helpful to you if you are very careful, but often
> they are more trouble than they are worth, and wherever possible, one
> should use some other way to express the meaning of what they were
> using NULLs for.
>
> -- Darren Duncan
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] IS there some way of viewing an SQLite Database?

[Fred Williams]

Or, simply look here for a whole range of selections.

http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

I currently prefer SQLiteAdmin.exe

Fred

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Saturday, November 04, 2006 3:58 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] IS there some way of viewing an SQLite Database?
>
>
> >
> > I downloaded a program, DB commander Pro
> (http://www.dbcommander.com/), to
> > try to view an SQLite database.
> >
> > However, I need to set up a "Data Source (ODBC)"  (windows
> control panel).
> > What System DNS would I need to add for SQLite?
> >
> > Alternatively, is there some other way of viewing an SQLite
> database?
> > TIA!!
>
> You can try SQLiteManager:
> http://www.sqlabs.net/sqlitemanager.php
>
> Regards,
> Marco Bambini
> SQLabs
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] new sqlite-based webserver

[Fred Williams]

What'ch got it running on, a 286?  Tried three different times and got
tired waiting all three times :-(

Not going to stir much interest with response times like that!


> -Original Message-
> From: Günter Greschenz [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 09, 2006 12:04 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] new sqlite-based webserver
>
>
> hi,
>
> i dont know if anyone is interested in my new open source project...
> i implemented a little webserver with javascript as backend-language
> (1.7 from mozilla 2.0.rc1) and sqlite as datastorage (3.3.7)
> the server is serving himself on "http://greschenz.dyndns.org; :-)
> the source can be downloaded at
> "http://greschenz.dyndns.org/download/gas/;
> its compilable with gcc(linux) and vs2005(win32)
>
> please send me any comments / ideas...
>
> cu, gg
>
>
>
> --
> ---
> To unsubscribe, send email to [EMAIL PROTECTED]
> --
> ---
>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-