index CDX on the fly
in [Visual Objects]
|
Prev: Time flies....
Next: Serial comm in a VOService
From: Geoff Schaller on 6 Jan 2010 16:32 Paolo. Actually you are wrong on several fronts. With SQL you can do the exact same thing. You can buffer your selects in just the same way. Let us say (for example) your browser theoretically is looking at 1 million rows. Well you actually only retrieve TOP 40. If the user presses page down you simply refresh the recordset and get the next (40... whatever) rows. You just continually adjust the TOP x you actually calling. The user can only ever see 30 or 40 or so and this is what it continually retrieves. And then there is asynchronous selects... However how stupid are most DBF style browsers anyway? We used to just open the table... at the top or bottom. What we REALLY should have done was open up on 'this month' or some context that made sense. Well with SQL you just get more intelligent about context. Users get used to it very quickly because in truth, it is far more logical. But where SQL shines over DBF is in that you can create an order over any combination of fields through filters. Filters and scopes in SQL are the same thing and are ultra efficient. And you can do massive updates and computations in a fraction of a second that might take DBFs minutes or even hours. Geoff "Perfect Solution Software" <infoNOSPAM1DELETE(a)magicorg.com> wrote in message news:4b44cd87$0$709$5fc30a8(a)news.tiscali.it: > Ginny > > But when you show a window with a SQL browser in it, at first the browser is > empty, then the > user selects what he would like to query, presses a button to start the > query and then you show > the result data in the browser or as it is common in the DBF world and > bBrowser, > the data are displayed as soon as the window is shown and then the user can > change the date interval, select a customer to show only that data etc.. > To be more clear I mean that in DBF you do not have to care about the data > you have > to display in the browser as it is bBrowser that stops reading data as soon > as the "buffer" is full even > there is 1GB DBF, in SQL is the same?? Or you have to take care about the > data > queried and returned to the browser?? > For example if someone queries a period of 10 years you have to wait for the > SQL engine > to return all the data to the browser or as it is in DBF when the bBrowser > "buffer" is full it stops. > Hope this question is not too stupid. I do not know very much about SQL. > > Paolo > > > > > > > > SQL can do stuff like "select col1, col2 from someTable where {any > > condition you can dream up} order by {whatever order you want}" and it > > will outperform DBF. But the SQL query analyzer can help you see where > > perhaps having certain columns in an index could speed this up even more. > > Even today I am sometimes surprised by the query analyzer's suggestions, > > but it is pretty much always right. You don't add the indexes as you need > > them for one report - you just add them to the database and SQL maintains > > statistics about the data so it know what query plan to generate for > > queries including which indexes it wants to use. > >
From: Geoff Schaller on 6 Jan 2010 16:34 This is another example of something which is instant in SQL. Re-ordering current data sets. You also don't have to match the index expression. You can re-order based on any criteria. "Amilcar A. Camargo" <amilcarcamargo(a)gmail.com> wrote in message news:k9h9k5thdph3bi9iajkt20kp45c77iv977(a)4ax.com: > Hi Paolo, > > On Tue, 5 Jan 2010 16:39:32 +0100, "Perfect Solution Software" > <infoNOSPAM1DELETE(a)magicorg.com> 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?? > > > I do this for browsers so the user can order data clicking on the column > header. My approach is to build temporary indexes (normally the file resides in > windows temp directory) as necessary. The catch: build your indexes based on > the 'scope' already applied to your dbf file so it will perform fast. > Otherwise, it could take too much time and upset your users. > > To deal with final clean up, extend your base server Close() method and, after > calling SUPER, delete your temp file. It should prove no problem. > > Have you considered migrating to SQL? This could be far easier in that > environment. > > HTH, > Amilcar A. Camargo F. > Guatemala, C. A.
From: Perfect Solution Software on 7 Jan 2010 11:30 OK, you convinced me to take a very close look to SQL in my future development. Thanks to all Paolo Kalc "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> ha scritto nel messaggio news:6k71n.67278$ze1.58656(a)news-server.bigpond.net.au... > Paolo. > > Actually you are wrong on several fronts. With SQL you can do the exact > same thing. You can buffer your selects in just the same way. Let us say > (for example) your browser theoretically is looking at 1 million rows. > Well you actually only retrieve TOP 40. If the user presses page down you > simply refresh the recordset and get the next (40... whatever) rows. You > just continually adjust the TOP x you actually calling. The user can only > ever see 30 or 40 or so and this is what it continually retrieves. >
From: richard.townsendrose on 16 Jan 2010 06:52 Paolo. however one major drawback when generating selects is that not always does the data come up in a decent order. last year i was using a construction portal called "build on line" to generate information such as dates that revisions of documents were issued by bovis to my client for contract claims purposes. it was a nightmare as the data was NOT in drawing no and revision order, let alone in date issued order when revisions were issued several times. so it was export to csv, import to dbf and index for claims analysis richard
From: E®!k /!sser on 16 Jan 2010 08:10
Richard, > however one major drawback when generating selects is that not always > does the data come up in a decent order. Some people use an 'ORDER BY' clause in their query for this. regards, Erik "richard.townsendrose" <richard.townsendrose(a)googlemail.com> schreef in bericht news:ea9ffde4-2cc4-457b-b30b-6ba28e8405b5(a)s31g2000yqs.googlegroups.com... > Paolo. > > > last year i was using a construction portal called "build on line" to > generate information such as dates that revisions of documents were > issued by bovis to my client for contract claims purposes. > > it was a nightmare as the data was NOT in drawing no and revision > order, let alone in date issued order when revisions were issued > several times. > so it was export to csv, import to dbf and index for claims analysis > > richard |