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.
* 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.
*** 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:
* 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.
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: -> 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!)
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
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, xFUNCTION Resetfld() SET FIELDS TO RETURN .T. Calling commands 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() RETURNFUNCTION 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=: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 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.
|