Page 2 of 2

Re: Grid_1 command - performance?

Posted: Mon Apr 12, 2021 2:14 pm
by andyglezl
GeoffBarnard wrote:
Sun Apr 11, 2021 6:50 pm
Hello,

I've been playing with HMG for a couple of years, byt have just tried something a little more exciting.

I've used the GRID_35 demo prog, with some slight changes, to try to test a CDX data file/index from a commercial application regarding compatibility.

The dbf is about 100 Mb, with nearly a million records, and the file is working perfectly in the current application (my own code using 'C' with the Codebase library).

The GRID_35 demo prog has been changed to use my file/index, and it works fine for the initial display. But when I press END to drop to the bottom of the file, initially nothing happens, then the last screen-full of records appears one-by one, with a second or two pause between each one. On my system, the end screen would appear/fill almost instantly, as would any intervening screen.

The data appears to be correct, so I don't think there's a problem with the index (which was generated by by system). The GRID has calculated the top record for the screen and is displaying down from that to the EOF.

The process seems to be 'working', just sooo slowly. Am I missing anything regarding HMG, or the use of the GRID command.

Geoff - Guisborough, England

Maybe this help...

viewtopic.php?f=24&t=4826&p=45910&hilit ... ese#p45910

Re: Grid_1 command - performance?

Posted: Mon Apr 12, 2021 3:45 pm
by GeoffBarnard
BROWSE.02 works much better. Great.

More detailed reply lost by forum??

Thanks. Geoff

Re: Grid_1 command - performance?

Posted: Mon Apr 12, 2021 4:18 pm
by franco
In my invoicing program I use grid for invoice. Handles 100 records per invoice ok.
For inventory lookup to add to invoice I use a browse 1,000,000 records.

Re: Grid_1 command - performance?

Posted: Wed Apr 14, 2021 12:56 am
by AUGE_OHR
andyglezl wrote:
Mon Apr 12, 2021 2:14 pm
Maybe this help...
viewtopic.php?f=24&t=4826&p=45910&hilit ... ese#p45910
good point :!:

when have many DELETED() Record but "hide" it with SET DELETED ON than you can get that slow down Effect

as i do not "re-use" DELETED() i use

Code: Select all

   INDEX ON FIELD TO XYZ FOR !DELETED()
to avoid those Problem

Re: Grid_1 command - performance?

Posted: Thu Apr 15, 2021 8:08 pm
by GeoffBarnard
Thanks for your comments.

As noted, the BROWSE control seems NOT to have this problem.

Regarding the suggestion above, I should note that the database has VERY few deleted records, and SET DELETED is not ON. I've checked the data in the full working application, and there are no deleted records in the last couple of pages at least.

Maybe I should create indexes using NDX and NTX and see if they behave the same?

Geoff

Re: Grid_1 command - performance?

Posted: Thu Apr 15, 2021 9:52 pm
by GeoffBarnard
Still interested to answer the 'why' here.

I've gone back to the GRID I tried first, based from the GRID_35 sample.

Regen this prog to use the same dbf, but now with a NTX file using the same key.

The CDX file was 6 or so Mb, the NTX is 24 or so Mb. That's by the way.

When I use END to drop to the bottom of the file, the screen is updated slowly line-by-line, but much faster than with the CDX. Maybe 3 or 4 times faster. A Page-UP is slow. but barely practical. Both better than the CDX option.

So it's not JUST about the CDX??

Geoff

Re: Grid_1 command - performance?

Posted: Fri Apr 16, 2021 4:38 pm
by franco
Jimmy is only using deleted as example. As I sais above for my invoicing I use a grid.
My invoice items file has 1,500,000 records. My Invoice File gas 50,000 records
if invoice field inv_no equals 100175.

Code: Select all

use invoice 
index is inv_no
use pinv_it
index is inv   / I use different field name to stop confusion.
set relation to inv into INVOICE
select invoice 
seek '100175'
select inv_item
index on inv to invtemp for inv = invoice->inv_no
Now I use GRID to work with the data which may only be 5 items.
To scan any full tables I use browse. I never use browse to work with data. I never use grid to scan data.