Hi Lorenzo,

I was doing some tests with it last week, see how curious life is :)

I've read sqlite site and it says that 10Gb is its upper limit.

I've started looking at it because I was thinking about using  it for a cheap 
sql-rdd via usrrdd, but I've not reached the point where I can say that (I 
think) it is feasible or not.

BTW, I think it could be usefull to have an extended text into command for sql, 
or html or any other situation where you need to mix some other language with 
clipper code.

I mean, for example

local cfielda, cfieldb, ctable, ckey

cfielda := 'xxx'
cfieldb := 'yyy'
ctable := 'orders'
ckey := '001102'

text into csql
   select $cfielda,$cfieldb from $ctable
   where $cfielda = $ckey
endtext

the same could be usefull for html, xml and so on.

Anyway, with a 2million records table, nearly 100Mb with one index, searching 
for a value takes no time, doing a

select tipo,count(*) from retrossn group by tipo

on the same table, without indexes, on a hackintosh :O with 1.5Gb of ram and a 
PIV 3GHz took around 15-20 seconds (I think a dbEval() could take more time).


Maurilio.


PS. Anyway, I was also thinking about the fact that when I wrote contrib/mysql 
I was trying to mimick clipper table methods, while it could be more 
simple/powerfull to try to move away from clipper way of doing things given 
that sql is a higher level language than clipper.



> Is there anybody with experiences with sqlite?
>
> I'll make some questions assuming "yes" of the one above :)
>
> Is its "query" performance comparable to db like postgresql or mysql?
>
> Since it can be embedded, could it be possible to speed up the DBF
> import? ( that is avoid DBF -> TEXT -> SQL )
>
> Is there anybody who has already done an interface like
> contrib/hbpgsql for sqlite?
>
> I'm evaluating sqlite to "provide SQL interface to DBFs" for small
> offices where the maintenance of a SQL server could be problematic.
>
> The main requirement is IMPORT SPEED since near 10GB of DBFs need to
> be imported, indexed and pre-calculated in 1-2 hours and QUERY SPEED
> since there is nothing worse than wait more than 3secs for a web page.
>
> best regards,
> Lorenzo
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to