index CDX on the fly
in [Visual Objects]
|
Prev: Time flies....
Next: Serial comm in a VOService
From: Geoff Schaller on 6 Jan 2010 04:40 Dirk, This really only works in a 'report' situation but is still tragic if there are a lot of rows. I think this guy is talking generic browsers where he is expecting a lot of data. This isn't unlike SQL where data volume is an important performance factor. Geoff "Dirk (Belgium)" <dirk.dot.herijgers(a)pbprojects.dot.be> wrote in message news:P9Y0n.2068$0a2.609(a)newsfe21.ams2: > Perfect Solution Software wrote: > > > > I use DBF files with CDX indexes with a lot of tags. > > But sometimes you need to display data in different ways not included > > in any Tag index. The idea is create a temporary index on the fly, > > display the DBF data and then when the user closes the browser > > displaying the data delete the index. Does anyone use this approach?? > > > > regards > > Paolo Kalc > > > Paolo, > > I do this all the time when creating reports. Just before sending the > table to ReportPro, I create a separate CDX index (with filter > conditions) and RP use this index with 1 tag inside for the report. > Because this index only have the records which are really needed, I > always have quick reports. > > Deleting this temporary index is just deleting a file on disk (after > closing the table). > > Dirk > > --
From: Dirk (Belgium) on 6 Jan 2010 05:42 Geoff Schaller wrote: > Dirk, > > This really only works in a 'report' situation but is still tragic if > there are a lot of rows. I think this guy is talking generic browsers > where he is expecting a lot of data. This isn't unlike SQL where data > volume is an important performance factor. > > Geoff > > > Geoff, Indeed, this approach is best in a report situation. I always start with a upper and lower scope (for example report between 2 dates). With this scopes set, the temporary index is created very quick. I have statistics in a DBF file and there is an index on the date field. When I need some statistics of 1 day, I place a top and bottom scope, and the temporary index is build in a few seconds, no matter how many records are in this really big DBF file !!! Dirk. --
From: Perfect Solution Software on 6 Jan 2010 07:14 Yes, I need data mostly for browser situations. I came up with a custom built temporary CDX index file. I set an upper and bottom scope, than go through the rest of the DBF file evaluating the filter condition and adding to the custom index only records that meet the filter using EVAL() Does SQL do something similar or with SQL this kind of things (I mean extracting particular data and sorting) is much faster than in DBF in this particular situation where you do not have indexed data. In SQL you alway first "extract" data from your file befor showing them in browser? How does SQL work compared to DBF?? The only thing I know about SQL is that the work is done on the server machine therefore the speed should be much better for SQL, but what else is the difference?? cbFilter := &( '{||' + self:cfilterstring + '}' ) self:oDBDocumenti:gotop() do while !self:oDBDocumenti:eof MyInfoMessage("elaborazione.....") IF self:oDBDocumenti:Eval( cbFilter,,, 1 ) self:oDBDocumenti:OrderKeyAdd('TMPORD', cTmpIndex) ENDIF self:oDBDocumenti:Skip(1) enddo and then set the order to TMPORD regards Paolo Kalc "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> ha scritto nel messaggio news:mUY0n.67200$ze1.38347(a)news-server.bigpond.net.au... > Dirk, > > This really only works in a 'report' situation but is still tragic if > there are a lot of rows. I think this guy is talking generic browsers > where he is expecting a lot of data. This isn't unlike SQL where data > volume is an important performance factor. > > Geoff > > > > "Dirk (Belgium)" <dirk.dot.herijgers(a)pbprojects.dot.be> wrote in message > news:P9Y0n.2068$0a2.609(a)newsfe21.ams2: > >> Perfect Solution Software wrote: >> >>
From: Alessandro Antonangeli on 6 Jan 2010 07:58 Hi Paolo Look also at the CreateOrder Help: may be that a oDbServer:SetOrderCondition(,cbFilter) oDbServer:CreateOrder('TMPORD', cTmpIndex) oDbServer:SetOrderCondition() could be faster -- Ciao Alessandro
From: Ginny Caughey on 6 Jan 2010 08:24
To answer your question about SQL - It's more than just that the work is done on the server machine, although only sending the data you actually need across the wire is a benefit. The biggest advantage is the SQL query processor - software that computer scientists who spend their whole lives specializing in data access constantly tweak to perfection. Combined with the right indexes and decent server hardware, you can do all manner of complex queries with great performance. (And where you don't have great performance, the best SQL databases come with query analyzers that will suggest where a new index might help a lot.) Even though I know the way my DBF data is used and have the indexes I need to maximize performance, my SQL reports run faster, and sometimes orders of magnitude faster, than the DBF versions. Of course I've rewritten my reports to specifically take advantage of SQL - if I just ran the old DBF code against a SQL database, I wouldn't see such a dramatic improvement. A second advantage of SQL that is important to my largest customers is security. Their administrators can control who gets to do what with the data at a very fine level. All I have to do is use authentication based on the user and the SQL engine does the rest. Of course if a customer chooses to leave security wide open on the database, that works too without any changes in my software. And finally, my customers are switching to the SQL versions of my apps because their databases have just grown too large for DBF files. They may have a decade or more of data and don't want to keep it off line or in different files. "Huge" dbf files when move to SQL make databases that are considered tiny by SQL standards. Not a specific advantage for customers, but for me now that I've worked in SQL for several years, I find designing and coding apps to run against a SQL database is quicker and easier and especially since it also allows me to use more modern languages like C# for new work. This does become an advantage to a customer if I can do the work in fewer hours (therefore costing them less), so it's not unusual for my customers these days who need custom work to choose to move to the SQL versions of my apps for that reason. -- Ginny Caughey www.wasteworks.com "Perfect Solution Software" <infoNOSPAM1DELETE(a)magicorg.com> wrote in message news:4b447ebe$0$6819$5fc30a8(a)news.tiscali.it... > Yes, I need data mostly for browser situations. > I came up with a custom built temporary CDX index file. > I set an upper and bottom scope, than go through the rest > of the DBF file evaluating the filter condition and adding to the custom > index only > records that meet the filter using EVAL() > Does SQL do something similar or with SQL this kind of things (I mean > extracting particular > data and sorting) is much faster than in DBF in this particular situation > where you do not have indexed data. > In SQL you alway first "extract" data from your file befor showing them in > browser? > How does SQL work compared to DBF?? > The only thing I know about SQL is that the work is done on the server > machine therefore the speed > should be much better for SQL, but what else is the difference?? > > cbFilter := &( '{||' + self:cfilterstring + '}' ) > > > > > self:oDBDocumenti:gotop() > > > > do while !self:oDBDocumenti:eof > > MyInfoMessage("elaborazione.....") > > IF self:oDBDocumenti:Eval( cbFilter,,, 1 ) > > > self:oDBDocumenti:OrderKeyAdd('TMPORD', cTmpIndex) > > ENDIF > > > self:oDBDocumenti:Skip(1) > > > enddo > > and then set the order to TMPORD > > > regards > Paolo Kalc > > "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> ha scritto nel > messaggio news:mUY0n.67200$ze1.38347(a)news-server.bigpond.net.au... >> Dirk, >> >> This really only works in a 'report' situation but is still tragic if >> there are a lot of rows. I think this guy is talking generic browsers >> where he is expecting a lot of data. This isn't unlike SQL where data >> volume is an important performance factor. >> >> Geoff >> >> >> >> "Dirk (Belgium)" <dirk.dot.herijgers(a)pbprojects.dot.be> wrote in message >> news:P9Y0n.2068$0a2.609(a)newsfe21.ams2: >> >>> Perfect Solution Software wrote: >>> >>> > > |