
  Clipper 5.0  Internal Errors, V1.03  (9102.02)
  Compiled by 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 produces a fix disk or provides developers with an accurate 
  internal error listing.  Feel free to distribute these freely.

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

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

  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.
  

  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 quotes (") in this file's description section
  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.


                       The Unofficial Internal Error List

Internal Error #0 - 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
  whith 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
  (#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.

  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.


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.


Internal Error #442
  () 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.


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 occured 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).


Infernal 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') ?  :)

  () 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 chunck 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.

Internal Error #777
  (#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 occured 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 recreate this occurance by using similar databases.  More
  information is forthcoming.


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.


Internal Error #1104
  (#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.


Internal Error #1210
  () "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<nAmount,.t.,.f.) // Field Assign
		// Suggested fix: GOTO RECNO()
      skip
    enddo

  Nantucket indicated that "placing a GOTO RECNO() directly after the
  field assignment may solve this particular instance of the problem."


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
  (#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() < 5
      INDEX ON PRPOST->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
  (#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
  (#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.  

  See also 'Internal Error #5302'

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

  See also 'Internal Error #5302'

Internal Error #5318
  (#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
  (#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 occured 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 oper-  ~
  ations.  (PACKs with indexes 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.

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.

