Re: [sqlite] Getting error "file is encrypted or is not a database" when trying simple C example

[Fred Basset]

Yes I had done an "apt-get install sqlite" which had installed sqlite2.  I
removed it, installed sqlite3 and all is good now.


On Mon, May 26, 2014 at 8:26 AM, Donald Griggs <dfgri...@gmail.com> wrote:

> Hi Fred,
>
> At the risk of informing you of something you may already know,
> you should be able to convert an sqlite version 2 database to sqlite3
> easily using the command line commands as follows:
>
> sqlite OLD.DB .dump | sqlite3 NEW.DB
>
> http://www.sqlite.org/version3.html
>
>
> Donald
> ___
> 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] Getting error "file is encrypted or is not a database" when trying simple C example

[Fred Basset]

I am using sqlite3 version 2.8.17 on an Arm Debian Linux system.

I created a test table using these commands from Linux:

"
cat 01_create_tables.sql
CREATE TABLE PV_INTERVALDATA (
   timestamp DATE,
   T_ambient  REALNOT NULL,
   T_trunk1   REALNOT NULL,
   T_trunk4   REALNOT NULL
);

sqlite < 01_create_tables.sql pvintervaldata.sqlite
"

I then went to insert a row into the new database with this C code:

"
#include 
#include 

static int callback(void *NotUsed, int argc, char **argv, char **azColName){
  int i;
  for(i=0; i

Re: [sqlite] 64bit compatibility warnings

[fred]

> I think that in general it might be a good idea to update the code to
> not produce any 64 bit portability warnings, so that we know for sure,
> that compiling 64 bit does not introduce any 64 bit side effects or possible 
> bugs.

...as long as doing so does not break 32-bit code...

Fred

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

Re: [sqlite] SQLite 3.7.17 preview - 2x faster?

[fred]

> The link is dead. I'd like to know more about this so can you provide us
> with a live link?

The problem is the closing parenthesis has become part of the link in Max's
first email - remove it in your browser URL window and the link works fine.

Or -

http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/81dd029f-2f55-49f2-bd02-1a8ceb0373eb

Fred

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

Re: [sqlite] SQLite3

[fred]

> it would be wise if you use a tool like the SQLite Expert; that will
> generate statements that you can use on command line as well.

And a couple of other free tools are:

SQLite Administrator - http://sqliteadmin.orbmu2k.de/

SQLite Database Browser - http://sqlitebrowser.sourceforge.net/

Fred

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

[sqlite] "SQLite" Pronunciation

[fred]

OK, how does one pronounce "SQLite"? "see-kwel-lite"? "ess-kyoo-lite"?
"ess-kyoo-ell-lite"? "see-kwel-ite"? "ess-kyoo-ell-ite"? Or...?

I guess, to some extent, it may depend on whether one pronounces (or
mispronounces) "SQL" as "see-kwel" or as "ess-kyoo-ell".

I think I read someplace that the author of SQLite pronounced it as
"ess-kyoo-ell-ite". (?) I couldn't find any pronunciation mentioned on
sqlite.org.

Is there a consensus here? (Yes, I know that pronunciation matters little
on a mailing list.)

Gee, "see-plus-plus", "emm-eff-see", and "boost" (etc.) are all a lot
easier (to pronounce, anyway - ).

Fred

___
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]

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

[sqlite] Detach worked OK in 3.6.19 -- gets error #1 (Database is Locked) in 3.6.20.

[Fred Meier]

The following pseudo code works OK in 3.6.19 but the Detach gets error #1
(Database is Locked) in 3.6.20.
   1. Prepare a Select statement returning 1 or more rows
   2. Step the first row
   3. Exec Attach statement
   4. Exec Detach statement for previous Attach   (This is statement that
get error 1 in 3.6.20)

You may have decided to eliminate a dangerous feature?   I have coded a
workaround in my production applications.

Regards
Fred Meier
___
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" <dan-sql...@dp.id.au>
To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org>
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 <sqlite_l...@bcsft.com> 
> 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
<slav...@hearsay.demon.co.uk>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
<slav...@hearsay.demon.co.uk> 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 rega

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

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, <aba.elha...@comcast.net> 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
<j...@dodgen.us> 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" <d...@hwaci.com>
> Subject: Re: [sqlite] sqllogictest tool - please help :-)
> To: General Discussion of SQLite Database <sqlite-users@sqlite.org>
> 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"
> <sqlite-users@sqlite.org>
> 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
>>&g

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"
<sqlite-users@sqlite.org>
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] Clear Screen Command

[Fred J. Stephens]

Mihai Limbasan wrote:

> I don't think it's too OS-specific - I think it's really outside the 
> scope of the sqlite3 shell. The shell is really not intended to be a 
> presentation layer, it's supposed to be a demo application, debugging 
> helper, and quick-and-dirty manipulation tool. If a clear screen command 
> were to be implemented, then what next? Cursor positioning? Perhaps 
> output coloring? And so on :)
I asked this question a while back and was told of the Ctrl-L command. 
That works fine, but I think regarding the comments above, a "clear 
screen" command would help with all those uses without overly 
complicating the sqlite3 shell.
___
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] a suggestion to write tutorial for sqlite

[Fred J. Stephens]

I think one of the most lacking aspects of the documentation are 
examples. Perhaps this is better addressed in the proposed tutorial, but 
not all the "SQL Syntax" pages make it clear how to use the statement, 
especially the more complex ones like SELECT, and expressions.
The datetime use is also not always easy to grasp (as witnessed by 
questions on this list).
So, I think a tutorial is a great idea!
___
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] List Columns

[Fred J. Stephens]

Dennis Cote wrote:
> Fred J. Stephens wrote:
>> Is there a way to list the column names in a table from the SQLite 
>> command line interface? I know .schema  will show them, but the 
>> output seems like it would be difficult to parse so that only the column 
>> names are shown.
>>
> 
> See pragma table_info(table-name) at 
> http://www.sqlite.org/pragma.html#schema
Thanks Denis,
Thats just what I needed. I wasn't familiar with the pragma statements.
Fred Stephens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] List Columns

[Fred J. Stephens]

Is there a way to list the column names in a table from the SQLite 
command line interface? I know .schema  will show them, but the 
output seems like it would be difficult to parse so that only the column 
names are shown.

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

Re: [sqlite] reading MS Access 97 files

[Fred J. Stephens]

Rich Shepard wrote:
> On Thu, 10 Apr 2008, Fred J. Stephens wrote:
> 
>> But to us former Access users, "database" is quick shorthand.
> 
> Fred,
> 
>Access is a joke. At least, that's what my colleagues who must work in the
> Microsoft world tell me.
I agree. Thats why I said "former" user. Anyway, I am rusty in Access, 
haven't used
it since switching to Linux 4-5 years ago. I had forgotten all about the 
DAO, ADO stuff
that Michael mentioned.

>> And I did say later in the post that sqlite is a database engine.
> 
>That's ambiguous.
If it's good enough for DRH to refer to it thus on his website, it's 
good enough for me! :-)
I understand the distinction, but I was just trying to help John get a 
quick overview of the situation until more knowledgeable users chimed in.
Now they have, so I will bow out.
Fred Stephens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] reading MS Access 97 files

[Fred J. Stephens]

Rich Shepard wrote:
> On Thu, 10 Apr 2008, Fred J. Stephens wrote:
> 
>> No, SQLite IS a database.
> 
>Er, not so. It's a relational database management system that supports the
> creation of as many different databases as you care to write.
Right. I knew I was going to make a idiot of myself...
But to us former Access users, "database" is quick shorthand.
"SQLite is the most widely deployed SQL database engine in the world."
 From sqlite.org.
And I did say later in the post that sqlite is a database engine.

>Take a look at mdb-tools. It's a library that lets you read Acess data
> (and schema) files so you can move them to SQLite.
Good idea.

Fred Stephens

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

Re: [sqlite] reading MS Access 97 files

[Fred J. Stephens]

John Grant wrote:
> @All,
> 
> Thanks for the replies.  I would like to say that I am new to this, and
> I've spent many hours trying to find documentation so that I don't look
> like an idiot on any forums.  :)  With that said, I'm very confused.
No problem, I am probably going to make one out of myself, but I will 
try to help
until more competent advice comes along.

> I guess I was under the impression that SQLite was a library for reading
> databases of various formats. 
No, SQLite IS a database. It can be used to replace others like Access, 
MySQL etc. However, (and I went through this confusion when moving to 
Linux and away from Access) Access is more than a database engine, it 
also a report generator, query creator, form designer, etc.
SQLite is just the database engine (or library or command line tool).
You provide your own code to create the tables, insert data, and work 
with it.

  I have a file that can be viewed with MS
> Access.  I have tested this myself.  Open Office immediately closed
> (probably crashed) when I tried to open the file with its 'Base'
> program.  I need a library that can help me load that same data into my
> application.  It does not help me to view the data in MS Access or other
> applications.
What language is your application written in? You may be able to use the
ODBC driver from within that language.

> What do you mean when you say I need a driver?  Are you telling me that
> SQLite can read the file or not?  If not, do you know of a library that
> will help me with my task?
An ODBC (Open Database Connectivity) driver lets you read data out of a 
database, without having it's native application. I think that is 
roughly correct. So, no, SQLite won't open the file and won't help you 
until you get the data out of Access format. The only way I know offhand 
to do that without exporting it in csv (comma separated values) or 
something, is an ODBC driver.
Hope this helps.
Fred Stephens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] reading MS Access 97 files

[Fred J. Stephens]

Michael Hooker wrote:
> I dare say someone will ask why you don't use Access 97 (or later) to 
> display the file.  It would be the easiest option, after all!  If you don't 
> have Access try OpenOffice, it's free.
> 
> If you really want to use Sqlite I'd load the file into Access (or 
> OpenOffice), export it as comma or tab delimited text and start from there. 
> You won't get any pretty colours or text formatting in Sqlite.  And it may 
> be that the file has all sorts of strange columnar formatting, formulae and 
> labels that make it unsuitable for transfer to a plain ordinary database 
> format, where all rows have an equal number of columns, and each column has 
> the same type of data in it.  Spreadsheets are designed for flexible 
> display, whereas a database is inflexible (but that is often its strength - 
> you know that column 5 will always be the price of your widget, and not a 
> label or a formula).   If the Access file has many pages, each page will 
> have to be exported and turned into a separate table, with any necessary 
> linking done through your Sqlite SELECT queries.
I'm confused here - are we talking about Access, the database or Excel 
the spreadsheet? You are probably right about the easiest way to get the 
data out so he can use it though, except that I don't think OO handles 
Access databases except through the ODBC driver.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] reading MS Access 97 files

[Fred J. Stephens]

John Grant wrote:
> Hello,
> 
> I'm new to database programming.  I'm trying to display information from
> a file that is said to "use the Access 97 format".  Can SQLite help me?
> If so, where should begin?
You probably need an ODBC driver to display the data. I don't think 
SQLite will be any help until you get the data out. Then, you could 
store it in SQLite instead of Access.
There are ODBC drivers available, for use in Open Office I think, and 
others. Try searching for Access +ODBC

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

Re: [sqlite] Limit Column Width

[Fred J. Stephens]

Dennis Cote wrote:

> You can use the replace() function to strip the newlines from your 
> strings. You could replace the newlines with empty strings or with a 
> single space. The trick is entering the newlines. You can enter them 
> directly in an sql script file.
> 
> select replace(some_column, '
> ',' ') from a_table;
> 
> Or you can use a cast and enter the expected newline characters for your 
> system (i.e. Windows is 0d0a, *nix is 0a, etc).
> 
> select replace(some_column, cast(x'0d0a' as text), ' ') from table
> 
> Then the columns can be truncated using the substr() function as you 
> suggest. The resulting strings should fit in your grid.
Thanks Dennis! Works great. This is what I came up with:

NOTES="$(cmd2db ".mode column" ".width 3 80" ".headers off" "SELECT 
id,replace(substr(note,1,80),cast(x'0a' as text),' ') FROM notes WHERE 
type LIKE '%$TYPE%'$SUBTYPE LIMIT $LMT;")"

echo"$NOTES"|sed -e 's/ / /g'   

I'm using sed to replace tabs with a space.I suppose I could use another 
  replace-cast in the SQL. cmd2db is a really simple function to pass 
multiple commands to sqlite. I'm sure there is a better way, but this works.

NOTES is a table in my personal information manager to store random text.

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

[sqlite] Limit Column Width

[Fred J. Stephens]

How can I limit the width of column returned by a query?
In a bash script I am returning an ID, and a text field from a table. 
The text field can be any length, contain newlines, etc. The problems is 
if a row of results contains a new line, the "grid" of rows and columns 
is messed up. I can limit the length of the returned text with 
substr(test,1,80), but that doesn't stop the newline appearing in the 
output. Neither does .mode column, .width 3 80 (3 for the ID, 80 for the 
text).
I have tried dozens of combinations of piping the output to sed & tr to 
try and remove any newlines, but if I do so, the output "grid" is all 
crunched together with the next ID on the same row as the previous text.

What I need is for each row of the query results to end at 80 characters 
or so and not wrap to another line - ie: one row per line.
I hope I am making sense here.
Any suggestions appreciated.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Clear screen in command line interface

[Fred J. Stephens]

John Stanton wrote:
> Fred J. Stephens wrote:
>> Would it be possible to incorporate a clear screen command, like "clear" 
>> in BASH? This would be handy to keep the view in the command line 
>> interface uncluttered.
>> Maybe ".clear"?
> You have the source and it uses curses so the addition should be fairly 
> simple.
Now that I know about Ctrl-L, I can live with that.
Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Clear screen in command line interface

[Fred J. Stephens]

Derrell Lipman wrote:

> In konsole (and xterm, I'm pretty sure), you can just hit CTRL-L to
> clear the screen whenever you're at an sqlite> prompt.
Excellent! Thats what I needed.
Thank you.
Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Clear screen in command line interface

[Fred J. Stephens]

Mike McGonagle wrote:
> Hum, on the Mac (10.4.9), the terminal window can be cleared from within the
> terminal program itself. I would imagine that other terminal programs also
> provide this. Does this functionality really need to be in SQLite?
> Mike
You're right I guess. In Konsole under KDE at least, there is a "Clear 
Terminal" command.
With SQLite though it leaves you with a blank screen and no prompt. 
Hitting enter brings back the prompt, but at the BOTTOM of the screen.
Better than nothing I guess. I just thought it would probably be trivial 
to add this to SQLite's command line program.
Fred

> On Wed, Mar 26, 2008 at 1:59 PM, Fred J. Stephens <[EMAIL PROTECTED]> wrote:
> 
>> Would it be possible to incorporate a clear screen command, like "clear"
>> in BASH? This would be handy to keep the view in the command line
>> interface uncluttered.
>> Maybe ".clear"?
>> ___
>> 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] Clear screen in command line interface

[Fred J. Stephens]

Would it be possible to incorporate a clear screen command, like "clear" 
in BASH? This would be handy to keep the view in the command line 
interface uncluttered.
Maybe ".clear"?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Where is the database file created?

[Fred Janon]

Thanks, I did already read that page and all the other ones. I was asking a
question about SQLLite3.exe very precisely, I thought. The command line is
in my email and its result. I don't think there is any mention of in-memory
database in the feature list either. I thought it might help to improve the
documentation.

Thanks

Fred

On 3/22/08, Christian Smith <[EMAIL PROTECTED]> wrote:
>
> On Sat, Mar 22, 2008 at 06:44:45PM +0900, Fred Janon wrote:
> > Hi,
> >
> > I read the documentation, features and faq and could not find anything
> that
> > specifies where (which directory) the database file is stored. I
> launched
> > sqlite3.exe on windows without a database name, using the '.databases'
> > command, I get:
> >
> > sqlite> .databases
> > seq  name file
> > ---  ---
> > --
> > 0main
> > sqlite>
> >
> > and since it doesn't show a file, I presume that sqlite does actually
> > support in-memory temporary databases? Where is is documented?
>
>
> SQLite supports file and/or in-memory databases. The file is wherever you
> tell it to be. Start the sqlite3.exe command with an (unused) filename and
> you'll see that file created when you do any writes to this new database.
>
> You might want to start here:
> http://sqlite.org/quickstart.html
>
> >
> > Thanks
> >
> > 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] Where is the database file created?

[Fred Janon]

Hi,

I read the documentation, features and faq and could not find anything that
specifies where (which directory) the database file is stored. I launched
sqlite3.exe on windows without a database name, using the '.databases'
command, I get:

sqlite> .databases
seq  name file
---  ---
--
0main
sqlite>

and since it doesn't show a file, I presume that sqlite does actually
support in-memory temporary databases? Where is is documented?

SQLite is cool, I started using it today, created a couple of tables, used a
few selects with join with no surprise. Nice and clean. Good job SQlite
team. I am doing a project on Android, I guess you'll see more and more
people working on Android.

Thanks

Fred
___
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] Question on Blobs

[Fred J. Stephens]

Dennis Cote wrote:
> If you are using the command line sqlite3 program rather than the 
> library, then all your input must be text that can appear on the command 
> line or be redirected from stdin. Handling binary data this way will be 
> difficult.
Thanks Dennis,
You cleared up allot for me. I think for my (simple) purposes, it's more 
trouble than it's worth. Plus, I wouldn't be able to search for a word 
or phrase without lots of trouble decoding first.
Mostly, I would just like to save the formating of text when I save a 
record, the view it again in an editor (as plain text).
Some data I am encrypting with gpg, but I am saving that as files 
outside the database.

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

Re: [sqlite] Question on Blobs

[Fred J. Stephens]

Thanks John & Dennis;
Looks like I am getting ahead of myself here. I'm just doing a simple 
PIM app as a BASH script that uses SQLite to store data. Probably I 
can't do this in a script as you could in C.

I find the formating of the text from a file is not saved if I read it 
and insert it into a table, so I was hoping there was a way to save the 
binary file and thus preserve all the formatting. Also it would let me 
save images etc. in the database.

When I get back to learning Python, maybe one of the SQLite wrappers 
will help me do this more easily. My present program is really just a 
way to get started until I move to Python. Also, it is good practice in 
BASH scripting, SQL and basic usage of SQLite.

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

Re: [sqlite] Question on Blobs

[Fred J. Stephens]

Mike McGonagle wrote:
> Hello all,
> I was hoping that someone might share some tips on working with Blobs? 
I am also curious about this.
For instance, how can I store a file in a table?
Not read the file and store the text, but the binary file itself?
Thanks.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Two commands at once

[Fred J. Stephens]

Derrell Lipman wrote:
> On Feb 16, 2008 12:01 PM, Fred J. Stephens <[EMAIL PROTECTED]> wrote:
>> How can I issue 2 commands to SQLite at the same time in a shell script?
>> I want to temporarily change the separator for the returned data,
>> something like:
>> sqlite3 database.db ".separator " ", SELECT first,last FROM address;"
> 
> sqlite3 database.db <<'EOF'
> .separator " "
> SELECT first, last FROM address;
> EOF
Ah, the here doc! I hadn't thought of that.
Thanks very much.
Fred
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Two commands at once

[Fred J. Stephens]

How can I issue 2 commands to SQLite at the same time in a shell script?
I want to temporarily change the separator for the returned data, 
something like:
sqlite3 database.db ".separator " ", SELECT first,last FROM address;"

But I can't get it to work.
Thanks.
___
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] How do I get back command history in v3.5.4?

[Fred J. Stephens]

On 1/16/08, John Stanton <[EMAIL PROTECTED]> wrote:
> Do you have readline installed on your Linux machine?  If not download
> the package, configure and install.  Then compile Sqlite with readline.
John,
Yes I do have readline installed, and as I said, SQLite worked fine
with the version from the Ubuntu package repositories (3.4.2). I would
just use that one, but I am concerned about the possible data
corruption bug fixed in 3.5.4.
Thanks for the reply. Any other suggestions?

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

[sqlite] How do I get back command history in v3.5.4?

[Fred J. Stephens]

Just replaced SQLite v 3.42 on Kubuntu 7.10 with the new v3.45 binary
downloaded from sqlite.org. it works fine, but now I don't have the
(essential, to me) command history. I have searched the forums and
read that it requires readline. I do have /lib/libreadline.so.5.
I tried compiling from source but get errors, 137 if I remember
correctly. Tried editing the make file to enable readline and putting
in the path to the readline library, but I still get errors compiling.
Isn't readline support supposed to be automatically detected on Linux
by configure?

If I can't get this fixed, how likely is the possible  data corruption
problem that was corrected by 3.5.4?  Will I have to wait for the new
version to hit the Ubuntu repositories? Maybe I am spoiled by 3-4
years on Gentoo , in having the latest versions available, but if data
corruption is an issue I would like to use the new version.

Another curious thing is that the original binary for sqlite3 is only
about 32k, while this new one is 300k! The file command shows that
they are both dynamically linked and stripped, so I don't understand
the huge difference in size.

Any information appreciated

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

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 // <http://plasmasturm.org/>


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]
-