>Running into something really weird that almost has to be a local configuration issue. I'm working on a large application that's using an error handler that originated in Stonefield AppMaker and has been enhanced a bunch over the years. A couple of weeks ago, we made a change to the underlying ErrorLog table (widened one field so we could put some additional data into it).
>
>Since then, when an error occurs during my testing, VFP crashes.When I'm lucky, first I see an error message on the line that inserts data into the errorlog table. The error message is:
>
>“There is not enough disk space for .”
>
>Yes, with nothing between the word "for" and the period. The line of code it appears on is:
>
>

>		insert into ERRORLOG ;
>              (DATE, TIME, USER, TERMINAL, CUSTOMER, ALIAS,;
>               RECNUM, KEYFLD, ERRMSG1, ERRMSG2, ERRMSG3, ACTION, ;
>				MEMVARS, DETAILS, CALLSTACK) ;
>		   values ;
>		      (date(), time(), gcUSER_NAME, SysZero(), space(len(customer)), lcALIAS, ;
>               lnREC, lcKEY, lcLINE1, lcLINE2, lcLINE3, 'REBOOT',;
>               '', m.lcDetails, m.lcStackInfo)
>

>
>If I resume from this point, VFP crashes. The error log says it's C0000094. (More often, I get the crash without the error message.)
>
>What makes this interesting is that my client (another developer) and his customers aren't having this problem. Errors are logged as they should be.
>
>I've tried deleting and recreating the ErrorLog table from scratch. The lcDetails variable can be huge; I've added code to limit it to 254 chars just for testing. No joy there, either. I've tried renaming my FoxUser file so a new one is created.
>
>This is really slowing down my debugging. Open to any ideas.

1. If you have non-Microsoft antivirus, try disabling its real-time scanning component

2. Is your Errorlog table a conventional local file on conventional local storage, or something else e.g.
- Cloud-synced storage such as OneDrive or a SharePoint Online document library? If so you could try temporarily disabling sync for those files
- Is Windows 10 File History or any 3rd-party real-time/cloud backup software running?
- On a file server or NAS?

3. (you might want to try this first) Do you have another computer from which you can run your tests - to see if it's something in one particular computer or in your environment
- are you testing on a physical computer or a VM?

4. Are you actually running low on free space on *any* drive connected to your test machine? Do you have compression turned on for any drive in question - if so it's a good idea to be conservative about free space. For example, one rule of thumb for uncompressed drives is 15% free is yellow alert, 10% free is orange alert, 5% free is red alert. As a very rough rule of thumb you can double those values for compressed volumes

Update:

5. Maybe your ErrorLog table has subtle corruption (like a CHR( 0 ) in a memo or char column), or an index tag corruption