This article is released to the Public domain.  However, if you choose to 
republish or paraphrase any of it, please provide suitable credit and please 
include my CIS number.

    ************************************************************


       CLIPPER SUMMER 87 - the Open Error (0) Story (part two)
       -------------------------------------------------------


Back in the Spring of 1991, I had an experience with Open Error (0) at
a Novell equipped client site that was truly an eye opener.  For no apparent 
reason, one particular program module was unable to open one of the key 
system data files and its indexes, without getting an open error 0.  Other
program modules had no problem with this data file or any of the other files
that were currently open at the time.  One line of code became a brick wall!

Here's what we tried:

  1 - deleted all indexes and reindexed ALL files in the entire application.
  
  2 - recreated all dbf files from empty structures, appending all data
      back to a normal state. Created ALL new indexes.
      
  3 - replaced all Clipper components with copies from the original disks.
      recompiled and linked all program elements.
      
  4 - we shuffled the order of libraries, object file names, etc.

  5 - backed up all data to tape.  Removed the directory structure from
      the novell server. Downed the server. Restored from tape after
      recreating new directory structures.
      

After each of the five above Procedures, we tried the application and 
again came up with Open Error 0 at the EXCACT same line number. Finally:


  6 - restored the client data to our own server running a similar if not
      exact version of Novell. When we ran the application on our system,
      we did NOT have the open error 0 !!!


It became apparent that we were not going to find the answer inside our
code or inside the data files or index files.  The cause of the problem
was external and was affecting the workstation that was running our EXE.  
At the client site, we were able to watch the error occur with the debugger 
and found that all the index keys for all open data files had disappeared.
The debugger displayed a number for each index attached, but the index key
contents was GONE!  Indexkey(0) was returning a string with len() of 0 and
type() = "C".  

My guess is that the Open Error (0) is Clipper's way of saying it can't
macro expand the null string it found in the area in memory where it 
expected to find our indexkey character string.  Somehow, Clipper had
lost the location of its Indexkey table for all open files!

While still in the debugger, I discovered that you could force Clipper 
to find the table by using the indexkey() on a non-active work area that 
had indexes attached.  Luckily, this same technique works without
the debugger linked in.

Just before the line of code causing your Open Error (0), place the following
code:

    x = cust->(indexkey(0))
           
where cust.dbf is in another area with indexes attached.  Cust.dbf canNOT
be in the active (current) work area for this to work.  You of course will
use the name of one of YOUR data files in place of Cust. 


  ************************************************************************

I really should apologize for publishing this horrible little kludge, but it 
really does work.  I've only had to use it twice since the original discovery,
but other programmers have tried this technique and it has worked for them 
as well.  Our staff invested close to 50 hours of non-billable time in this 
kludge and by publishing it, I'm hoping to save someone some time in the 
future.  God knows how many thousands of hours all my friends on Nanforum
have saved me over the years.

One final note, look for a faulty network card or perhaps an older buggy 
version of one of Novell's network shell executables.  It has been reported
that both can cause faulty packets to be passed around, messing with
other workstation's data.  Isn't it just like a programmer to blame the
hardware <g>.


Happy sleuthing!


Larry Bauder,
Vancouver, B.C. Canada
CIS 71320, 2707



