
  Clipper 5.0  Internal Errors, V1.0  (9101.05)
  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.

  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.  As for the accuracy
  of these statements ... 

  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.
  


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.

  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."


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

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.


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 #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 should clear it up."



Internal Error #1210  (continued)
  (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 #1012.

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


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.  


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.

  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) Nantucket said to "append a CHR(0) to the end of your key
  string."  One user reports this error went away for good.

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."
