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