Memo field replace reports disk full error 2

[peteraharrison]

When using a memo field to store incrementing history, the program reports a &quot;disk full&quot; error when replacing <memofield> with <memofield> + <newstring>. When this occurs the <memofield> content is usually 64k or more and the added bytes are typically a few tens or a few hundreds of bytes. Obviously this is nowhere near the Foxpro memo field limit and the disk drives involved usually have 10GByte or more free space.
The application is running in an NTVDM on either NT 4.0 or 2000 Professional application servers. The problem can be demonstrated interactively once it occurs under program control and can be fixed (temporarily) by appending to a new structure and renaming etc. However, under normal use, the problem reappears in a short period.
Any ideas on this will be greatly appreciated.

 

[ramani]

Hi peter,
W2000 seems to corrupt the memo files when it is beyond some size. I faced this problem and solved it by strange way. I dont know if that same trick helps you. I have not bothered to probe in detail, 'coz I have either used non W2000 systems in such places or upgrading them to VFP base.

The solution however I provided is to add a line in the config.fp related to memlimits..

MEMLIMIT = 40, 4096, 16384 or something like that.



ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
Merry Christmas & Happy New Year

 

[peteraharrison]

Ramani,
Thanks for the input. We are actually running about 35 simultaneous instances of a Foxpro application in separate NTVDM domains on each of many servers. Each of the servers has 512MB of memory.
We do use MEMLIMIT - essential, because without it, the first instance of Foxpro will claim several hundred megs of memory and by the time the fourth or fifth instance starts, there is no memory left! We have the MEMLIMIT parameters set to ration each Foxpro instance to about 12 megs. We also have to run another TSR in each NTVDM that prevents each Foxpro instance from consuming the entire CPU.
You are quite right that the file is corrupted. Moving a misbehaving file set from a production server and testing it on an engineering computer produces the same error when trying to extend a memo field of more than 60k or so. Appending the damaged file contents to a fresh structure &quot;cures&quot; the problem, at least for a short period.
I am considering one of the commercial &quot;file fixer&quot; utilities to try to help with the problem. Does anyone have experience with any of these?

Again, thanks for the assistance,


Peter Harrison

 

[Jerry4DOS]

Any time I had a memo field corruption, it was when I was using FDP STANDARD, never when I was using FPD EXTENDED. I even corralled and saved a couple of instances of predictable corruptions, but I never traced it down far enough to figure out exactly what triggered the corruption -- maybe some day. . . .

 

[Scott24x7]

Peter,
For FoxPro 2.x tables, DSalvage (available from Halogram) is about the best thing going. I've been using it for years, and it is about as affective a table fixer as I've seen anywhere.
Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

 

[DRRAZGU]

FoxPro allows a maximum character variable size of 64K. If you are reading your memo field into a variable and then adding to it you will get the &quot;Disk Full&quot; error if the result exceeds 64K.

 

[peteraharrison]

In the extended version (2.6 (X)) the maximum string length is 2 gigabytes rather than the 64 kilobyte limit in the regular version. This can easily be verified by entering a few bytes into memo field and then running the line &quot;repl <memofield> with <memofield> + <memofield>&quot; repeatedly from the Command box (20 times will produce roughly a megabyte per each starting character) and then assigning <memofield> to a string. E.g. &quot;lcString = <memofield>&quot;. The string can then repeatedly be added to the memofield as desired, &quot;repl <memofield> with <memofield> + lcString&quot;, for example.
With a fresh structure this works fine, with a corrupted structure (nature and source of corruption unknown), this produces the disk full error. Out of nearly one thousand installations this has been seen only in three of four cases but is critical issue nonetheless, due to data loss.

Thanks for the input,

Peter.

 

[marcfree]

I'm trying to insert an bmp file in a general field and I get the message: Error creating OLE object. What to do to make fpw find the server application?

Thanks for any help

 

[DSummZZZ]

First off, I would avoid using general fields. They become huge, are flakey, and are hard to retrieve data out of once put in. You should consider using relative pathnames in a field instead.
That said, that error is either because of insufficient memory or Fox can't find the associated app. Maybe bitmaps are registered as using a non-ole app?


-Dave S.-

Even more Fox stuff at:

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

 

[marcfree]

Thank you for your help.

If bitmaps are registered as using a non-ole app, how to change this in Windows?

Whato do you mean with &quot;relative pathnames instead&quot;? It's a different way to do the same thing?

Thanks

 

[DSummZZZ]

You would change the association with the rgiht-click->Open With dialog. Select 'Always use this app to open ....'

What I mean by relative paths is, create a field in your table of type character say, 50 characters wide. Then store the name of the file, including the full path name in that field. Then when you want to access it, you can do something like:
@ 1, 1 say MyTable.BMPName BITMAP


-Dave S.-

Even more Fox stuff at:

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

 

[marcfree]

Thank you Dave but even doing...
&quot;change the association with the rgiht-click->Open With dialog. Select 'Always use this app to open ....&quot;
I still got the same message:&quot;error creating OLE object&quot;