Too many files open - error

 

TOO MANY FILES OPEN
  1. Check your CONFIG.SYS for any FILES= command. Edit CONFIG.SYS so that FILES=99 or more. FILES=150 is often necessary if Windows is being used.
      
  2. Check CONFIG.DB for any FILES= command.
     
  3. Network environment?

    NOVELL What is FILE HANDLES = in SHELL.CFG or the NET.CFG? No .CFG file means default values. For example Netware version 2.2 allows 40 by default. Run NETGEN to increase file handles default.

    dBASE 5 for DOS now defaults to FILES = 250 in the CONFIG.DB opposed to dBASE IV FILES=99. This means that the config.sys may contain a line that says FILES=250. This allows us to open more files in more work areas than in previous versions.

    The problem is the NET allocates a number of these files as well. The total number of files in the Config.sys PLUS "Handles = ..." in the NET.CFG must NOT exceed 254. So if you change your "FILES = .." to FILES = 254 in the Config.sys, you will not be able to log into the net. However, this can be set to 200 and the "HANDLES = ..." line in the NET.CFG can be set to 54 as well. This gives a grand total of 254.

    PC-NFS PC-NFS by default only allows a handful of open files. However, the PCNFS.SYS driver has a /f parameter which allows you to increase the number of open files up to 127.

    LANTASTIC or another DOS/SHARE-based Peer-to-Peer network Is SHARE loaded? In some cases the defaults for SHARE need to be increased. See #4 below and GO ARTISOFT - SHARE.TXT.
     
  4. SHARE [/f:space] [/l:locks]

    *> The /F Parameter <* The /F parameter allocates the storage area (in bytes) used to keep track of filename, filepath and 11 bytes housekeeping information for EACH file opened. The default value for the /F option is 2048. Using an average length of a filename and path of 20 bytes (average is per DOS 5 Users Guide - SHARE), the default value is sufficient for 66 simultaneously open files:

    2048 / (20+11) = 66.06

    If your FILES= statement specifies more than 66 files, or your average path length is longer than 20 characters, you may want to adjust the /F parameter.

    On a network server that uses SHARE, you will need to allocate enough space for all the files that will be opened by all the users on the network.

    You can calculate the maximum needed space required by multiplying the number of files in your CONFIG.SYS by 31 (20 bytes avg. pathname + filename + 11 bytes). For a system with FILES=255 in CONFIG.SYS, with all 255 files opened, SHARE will require 7905 for /f:space.

    If the /F option is too low, you may receive a "File not Found" error.

    *> The /L Parameter <* The /L parameter specifies the maximum number of simultaneous locks that SHARE can handle. For DOS 5 and 6 the default is 20. If running Windows, or working on a Network you may quickly exceed the default.

    The /L setting should be at LEAST the number of files you've specified in your CONFIG.SYS. Each open file can grab a lock but could potentially have dozens. If you're running a multi-user program you have to keep in mind the maximum number of files you may have open as well as the maximum number of record locks that may be issued. Each time an application requests a record lock, a lock on that portion of the file is issued.

    Programs may behave in an unpredictable manner when SHARE runs out of locks. If the value used in the /L option is too low, you can expect to receive an error "Too many files open", "File Access Denied", "Sharing Violation", and in some cases a lock up.

    Example:

    SHARE /f:5200 /l:167
    * sufficient storage area (/f:) for 167 files and 167 locks (/l:).

    *> If you experience problems with SHARE <* - Try loading SHARE at the TOP of your AUTOEXEC.BAT before other devices. - If loading SHARE in the upper memory, load Share in conventional memory instead. Change:

    loadhigh c:\dos\share.exe /L:# /F:#

    to:

    c:\dos\share.exe /L:# /F:#

    According to MicroSoft you should not use the MS-DOS loadhigh command when you run a third-party upper memory manager such as Qemm. - Make sure there is not more than one Share line in AUTOEXEC.BAT or CONFIG.SYS and that it does not exist in both AUTOEXEC.BAT and CONFIG.SYS. - If you are low on available memory or perhaps have a memory conflict, and have SHARE /f: /l: set, try decreasing the values.
     
  5. WINDOWS

    Windows has a setting in the SYSTEM.INI file called PERVMFILES= This sets the number of file handles Windows allocates to each virtual machine. In the [386Enh] section of the SYSTEM.INI file, modify the line:

         PerVMFiles=

    The default is 10. It can be up to 255.
     
  6. OS/2 If your dBASE application returns the error message "Too many files open", make sure to check the DOS_FILES setting for your dBASE program object. The DOS_FILES setting establishes the maximum number of file handles that the DOS program is able to open. The default setting is 20. dBASE III PLUS can only open 15 files so you can leave the setting at its default of 20. On the other hand, dBASE IV can open up to 99 files, so it can be set to 99. Please note that each file handle allocated uses 39 bytes of conventional memory. So set the DOS_FILES according to the maximum number of files your dBASE application will open. Also make sure DOS_VERSION is set for the program object you are running dBASE IV from.
     
  7. QEMM Check files option
     
  8. Under the assumption that there may be something else causing a problem in the environment TEST with a minimum setup. Create a bootable floppy and add only the following:

    CONFIG.SYS      AUTOEXEC.BAT
    FILES=99        PATH=C:\DBASE
    BUFFERS=15      PROMPT $P$G


    ONLY add other lines REQUIRED to boot the computer ( disk partitioning, compression, etc.)
     
  9. To see if there is a problem within your code run the following program to see how many files you can open:
    *- PRG TO SEE HOW MANY FILES YOU CAN OPEN
    *- If you error out with "Too many files are open"
    *- choose SUSPEND and then DISPLAY STATUS.
    *- Check the line that says "Number of files Open"
    CLOSE ALL
    CLEAR ALL
    Z=1
    DO WHILE Z<100
      fname = "X_"+LTRIM(STR(Z))+".TXT"
      fhandle = FCREATE(fname)
      junk = FPUTS(fhandle,"x")
      Z=Z+1
    ENDDO
    DISPLAY STATUS


    dBASE uses some file handles internally. The above code should easily create greater than 80 files. * Remember to clean up the disk after this test. You will have files named x_1.txt, x_2.txt .... As long as you have no files name x_*.txt of your own delete these by issuing !DEL x_*.txt.
     
  10. If #9 above opens more than enough files, check your database and index files for any possible corruption. Download:

    Lib:6 - DBFCLN.EXE Title : Dbfclean utility
    Lib:6 - DBTCHK.EXE Title : Checks for corrupted memo fields

    Run these utilities against your DBF and DBT (if any). After checking these files for corruption. CLOSE ALL and delete and remake any NDX or MDX file associated with them. At this point we should have clean data files and indexes.
     
  11. Make sure your programs aren't calling themselves recursively. This can be the result of issuing a DO statement to go back to a previous procedure, instead of issuing RETURN. For example:

    * prg_AA.PRG
      DO prg_BB
      RETURN
     
    * prg_BB.PRG
      DO prg_CC
      RETURN
     
    * prg_CC.PRG
      DO prg_AA
      RETURN


    Program AA calls BB, BB calls CC, and CC calls back to AA..., each program will occupy a file handle. The programs keep getting pushed on top of stack waiting to be popped off. The stack will eventually be filled up, and the operating system will run out of file handles. You will then see one of these messages depending what the application does:

    "Too many files are open"
    "Insufficient memory"
    "Procedure nested too deep"
    "Internal: Virtual Stack Overflow"

    If a DO command is used in this manner, it is termed recursive programming. This involves a circle of programs or menus instead of a chain or hierarchy. In the above example, program AA calls program BB with the DO command. Program BB calls CC in a similar manner. Up to this point, there is a proper hierarchical chain of programs: AA-BB-CC. If program CC then calls AA with a DO command, a full circle would have been completed: AA-BB-CC-AA. This causes problems in dBASE as each opening of a module in this way uses a file handle. Only the file handle for the latest opened instance of a given module name can be released, other instances become irretrievably lost and the limited number of available file handled is quickly expended.

    In this chain of programs, AA-BB-CC, module CC would ordinarily have a RETURN command at the point where its processing is considered complete. This automatically returns control to BB, at the first command line after the command line DO CC. Similarly, when a RETURN command in BB is encountered, control returns to AA.

    * prg_AA.PRG
      DO prg_BB
      RETURN
     
    * prg_BB.PRG
      DO prg_CC
      RETURN
     
    * prg_CC.PRG
    * ... code ...
      RETURN

    There is one exception to this, and that is the need to go directly from CC back to AA, but closing all intermediate open modules in the process. This can be accomplished with the RETURN TO MASTER command (in CC). This would have the same apparent effect as DO AA (invoked in CC), but does go back through each open intermediate module in the hierarchy, closing each, until the topmost level is reached.

    * prg_AA.PRG
      DO prg_BB
      RETURN
     
    * prg_BB.PRG
      DO prg_CC
      RETURN
     
    * prg_CC.PRG
    * ... code ...
      RETURN TO MASTER

    A good way to spot recursive calling is to use a program code documentor such as SNAP.

    LIB 14: SNP502.ZIP
    Title : Snap! Version 5.02 - Program Documentor for xBase

    Within dBASE you can do something along the following to see if you can spot recursive calls:
    SET TALK ON
    SET ECHO ON
    SET ALTERNATE TO list.txt
    SET ALTERNATE ON
    DO program
    * Cancel from too many files open error
    SET ALTERNATE OFF
    SET ALTERNATE TO
    CLOSE ALL
    MODIFY COMMAND list.txt

     
  12. Long shot but possible: Delete and re-install the dBASE software for any possible corruption.

[Home] [FAQ Index]