EDIT slow to relinquish control after DOWN ARROW or PAGE DOWN

[FoxEgg]

New problem...

I browse all the records in a particular patients file by using an EDIT and first I set a filter

SET FILTER TO FILE_NUM = FNUM
 
... and then I 

EDIT FIELDS 1,2,3,4,5 etc WHILE FILE_NUM = FNUM

The problem is that if I go down to the last edit page and then I push a DOWN ARROW or a PAGE DOWN once more then the thing disappears forever or until it decides to give me back control. I presume it is because it is a monstrously big database.

I would have thought that the filter would prevent that sort of behaviour.

 

[FoxEgg]

OK so if I change the command

EDIT FIELDS 1,2,3,4,5 etc WHILE FILE_NUM = FNUM

to

EDIT FIELDS 1,2,3,4,5 etc



and rely on the FILTER alone...

Then going DOWN is OK but GOING UP replicates the slow release / no refresh problem


Mmmmmmmmmmmmm

FoxEgg

 

[JRB-Bldr]

Moving from record to record with a FILTER on has always been a potentially slow process in a Browse screen.

In a "monstrously big database" this problem is even worse.

It would be much better to be browsing on a sub-set of the data table where only the FILE_NUM = FNUM records exist.

You can create a blank 'dummy' table to be browsed and then populate it dynamically with records as the specific FNUM is selected.

Another, less desirable, possibility would be to have an Index on FILE_NUM and have it active. Then when FNUM is selected you do a SEEK - followed by your Up/Down arrow movement.

Good Luck,
JRB-Bldr

 

[DSummZZZ]

As JRB-Bldr said:

Moving from record to record with a FILTER on has always been a potentially slow process in a Browse screen.

I just wanted to add that the reason behind this is that for each record displayed, Fox has to read through the table sequentially until it finds a enough matching records to populate the browse window. And yes, on a huge table, it could take way more time than tolerable.

In my opinion, filters are a bad idea, unless you are maybe doing some testing on a very small set of data.
Preferably, do like he said and use a subset by running a query, or at least create indexes on the fields you would normally set a filter to and use a BROWSE FOR type of condition.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[TamarGranor]

I just wanted to add that the reason behind this is that for each record displayed, Fox has to read through the table sequentially until it finds a enough matching records to populate the browse window. And yes, on a huge table, it could take way more time than tolerable.
In my opinion, filters are a bad idea, unless you are maybe doing some testing on a very small set of data.

Actually, filters are Rushmore-optimizable, using the same rules as for any other optimizable command.

Tamar

 

[FoxEgg]

Thanks again everyone.

I have always been aware the SET FILTER TO is not the fastest routine.... (Tamar's qualification duly noted)....but it worked .. however now I will dump it to get a better solution.

OK so maybe I can use the COPY TO command from my adjacent post (which solved that problem) and create a CURSOR DBF...

Then edit the CURSOR... but my question is then how do I UPDATE the records from the corrected CURSOR without duplicating records in the original database ???

((I think I'll go and look up UPDATE as a command just in case I guessed it))

JF

 

[JRB-Bldr]

There are a number of ways of committing changes from the Browse Cursor to the 'real' data table.

One way is to 'flag' changes made to the cursor and then scan the cursor records for changes.
Upon encountering a changed record, issue an

UPDATE <realtable>;
   SET <whatever> = <new value>
WHERE <expression>

Another way would be to set up a RELATION between your Cursor and the 'real' table. When changes are made to the cursor, push them back to the 'real' table.

There are a lot of ways in addition to these mentioned.

Good Luck,
JRB-Bldr

 

[DSummZZZ]

Actually, filters are Rushmore-optimizable, using the same rules as for any other optimizable command.

Well, I'll be. I thought that only applied to VFP not 2.x.





-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm