Major problems with FWH 13.09 / xHb ...

[TimStone]

This is going to be hard to resolve, but any help will be greatly appreciated.

I am using FWH 13.09 and xHarbour ( .com ) Aug 2010. These problems are all related to 13.08 / 13.09. Its a huge amount of work to roll back to 13.06 which was the "last known good" release for me.

Problem 1: xBrowse and mouse control
Using an xbrowse, with a .dbf, where the view is of records found with "odba:SetScopeTop( abc )" and "odba:SetScopeBottom( xyz )". When clicking on a row, may see the highlight bar go to that row, then jump back to an earlier row. No matter how many times this is clicked, the same problem occurs.

This is seen on an invoice when xbrowsing parts or labor that have been posted. Again, only records within the scope ( matching to the invoice number ) will be affected. It also seems to be tied to some, but not all, invoices.

The keyboard works correctly. Using page up or page down, and the arrow keys, work fine for navigating. However, if the mouse has been used, and then the keyboard, it may take several rows of movement to catch up and then it continues correctly.

Problem 2: Speed with data access
Where I am seeing the problems is with Advantage Database Server ( Remote ). All data accessing is suddenly much slower

All previous FWH builds ( prior to 13.08 ) worked with the same code and no evidence of any issues.

Your input is greatly appreciated.

Tim

[nageswaragunupudi]

Is problem.2 limited only to access through XBrowse or is there general slow down in access of data?

We are going to check if there are any changes that might cause the problem.1.

Meanwhile please let us know:
a) Approx size of the DBF ( number or records )
b) Does the DBF contain many deleted records?
c) Do you have the habit of creating an index tag on DELETED() and setting filter to "!DELETED()" ?

Notes on point (c):

If we set filter to "!DELETED()", this filter is resolved by the Server. If not client receives records including deleted records and client filters out the deleted records. In some cases this affects performance.

Without this filter, results of AdsKeyNo() and AdsKeyCount() are not accurate. This also causes unexpected record positioning in XBrowse because XBrowse depends a lot on KeyNo().

When the scoped set of records contain more deleted records, the problems may be more visible and that explains different behavior with different scoped sets of records ( different invoices ).

General recommendation is that
We create an additonal index tag "INDEX ON DELETED() TAG DELETED". Name of tag is not important.
And then we set filter "SET FILTER TO !DELETED()". In case we set some other filter, add the condition " .AND. !DELETED()".

[TimStone]

No, I do not use a deleted tag. I never have done that and the performance has been fine in the past.

I am using a set of updated libraries from Antonio, and perhaps those have some debugging code turned on that might slow down the processing ?

No, it is not exclusive to xbrowse. Some of these files have 60,000 - 80,000 records, including memo fields. There could even be more.

In one case, I want to run a report and manipulate data. In that case, I have a pair of temporary files which I first zap. Then, using an index, I do a soft seek on a record, and then engage in a DO WHILE loop. It may well be for records in a date range. For each matching record, I append a blank record in the temp file, copy the data, and save it. I'm using data objects and its quite simple. So, although I may have 60,000 records in the main file, using the index I seek the first date, then copy over perhaps a couple days of data ( usually far less than 1000 records ). Then the report is run against the temp files. It used to be very fast. Now it can take over a minute to get 2 days worth of data.

The DBF's may contain a number of deleted records. Tomorrow I will do a pack on those files to remove the deleted records to see if I can get better performance.

[TimStone]

I just did two things to help understand this:

1) I removed all deleted records from both the parts, and the labor, files. Thus they were perfectly clean.
2) I ran a report for 15 days. The system task was to go to the first matching date record, then copy individual records to the empty temporary file.
3) There were a total of 614 records ( all in sequence ) copied
4) The time to do this ( populate the two temporary files ) was 58 seconds.
5) The exact same process, using a build with 13.06, took 3 seconds ! ( Not a typo, 3 seconds before versus 58 seconds now ).

[Antonio Linares]

Tim,

I am using a set of updated libraries from Antonio, and perhaps those have some debugging code turned on that might slow down the processing ?

No, I never include debug code in the libraries

Tim, IMO what you describe it is not related with FWH at all. It seems related to the xHarbour (different) versions that you are using, or something that has changed on your network or pcs.

[nageswaragunupudi]

It does not seem to be relating to fwh or xbrowse.
But surely I agree this kind of delay is totally unacceptable. What you are doing should work very fast, even if there are many deleted records.
We need to look for the reason elsewhere.

[TimStone]

OK ... but tell me where my logic is wrong:

1) The problems are occurring at most of my installs. Essentially, the systems are slowing down to a crawl, with multiple problems arising. Its not just one location.
2) My client's computers have not changed
3) My computer has not changed
4) My code is the same
5) My xHarbour has not changed
6) My tools have not changed
7) My build has not changed
FWH HAS changed. The first set of libs would not work, so I'm using a build from the ones Antonio sent me after Build 2 had also failed.

So, since only the FWH has changed, where else might the problem lie ?

Tim