ADSCDX 9006: HB-xgrab memory allocation error

[TimStone]

Two of my clients have suddenly started experiencing a problem that generates an ADS error 9006 ( cannot allocate memory ) with HB_xgrab.

I cannot replicate, nor can I create a small code sample. The problem does not create an error.log file with this problem so I don't know what code triggers it.

I do know that it happens across two different versions of xBuilder ( March 06, and October 05 ) , and their appropriate versions of FWH.

The software on the October release has been running since December without a problem and suddenly this error started occuring this morning.

The installation with the March release actually started having problems last week with memory related issues using the older release, then upgraded to the newer version and the problem increased.

The problem will occur when trying to run an area of the program where multiple files are opened and data is stored in memory for display on a series of folder pages ( FWH ).

The software uses ADS, but one system uses LOCAL server and the other is using CLIENT SERVER.

Other clients with the same versions do not yet experience any problems.

It is my guess that either a piece of intrusive software is at play, but nothing shows up in testing, or a new security patch from Microsoft auto installed that may now conflict with xHarbour memory management.

Has anyone seen any evidence of this error recently, and does anyone have any clues.

Tim

[Antonio Linares]

Tim,

The problem you describe is very specific and it looks as a xharbour ADS RDD issue.

> ADS error 9006 ( cannot allocate memory ) with HB_xgrab.

You could create a log file from such ADS call, so when the error happens then you will know what memory amount is requested to be allocated.

[R.F.]

Tim:

That problem happends with DBF with memofields created with Clipper, SixDriver or Comix.

The problem is with the memosize block, which is not totally compatible with DBFCDX original format.

The 3rd. parties create the memo field with a size of 16 bytes, however, with the "REAL" FoxPro DBFCDX, the memo field should always been a 64 bytes long.

How to solve the problem:

You will need to create a brand new structure using the ARC tool.

Create a fresh structure with memofields with a memoblock size of 64 (default).

After creating the new empty dbf, using CLIPPER, (you read it, CLIPPER) open the new created DBF, Clipper will open it without any problem, and then, using an APPEND FROM, import the data from the old database into the new created structure.

Is very important that you create the new structre with ARC or using a xHarboour program.

[Antonio Linares]

Rene,

You should report this issue to Przemek as many users may face the same problem. Thanks.

[TimStone]

OK ... I hate to complicate the theory, but here are the facts:

1) The DBF and FPT were created with xHarbour / FWH and the ADS DBFCDX driver.

2) These have worked without failure now for several years.

3) The company using ADS Client Server found a virus on one workstation, disconnected it from the network, and still had the problem. They restored to a point prior to the virus, after cleaning all of the computers, and everything works.

4) The company using ADS LOCAL SERVER reports all machines are clean. However, apparently something occured on one computer that caused it to pass back corrupted data on two files. They did not have a viable backup. I tried exporting the data with ARC but that wouldn't work. dBase can't copy it either. dSalvage fixed a couple of small problems and says its OK. However, what worked was when I did an export using dClip41 ... but now apparently the client can't do an append to the files !

I have posted this on the xHarbour board.