Internal Error Code - Irrecoverable Error

 

This document gives trouble shooting techniques for dealing with all Internal Error Codes, this includes numbers 1000, 1024, 2025, 224, 35, etc.

ERROR 1000:

What exact version of dBASE are you using?

?VERSION(1) 

If the Internal Error is Error 1000 and you are using dBASE IV v2.0 x54 you can contact customer service (GO BORCS or 408-461-9000) and request the latest build x17. It (and x16) address many error 1000 problems caused by certain coding routines within dBASE. It will NOT fix problems if the problem is due to corruption or memory conflict.

ERROR 35:

Irrecoverable Error - "Protection violation". See Lib 10: QERR35.FAQ first, if problem persist then continue with the following.


TROUBLE SHOOTING ALL INTERNAL ERROR CODES:


Internal Errors usually stem from; lack of memory or memory conflicts, file corruption, an incapability on the system or a very particular set of commands.

-> To begin trouble shooting Internal Errors make sure there are no disk errors, corruption or memory conflicts.

Run CHKDSK or SCANDISK to make sure there are no disk errors. Download the following utilities and run them against your DBF/DBT.

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

* DELETED the MDX file and rebuild index. 
USE <filename> 
LIST STATUS TO PRINT && print out the tag names,  
&& and index expressions to help you rebuild MDX. 
CLOSE ALL 
DELETE FILE <filename>.MDX 
USE <filename> 
   && Proceed past error message, remake indexes. 

At this point we should have a clean disk, database and index.

If the problem persists boot clean to rule out any configuration problems.

*- CONFIG.SYS *- AUTOEXEC.BAT
FILES=99 PATH=c:\dbase
BUFFERS=15 PROMPT $P$G

*** and only other _essential_ files such as disk drivers and compression utilities. If on a network, first test locally with no network connection.

Window clean boot:

*- CONFIG.SYS *- AUTOEXEC.BAT
FILES=99 PATH=c:\windows;c:\dbase
BUFFERS=15 PROMPT $P$G
DEVICE=c:\<path>\himem.sys SET TEMP=C:\WINDOWS\TEMP

* Verify that you have a valid SET TEMP statement to an existing directory.

For more info on a clean boot See TI1480.ZIP in Library 10 or call the TechFax number 800-822-4269 and request document #1480

TI 1480 - How to Make a Plain DOS Boot Floppy Disk.

This will provide a quick yes/no as to whether configuration is in any way involved. If the problem still persist, it has nothing to do with a configuration conflict.

-> Run PMINFO.EXE or PMINFO32.EXE ( dBASE 5 for DOS ) and make sure that dBASE is correctly reading your extended memory.

DOS memory Extended memory
640 xxxx K bytes physically present (SETUP).
xxx xxxx K bytes available for DOS/16M programs.

xxxx 'K bytes available for DOS/16M programs' is what dBASE will use.

-> Check for a DBASE.ERR file.

An example DBASE.ERR file:

OPEN FILES: 
C:dbase1.res mode=33, bhot=0 
C:\DB54\DBASE420.ACC mode=6, bhot=0 
D:\TMP43052.$DB mode=8259, bhot=0 
>>> C:\DB54\DATA\XSTEVE.DBO mode=17, bhot=0 
-----
dBASE call traceback 
@ 5,5 SAY aaa PICTURE "@xxx" 
** At line6 in file xsteve.prg, procedure XSTEVE 

Use the .ERR file to help isolate the code triggering the error. In most cases the .ERR file will list the name of the program file dBASE was reading when the error occurred. The .ERR file is cumulative. Check to see if the error always occurs in the same procedure.

Try deleting the .DBO file and making any small change to the PRG which caused the error. This will cause the PRG to be rewritten and a recompile of the DBO.

If traceback doesn't show the line triggering the error. Put flag = .T. in the beginning of this procedure. Then run the debugger with FLAG in the breakpoint, step thru the procedure, what line triggers the error?

For more on DEBUG see:
TI1127.ZIP - How to Debug Programs Using the dBASE IV Debugger.

-> If the problem happens on a SET FILTER TO with a large database in dBASE 5 for DOS:

PROBLEM:

USE <filename> && Large database (200K records) 
SET FILTER TO fieldname = any_condition 
* results in Internal Error Code. 

WORKAROUND:

* Turn off dBASE speed filter by adding 
* logical to end of expression 
SET FILTER TO fieldname = any_condition .AND. .T. 

If speed is an issue, consider using an index and SET KEY TO instead of SET FILTER.

-> If this problem is happening in a REPORT, LABEL, QUERY, or SCREEN, that object file may be corrupt or from a different version of dBASE. By deleting object files dBASE will recompile. (!BACKUP FIRST!)

SCREEN: .FMO
LABEL: .LBO
REPORT: .FRO
QUERY: .QBO

After deleting the corresponding object file, go into the design surface and make some small change and re-execute to force dBASE to generate new code. Corruption if in the design file (.SCR for example) may need to be fixed by remaking the file (REPORT, QUERY, Etc.) from scratch, or going to a clean backup.

-> If the problem occurs when trying to save a large report, then your report may be too large or complex for the report generator. If this is the case your options are to decrease the size or simplify the report, split the report in to two, or write code to execute a report.

-> Using illegal names can cause Internal error messages. Follow proper naming conventions for field, file and memory variables: Names begins with a letter, and can contains letters, numbers and the underscore character "_".

Do not use dBASE reserve words. These are dBASE command words or the first 4 letters of a dBASE command as a name. Example: TOTAL, TOTA; SELECT, SELEC, SELE. Don't use the letters A-J, these are reserved for ALIAS names.

Queries are particularly susceptible to blowing up with internal errors when field/file/memory variable names don't follow dBASE naming conventions. For example starting a field name with a number will often cause the query to fail on this field.

-> Is the dBase variable DBTRAP set on? Setting DBTRAP off takes away the safety net provided by dBASE. Without it the programmer is responsible for any unconventional or dangerous programming. If that's the case, issue the command SET DBTRAP ON within the program. In many cases, if you run your program again, dBASE will display an error message when it encounters the code that's causing the problem.

-> Avoid 'Dangerous' programming techniques. These are general scenarios which could cause a Protection Violation.

Interrupting global commands
----------------------------------
There's a set of dBASE commands that act globally. Certain dBASE commands (such as BROWSE, SORT, and COPY) act globally on an entire table. If you change the conditions controlling one of these commands while the command is processing, you can confuse dBASE. (For example, you SET FIELDS to a field list, then in a UDF or ON KEY interruption you change or clear the fields list by issuing SET FIELDS TO.) These commands are:

- SET FILTER
- SET RELATION
- SET FIELDS
- ON KEY

Avoid redefining the conditions of any of these commands in UDFs that you use with the commands.

For example, the following code calls a UDF that redefines SET FIELDS conditions (DO NOT USE THIS CODE IN YOUR PROGRAMS):

USE Test1 
ON KEY LABEL A ? Resetfld() 
SET FIELDS TO Age, x = PI() 
KEYBOARD "A" 
BROWSE FIELDS Age, x 
FUNCTION Resetfld() 
SET FIELDS TO 
RETURN .T. 

Calling commands recursively
----------------------------------
You should generally avoid calling commands recursively. If you have DBTRAP set on, dBASE will prevent you from making recursive calls to some commands with the error message, "Command cannot be called recursively". However, commands that rewind the database, such as JOIN, LIST, and SCAN, might not get trapped by DBTRAP and are likely to cause an error code 1000 termination if you call them recursively.

A common way to inadvertently make a recursive call is to put a call to a command in a UDF, then call the UDF when you use the command. For example (DO NOT USE THIS CODE IN YOUR PROGRAMS):

*Srt.prg 
USE Test 
SORT TO Test88 ON Name FOR Udf1() 
RETURN 
FUNCTION Udf1() 
SORT TO Test99 ON Name 
RETURN .T. 

-> Further trouble shooting:

Try rearranging the statement or expression that caused the error. Try a reinstall. Did anything change? New install? New machine? Other software? Does the problem occur at different machines or only this one?

If the problem is isolated to a single machine Then your may be looking at a BIOS or hardware problem. Use DBINFO.EXE to return the BIOS information:

DBINFO -x 

Some older BIOSs have proven less than efficient or outright incompatible. A BIOS earlier than, say 1990, maybe suspect.

If using dBASE IV v2.0 try setting the following environmental variable:
SET DOS16M=: * limits the amount of available memory that dBASE grabs at startup.

SET DOS16M=:5M 
SET DOS16M=:5120K 

limits it to 5 megs. (4.8megs is where max performance starts to kick in, as no swap file is necessary at this point.) Either set this to EQUAL TO or LESS than the Extended Memory available for DOS16/M programs returned by PMINFO. If no other program will be accessing this memory concurrently with dBASE, set it EQUAL TO for best performance. By doing this no other programs will be accessing this portion of memory concurrently with dBASE. Do NOT use this variable with dBASE 5 for DOS or it's EXEcutables.

If using dBASE IV v2.0 or dBASE 5 for DOS set the following environmental variable.

SET DBASEIV_BUFF=9,,,16 

The buffsize defaults to 8, however you may find that a different value produces more efficient buffering on your system. While the ideal setting for your system can only be determined by trial and error, we have found that on systems with around 2-3Mb of total memory, using the "SET DBASEIV_BUFF=9" (or 7) seems to have a positive effect of disk I/O.

-> ERRCODE.TXT

Library 6: ERRCOD.ZIP
Title : ERRCODE.TXT file
ERRCODE.TXT file referred to on pg 709 of V2.0 Lang. Ref. This file lists and describes briefly all the internal error codes that dBASE detects and reports.

This file is of limited help in most circumstances. For the most part it lists possible error numbers and their associated messages. Not steps to debug the problem. The entire contents of ERRCODE.TXT is copied below for your convince:

----- Irrecoverable Errors -----

Currently, this file contains both TEST build and PRODUCTION build error codes.

105 mal16mt ERRmem105 pointer table full
106 mal16mt ERRmem106 attempt to realloc seg not allocated here
107 mal16mt ERRmem107 attempt to free seg not allocated here
221 mal16mp ERR221 internal logic error: block not full and all bits set
222 mal16mp ERR222 pointer provided to free is invalid
223 mal16mp ERR223 failure to find pacc pointing to block being freed
224 mal16mp ERR224 duplicate free attempt
301 mal16mp ERR301 alloc, amap count mismatch in mx_check
331 malext ERR331 grow registration table too small
700 bufferck ERR700 active BUFFER count invalid ( forward trace )
701 bufferck ERR701 active BUFFER count invalid ( backward trace )
702 bufferck ERR702 cannot locate FCB
703 bufferck ERR703 hot buffer is in free chain
704 bufferck ERR704 file queue flink, blink inconsistent
705 bufferck ERR705 freelist BUFFER count invalid ( forward trace )
706 bufferck ERR706 freelist BUFFER count invalid ( backward trace )
707 bufferck ERR707 used buffer count inconsistency
720 buffer ERR720 buffer initialization logic failed
801 critinit ERR801 INIT_MSG_SIZE is too small
802 critinit ERR802 MAX_MSG_CNT is too small
951 execute ERR951 unexpected failure of run command
1000 abfault ERR1000 termination due to PV
1001 abfault ERR1001 cannot allocate fault stack
1002 abfault ERR1002 cannot install fault handler
1021 memofunc ERR1021 invalid memo line length detected



[Home] [FAQ Index]