>>>Thanks for your reply, i changed the files to 254 and rebooted but still got the same error, any other suggestions
>>
>>Other than switching to NT, I can't think of any. What was the FILES= setting before you changed it, and the exact line that you set it to; CONFIG.SYS is funny about things like spaces on the line; IOW:
>>
>>FILES=254
>>
>>is OK, but
>>
>>FILES = 254
>>
>>may not be
>
>There's a sys(2010) function which should return 255 in VFP (in previous versions it returned the FILES setting from config.sys). Whoever had this problem should heck it in the Help, there's some interesting text about the number of files that can be open simultaneously in VFP. Though, this sounds contradictory - VFP should never choke on this, because why would they ever increase the number of work areas to 32K - they could have happily left it at 255 if this setting still mattered.
>
>If I remember the original problem well, we had about 120 tables open, and then if they had memos and/or indexes, it would increase the number of open files to more than 255. This makes me wonder if the 255 file handles limit applies, or is this a problem on that one machine only? I've never had so many tables open at the same time. Maybe it's none of my business to judge, but if any significant group among these tables have a common structure, I'd rather keep them as one table, and have one procedure at the end of the processing to dispatch the changes into individual tables, if they really have to exist. I've had a system with 100-150 tables with identical structure, but no workstation ever had to open more than three at a time.

The problem that arises under Win9x is that there's a ceiling on the number of active file handles that cna be managed by the underlying file manager, whose roots are still based on the MSDOS-based file handle management scheme. It a ceiling on the number of open file handles that can be active on the system at one time, not for a single task, but for all system and application tasks needed to make servicing the active process possible. This is why each VM started has to allocate space for file handles within itself; the set of active handles is process-specific. And as noted in the docs under SYS(2010), you often can't have that many files open in VFP - the OS needs some handles to service your process, VFP has some for its own use (like the one pointed back at the .EXE, temp files, resource files and the like) and any given DBF may represent numerous open files - a DBF that contains a memo field and has a structural CDX uses at least 3 file handles.

In some cases VFP will close down some handles, caching the file state, in order to make the file handles unique to another, inactive, data session, available for the current process; this incurs overhead during a switch back to the original data session, since the file handles may have to be restored if the data needed can't be serviced from internal VFP memory cache.

In some cases, no real file handle exists; for example, a cursur that is entirely memory-resident and processed in a read-only fashion might never have a disk presense, and VFP might never actually open a file handle to access it. I'm also not sure that a view based on a table always represents a separate file handle on the table when the view can be manipulated entirely in memory.

It's a tough problem to crack, and it's somewhat misleading to take the docs literally without paying any attention to the operating system imposed file limits; while VFP might be able to handle thousands of handles in a process, the operating system itself isn't able to let VFP use its internal capabilities in all circumstances.