Internal Errors

This document was printed from the Norton Guide: `Clipper 5.00a -
Internal Errors  V1.04' by  Terry McConnell. Though dated, I have found
it to be extremely useful. The Clipper 5.3 NG on runtime errors may contain
updates on these internal errors.

By the way, I have not been able to reach Terry McConnell to enquire on the
latest version of his document. Please e-mail me If you have
his latest e-mail address.

 Internal Errors
   Internal Error #0 through #100

These messages are the same for Summer '87 and Clipper 5.0.  Check out
IERROR.TXT in LIB 0 for complete, official explanations from Nantucket.

Internal Error #332

(#109665) User reported bug to Nantucket that when you fill array
with a value and then change this value to NIL or "" (presumably,
a value which, internally, takes less space), and refill this array
the run can fail with an internal error 332 depending on the length
of the new values.

  Internal Error #333, ARRAY(0) & STATICS$(0)

(#99608) Appears during creation of multi-dim array structures or use
of macros?  Very Mysterious & Elusive.  Sometimes disappears on it's
own.  Try shuffling the code around.

(#100777) Error may be generated when the system cannot find enough
contiguous memory for a big array or large variable.  Declaring: STATIC
aJunk[1,2,3,4,5,6,7,8,9,10] can bomb.  Seems to have something to do
with STATIC declarations.

(#112790) This error occurs in DBU when it attempts to read long
directories into memory via the DIRECTORY() function.  Again, this is
the same problem.

(#118666) If you are being plagued by Internal Error 333, you may want    ~
to try this fix from Jo French [74730,1751].

Instead of using methods to declare your array assigning an initial size,
like: LOCAL aBig[4000,8], try this:

LOCAL aBig := {}

FOR nX := 1 TO 4000
AADD(aBig, {}); ASIZE(aBig[nX],8)
NEXT nX


See Also: "Internal Error #442"

Internal Error #415 

(#101160) Error opening dynamic file.  Occurs when you compile a file
and link with first object module name longer than 8 characters.

This is a problem with RTLINK.EXE, not with CLIPPER.EXE.  The problem
involves specifying an object filename longer than 8 characters.  The
extra characters are ignored during file access, so the link works, but
the EXE has the extra characters in its reference to itself for VMM and
dynamic code swapping.  When you run the application, and it attempts to
load another part of itself, it can't because the internal file name is
invalid.

Solution: Don't use longer than 8 characters for filename.

() When running on a PC-AT 3270 microcomputer with PC DOS v3.30 & v3.20   ~
loaded, and the IBM 3270 PC Control Program Level 3.00 loaded, Clipper
bombed with this error message.  Once the IBM 3270 PC Control Program
was removed from memory, this error message disappeared.


 Internal Error #416

(#96017) Unable to access .exe for next dynamic page of code.

() This description seems very consistent with every description of
this error I've seen.  For some reason, your .EXE is no longer available
to read data from itself.  During the time that a Clipper application
runs, it swaps information from the EXE file to memory.  If the EXE is no
longer available to read, then the program will bomb with this error.

(#115578) A user gets the message frequently on a Novell Network.  One    ~
suggestion from Nantucket Tech Support asked if the same .EXE existed in
another directory in the search path.  This may cause this error.

(#115909) Kurt Schaldenbrand [72137,2703] suggests that this error is     ~
related in some way to expanded memory: "When a customer adds expanded
memory, occurrences of both 416 and 5320 go away."

See Also: "Internal Error #5320"


 Internal Error #442, STATICS$(0)

() This error can be produced by writing a program that declares a huge
STATIC array much like the example shown in the Internal Error #333
listing.  It can also be produced using a LOCAL declaration.  In this
case, "STATICS$ (0)" is replaced by function name and line number.

See Also: "Internal Error #333"


 Internal Error #521

(#96396) Occurred during the macro expansion of an array in a
REPLACE...WITH...NEXT command.  It was unclear from the example provided
if the error was caused when a 'M->' preceded the array element, or when
it did not.  There are indications that the message is sporadic and hard
to duplicate.

(#119988) IE #521 occurred in a replace to a memo field. (Note that this  ~
thread refers to the error as #512, but in the end it was #521 that the
user was getting)  The error disappeared the next day, no resolution or
workaround was offered.


 Internal Error #612

(#94798), (#94656), Cause: Submitting to EVAL() a first parameter whose
type is not codeblock.  Most common cause is linking in old ERRORSYS.OBJ
files from Summer '87 applications - even if recompiled with 5.0.

(#101142) Occurred on second access to a database w/ Lastrec() then
Recno() - Perhaps memory problem?  -- not consistent with other examples
of this error.

() In a custom ERRORSYS procedure: Not setting ERRORBLOCK() or committing
an error prior to setting ERRORBLOCK() will force this error.


 Internal Error #650

(#95972) Problem occurred during block evaluation from within a custom
error handler?  A message preceding the error indicated that the
program had run out of stack space: "Processor Stack Overflow."

() I got this error to occur by specifying an undefined ERRORBLOCK().
In other words, the function call in the codeblock that I passed to
ERRORBLOCK() had a symbol reference in it that was not linked to the
program.  .RTLink generated an "unresolved externals" message and
indicated that "EXE may not execute properly."  I suspect, however,
that this error has nothing at all to do with ERRORBLOCK()s in
general, but, instead, has something to do with the evaluation of
a NIL or undefined codeblock.

(#111301) This thread seemed to indicate that 650's real nature has
something to do with a stack overflow.  Increasing stack space may
help to remedy the situation.  Checking your code for recursion may
help as well (especially if you hadn't intended that there be any
recursion).

(#113260) This error occurred for one user in a 500 line test program with
some ASM modules linked in (though they did not appear to be the problem).
After this user changed a few static variable names, 650 began appearing
in _APPINIT(0) (a Clipper internal).

(#117157) One user got this error when he named a program ACHOICE.PRG     ~
and compiled it to ACHOICE.EXE.  There can only be one symbol name
for a procedure or a function.  If you have an ACHOICE.prg and you are
not compiling with the /n switch, any calls to ACHOICE() will cause the
assumed procedure ACHOICE to be executed. This results in recursion and
an eventual 650 stack overflow.  Remember, functions and procedures
are essentially the same.


 Internal Error #666 

(#98491) An invalid string was passed to SETCOLOR().

() I was unable to reproduce this bug with some pretty wild SETCOLOR()
strings.  Some folks believe that it is not really a SETCOLOR() problem
and that, instead, it is a memory problem in SETCOLOR().  According to
other testers, macroed variables are more likely to produce the error of
the beast.  Who really knows the true nature of Hell (... better than
Basil Hosmer and Dante') ?  :)

(Mail) Pat Cassidy [76605,2365] provided me with these two wonderful hair
raising bits of code.  They both faithfully produce the 666 error on my
machine and his.  (pun intended)

************************************************************
*  Program 1
************************************************************
line := 0
set color to ("$$$$$$$$$$$")  ; ? ++line //1
x := setcolor()               ; ? ++line //2
? "Setcolor returns ", x      ; ? ++line //3
set color to &x               ; ? ++line //4
z := "@@@@@@@@@@@@@"          ; ? ++line //5
set color to &z               ; ? ++line //6
set color to "z+/z/t/m/q"     ; ? ++line //7
? setcolor()                  ; ? ++line //8 - last line executed ok
m = "z+/z/t+/m/q"             ; ? ++line //9  - setcolor(0) error here??
setcolor(m)                   ; ? ++line //10
set color to &m               ; ? ++line //11
? setcolor()                  ; ? ++line //12
set color to "w/n,w/n,w/n,w/n,w/n,w/n"
setcolor("W/n,w/n,w,n,w/n/w/n,w/n,w/n")


************************************************************
*  Program 2
************************************************************
line := 0
set color to ("w/n,w/n")  ; ? ++line // print "1"
x := setcolor()           ; ? ++line // print "2"


? "Setcolor returns ", x  ; ? ++line // and "3"
set color to &x           ; ? ++line //4
z := "w/n,w/n"            ; ? ++line //5
set color to &z           ; ? ++line //6
set color to "w/n"        ; ? ++line //7
? setcolor()              ; ? ++line //8
m = "w/n,w/n"             ; ? ++line //9
setcolor(m)               ; ? ++line //10
set color to &m           ; ? ++line //11 - ok so far(prints 11)
? setcolor()              ; ? ++line //12 - never gets here
set color to "w/n,w/n,w/n,w/n,w/n,w/n"
setcolor("W/n,w/n,w,n,w/n/w/n,w/n,w/n")


 Internal Error #773,

(#112934) User indicated that the error would occur with a bunch of junk
on the screen -- which indicated to him that it may be some sort of "memory
trashed" error.  The only reports of this error are very sketchy.  This same
user later indicated that the program involves a large chunk of Microsoft
C 5.1 code called from Clipper 5.0.

(#112958) One user said that after getting an internal error 416, and
executing the program with //info, he got 773.

(#116899) BJ Walsh [71121,3013] found that this error was caused by his   ~
attempts to free pointers from C that didn't belong to his program.

See Also: "Internal Error #416"


 Internal Error #777, (b)OPENDB (0)

(#94779) This appeared to occur concurrently with memory problems, and
after a RUN command.


 Internal Error #993

(#96477) An example of this error occurred during an attempt to
macro compile a local in a block expression (INDEX..ON).  First the
"Error BASE/1065 Argument error: &" occurred.  Then three copies of
this error message (#993) were output.  The message "Aborted during
termination" also accompanied this error message before the application
came to a screeching halt in the land of the C prompt.

() My experiences with this message occur in a custom error handler.
After receiving an error message during a stabilize of a tbrowse, the
internal error 993 is generated as I display an array containing
callstack information.  I'm not sure what the correlation might be --
except for the fact that both occurred within an error handler.


(#110724) The following function was reported to crash with an internal
error 993 (Don Kiely 72657,475):

FUNCTION OpenFiles()
FIELD Number IN JOBS

USE COMPANY INDEX COMPANYN,COMPANYC NEW
USE JOBINFO INDEX JOBINFON NEW
USE JOBS    INDEX JOBSN,JOBSC NEW
SET RELATION TO Number INTO JOBINFO ADDITIVE
USE PEOPLE  INDEX PEOPLEN,PEOPLEC NEW          // Dies here.
RETURN NIL

Don said that when the error occurs, the call stack looks something like
this (without using any special error handler):

OPENFILES
__DBSETIND
(b)ERRORSYS
(b)ERRORSYS

I was unable to re-create this occurrence by using similar databases.

(#122336) Laurence Wieland [71141,1411] suggests that this error is       ~
generated purely on the basis of recursion: generating an error within
an error handler, for instance.  I wonder if there could be some problem
with the callstack that causes the tail to point to the head, causing the
callstack problem I outlined above ... (?)

(#115799) Carl Byington [74040,1156] provided this information:           ~

"Internal error 993 may be generated by the error handler trying to do a
nested read (for an error that was caused by a valid or when clause) without
the extra assignment statement that is required for any nested read to work
correctly."


 Internal Error #999

(#110250) It has to do with calling a function via a macro that was
not linked in.  Look for a function that you are calling via a macro
like:

nVar   := "UDF()"
RetVal := &nVar

... However, I was unable to reproduce this error using this example.

(Mail) Forest Belt [70054,3664] received IE #999 when linking a Summer    ~
'87 UDF into a home built .LIB file with a group of .ASM and 5.0 UDFs.

I was able to verify this by writing a program that called a S87 compiled
function.  Rtlink will warn you that you are attempting to link a S87
module with a 5.0 one, and will show "_VSTD" and "SUMMER87" as undefined
symbols.  Apparently, Clipper is attempting to call one of these functions
when it dies with the IE #999.


 Internal Error #1104, __DBARRANG(0)

(#102789) Occurred during a SORT..TO on an 8086 machine & expanded
memory.  Other reported cases show it occurring on a COPY command and
not in __DBARRANG().


 Internal Error #1110, __DBCREATI(0)

(#111278) This error was encountered during creation of an index file in
a maintenance program.  Appending to this same file caused an internal
error 416.  The user reported that this problem went away when he copied
his program to another directory; same hard drive, free space, files, and
RAM.

(#115248) Internal error 1110 may mean "zero length index key."  Check    ~
your index key for TRIM() functions or other functions that may evaluate
to a variable or zero length index key for different records.  The Clipper
reference manual has a discussion on how to workaround zero-length index
keys on page 4-56.

See Also: "Internal Error #416"


 Internal Error #1210, __DBPACK(0), __DBSKIP(0)

Record not found in index.  It should only occur if the database
is updated without the index being open.  Recreating the index and
re-running may clear it up.

(See Also Richard Thompson's BADPAC.ZIP or Fernando Villar's
IE1210.COM in the Nanforum libraries for examples)

(#95089) This scenario says to make a small database, and then make
2 indexes, one indexed on a large field and the other a small field).
Make sure the order in the SET INDEX command is large key then
small key.  Performing consecutive GO BOTTOM; DELETE; PACK will crash
to internal error #1210.

I was unable to reproduce this error by using this method.  My key
was 30 characters for the large index, 1 for the small, and I had 300
records in my test database.

(#110430)  This indicates that 1210 can occur when two machines update
the same record at approximately the same time using an rlock(), commit,
unlock sequence.

(#112069)  The following code fragment goes through an entire table
replacing the FILTER field.  There are three indexes open when the order
is set to 0 before the loop.  Part of the way through the table the error
INTERNAL ERROR 1210 __DBSKIP(0) occurs.

set order to 0
go top
do while !eof()
@ 0,0 say "Company"+profit->comp_code
lockrec()
profit->filter := if(profit->contract Internal Error #1242

(#96613) When using a SET RELATION and using an alias field in an
INDEX statement the INDEX does not work correctly.  If the program is
executed by itself (not under debugger) it creates a variable not found
error.  If the program is executed under the debugger it creates an
Internal Error 1242.

At the suggestion of a Nantucket support person, the programmer added
a FIELD statement - this eliminated the error message when executed by
itself, but the program did not work properly - it just ended either
after or during the INDEX.  When executed under the debugger it created
an Internal Error 1242.

According to Nantucket support personnel, "indexing on a field in another
work area does not always work properly," and could cause this error.

(#109860) Information presented by another user indicates that this error
may not be in indexing, but in the debugger -- or in the debug code placed
in the object by Clipper.

() After testing code provided by Peter Bilka [73417,1316]:

// test.prg
use child
index on cname to childn

select 1
use child
set index to childn

select 2
use parent
set relation to cname into child

go top
list parent->pname,child->cname

cancel

I was able to recreate the 1242 error only while in the debugger.  One
workaround may be to remove debugger code from modules that use set
relation (don't use Clipper's /b), or to not use set relation.


 Internal Error #1256, __DBSETIND(0)

(#112199) There were indications that:

USE GLOBAL
i1 = "globuser"
SET INDEX TO &i1

causes this error, when both database and index exist.  I was unable to
confirm this.

(Mail: Del Texley [71117,3551])  Del found that this error may be related
in some way to the size of the database.  He says that the workaround is
to test the number of records before opening the index file, and recreate
it if less than 5 records exist.

SELECT( SEL_POST )
USE PRPOST INDEX PRPOST   // Crash here with internal error # 1256 if
// prpost is empty!

** This Fixes if substituted for above line
USE PRPOST

IF RECCOUNT() <>Emp_num + DTOS( PRPOST->Pdate )  TO PRPOST
ELSE
SET INDEX TO PRPOST
ENDIF
** Weird enough for you?

(#112378) This message reports that 1256 occurs during a SET INDEX.  The
user says that he was using an index expression that contained a UDF for
displaying percent done during the index.  Clipper 5.0 stores index exp-
ressions as it receives them: "INDEX ON A     + B" will keep the strange
spacing.  His problem was that he had a function that was messing with
the NTX header, and not taking this  into account.


 Internal Error #2155, _DBSETIND (0)

(#104860) Index file corruption.  You can get this error if you open
an NDX file.

Also, the file may be open in another area.  If one work area creates
an index then another work area tries to open that newly created index,
you can get this error.


 Internal Error #3511

(#107383) Occurred during VM Swap file access on a Novell Network.
Returned DOS error 4 - perhaps related to handle problems?  Not enough
handles for swapfile?


 Internal Error #5302, VMSWAP

(#95585) VMM Problem.  Not enough base memory to run program.  Free
up some base memory by unloading unnecessary TSRs, etc ... remember
that BASE memory is the memory below 640K, and a Clipper application
needs as much of it as you can dole out.

If the computer you are running on is has an 80386sx or better, consider
purchasing a high RAM memory manager such as Quarterdeck's QEMM or 386 to
the Max.

If you are already running such a utility, and are still bonking your
cranium against DOS's paltry 640K limit, you may want to try disabling
your VGA/EGA adaptor's graphics capability to create excess contiguous
free DOS space (sometimes up to as much as 800K!).  QEMM's command to
do this is VIDRAM [OFF|ON].  Some systems do not allow for this option,
so check your 386 memory manager's documentation for details.


 Internal Error #5305

VMM Problem.

(Mail: John Farrar [100015,502]) John says he encountered 5305 while      ~
executing this code:

LOCAL aDept := {}
DBEval({|| AADD(aDept, DEPT->(FieldGet(1)))})

... on a database of 1 field and 26 records.  I was unable to verify that
this occurs consistently.

See Also: "Internal Error #5302"


 Internal Error #5317, __DBCREATI (0)

(#95574) Not enough base memory during index create.

See Also: "Internal Error #5302"


 Internal Error #5318, __RUN (0)

(#96064) VMM Problem.  RUN command.
(#108539) Memory problem.  Running on PCMOS system.

(#113750) If you are getting this error using RUN on PC-MOS, check out
PCMOS.ZIP in LIB 4.  It contains several assembly functions that work
with Clipper and PC-MOS -- and apparently allow you to circumvent the RUN
command all together.  Check with the author: Don Caton [71067,1350].


See Also: "Internal Error #5302"


 Internal Error #5320, __DBCREATI (0)

(#94001) Index Problem.

(#96249) Sometimes solved by reducing index key size.

(#95342) Possibly a conflict with CACHE, VDISK, or SMARTDRV.

(#95701) More of the same - May not be CACHE - perhaps combination of
key length and available memory.

(#95087) Indexing may have problems with macros.  Try surrounding your
key expression with parenthesis.

(#101629) Suggests that perhaps not pre-linking with BASE50 will help.

(#108574) One user appended a CHR(0) to the end of his key string at
Nantucket's suggestion, and this error went away for good.

(#112220) Reports that this error occurred also during a SORT -D in
__DBARRANG(0).  No resolution was offered.  Try the sort in a stand alone
program - the problem may be related to the size of the DBF and available
memory.

(#112803) This error seems to occur when clipper thinks you have expanded
memory, but you do not.  Installing expanded memory has been known to
solve it.  No guaranties, but it could be worth a try.  It also seems
Smartdrv.sys is usually installed at the time.

(#112960) In essence, the 5320 means the VMM has tried to map an EMS
page when no EMS is available or that the EMS manager has returned an
error code.

() Most of the 5320 reported errors have been on INDEXing or SORTing
operations.  (PACKs with NTXs open, REPLACING a key field, etc...)  Since
5320 is in the VMM error range (53xx), this would indicate that 5320 has
something to do with indexes related to VMM.  VMM is used for buffers,
variables, and clipper code.  It should be noted that 53xx does not
necessarily mean that there is a low memory problem - any VMM problem will
do.

(Mail: 71660,1440) While installing a Clipper 5.0 program on a Novell     ~
Network, this user solved continuous 5320 errors by switching from DOS 3.3
to 4.x.  I personally believe that the switch in DOS versions was not the
deciding factor, and that perhaps a change in EMS Driver or General RAM
configuration during the OS switch caused the errors to disappear.

(#117235) Ray Crisp [73667,1450] solved his 5320 woes by changing the     ~
following code:

SELECT 1
USE ARTRANS
INDEX ON VndNo+FileNo+STR(TransNo) TO ARTRANSA
INDEX ON FileNo+STR(TransNo) TO ARTRANSF
CLOSE DATABASES                        // Ray Added this, and ...
SELECT 1                               // this, and his problems disappeared
USE ARFILE
INDEX ON FileNo TO ARFILE
// etc ...

(#115909) Kurt Schaldenbrand [72137,2703] suggests that this error is     ~
related in some way to expanded memory: "When a customer adds expanded
memory, occurrences of both 416 and 5320 go away."

See Also: "Internal Error #416"


 Internal Error #5321, __DBREINDE (0)

(Mail: Greg Dahl [72050,650]) This error occurred when VMM had run out of
disk space during a reindex.


 Internal Error #5333

(#98457) Macro expanded to a local variable.  Means that VMM has died
with a reference to an invalid or NULL memory pointer.

(#114101) One user says that perhaps changing PRIVATE or PUBLIC variables
to LOCAL or STATIC may affect this error.

(#114263) This suggests that perhaps getting a macro variable: GET &mtest
where mtest is a public, may cause the problem.  I was unable to duplicate
this.

() I was able to get an internal error #5333 by declaring a local array
larger than 4096 (we'll say 'x'), then accessing an array element beyond
x % 4096.  For instance:

LOCAL aList[5000]
aList[769] := "Hello World"

(Mail: Greg Dahl [72050,650]) While using Roger Donnay's MEM50, Greg got  ~
IE 5333 REFRESHCUR(0) after making a data change using DBEDIT().  Some
symbol is apparently not available for DBEDIT() that should be.  Not using
MEM50 eliminated the problem.

(#116024) In this thread, a user was battling with a #5333 error that     ~
kept popping up during a READ.  He solved the problem by doing a CLEAR
GETS immediately before the first @ GET was issued.


 Accuracy ...
  How Accurate is the info in this guide? 

Where I was unable to determine the nature of a specifc error, you'll
see that I've left hints and notes from other people who have recevied
the error.  These people are the wonderous Clipper community -- they
hang out on Nanforum on CIS, and are really neat folks.  Most of the
time, they know what they are talking about.  Items that are displayed
in this color in error descriptions are quotes or paraphrases from
Nantucket personnel.

  Those funny numbers ...

The numbers in parenthesis are message and thread numbers from Nanforum
where the explanation of the error was extracted.  In some cases, due to
lack of source code or other factors I've made no attempt to verify the
error as reported.  However, those errors marked with empty parenthesis
have been verified by me.  When possible, code or methods that will
faithfully reproduce the errors where reported.  If there is no such
listing of code, then, once again, the errors have not been verified.

  Verification Equipment & stuff ...

Where I was able to verify errors, the following configuration was used:

Clipper 5.0 Revision 1.03, 592K free base memory (using EATMEM.COM to
reduce available base memory if necessary), Compaq 80386s, 4.5 Meg memory
managed by QEMM, DOS V4.01 w/Novell netware IPX, and NET4XMS loaded high.

 Credits ...
  Clipper 5.0  Internal Errors, V1.03 (9104.01)  - Terry McConnell

This error list is not a publication of Nantucket corporation.  This
list was compiled based on the messages posted on Compu-Serve's Nanforum
between November 1, 1990 and the date that appears on this file.

  Updates ...

I will be making frequent updates to this guide and I will make these
updates available on the DBADVISOR forum, and the NANFORUM on CIS until
Nantucket(r) produces a fix disk or provides developers with an accurate
internal error listing.  Feel free to distribute these freely.

Comments, suggestions, addendums, changes, and corrections to this
thing can be mailed to me, Terry McConnell 71570,3571 on Compu-Serve.

All changes to this guide from its previous version are marked with a
squiggly thing (tilde'). (~)

Thanks ...

Special thanks to all those who have helped me to compile this list, and
thanks to Jo W. French for the inspiration, and the anomaly reports.  The
only way that this list could have been compiled was with the replies &
help that Nanforum developers have given to other developers.  Thank you
to every person who has ever taken the time to help another developer,
and to those who have made it a habit.