Bad count field on D3

Bad count field on D3

Post by Martin Taylo » Mon, 21 Apr 1997 04:00:00



The last time I saw one of these was around 1982 on a Reality.

So. Resurrected in D3/SCO 7.1.15. Here are the circumstances.

In accessing a file using a BASIC program which has been well behaved
for about 6 years, the user got some kind of Referencing Illegal Frame
abort which is absolutely reproducable. To get out, the user types OFF.

The next file-save reports a bad count field, so we investigate. This
turns out to be in the middle of a group in a well sized file ( no
overflow) consisting of very small records. Typically under 30 bytes
each record including the count fields.

We use the gfe handler to fix the offending data and lose about 40
records which we restore from the previous night's file save.
Coincidentally ;) the RIF problem goes away at the same time.

I have very good reason to believe there was no data changed in the
group, although new records may have been added and therefore would have
gone to the end of the group.

So we treated and solved the problem in the time honoured way, but the
question that I cannot answer, and would like at least a clue to, is
what do you think are the possible causes of a bad count field in stable
data?
Martin Taylor (Author of "Pick for Users" and half of "Unix and Unidata")
Datamatters Ltd         http://www.dmatters.co.uk
13 Market Place, Heywood, Lancashire, UK

 
 
 

Bad count field on D3

Post by Tom Powe » Tue, 22 Apr 1997 04:00:00



> In accessing a file using a BASIC program which has been well behaved
> for about 6 years, the user got some kind of Referencing Illegal Frame
> abort which is absolutely reproducable. To get out, the user types OFF.

> The next file-save reports a bad count field, so we investigate. Thissnip
> So we treated and solved the problem in the time honoured way, but the
> question that I cannot answer, and would like at least a clue to, is
> what do you think are the possible causes of a bad count field in stable
> data?

We had a series of 'funnies' with one of our D3/SCO sites - during
filesaves we got group inconsistency errors (GFE survives no matter what
the advertising blurb says!) on the dictionary portion of program files
which had not been recompiled for months. Concurrently we were having
problems with terminals connected to the digiboards. Then one fine day
the digiboards refused to work and the runaround started! Eventually
seemed to be the PCI digiboard controller and the EISA Smart-Array
controller for the compaq disk array didn't like each other. We now have
an ISA digiboard controller and harmony prevails.

I don't know your hardware config but maybe there's a clue?

 
 
 

Bad count field on D3

Post by CWNoa » Thu, 24 Apr 1997 04:00:00


Martin,

If new records were added, I believe the entire group would be re-written,
even though the new records were added at the end. The reasons a bit or
byte could be changed improperly are myriad - power hiccup, transient
memory glitch, gremlins, a bug in D3 (gads!). You probably will never know
for sure.

Anyway, can't a count field be changed in the de*? If D3 allows it,
it would be far easier than restoring the lost records. Just a thought...

Regards,
Charlie

PS:  It's good to know there are still others around who remember Reality
back in the early 80s ;)>



>Subject:    Bad count field on D3

>Date:       Sun, 20 Apr 1997 13:00:25 +0100

>The last time I saw one of these was around 1982 on a Reality.

>So. Resurrected in D3/SCO 7.1.15. Here are the circumstances.

>In accessing a file using a BASIC program which has been well >behaved

for about 6 years, the user got some kind of Referencing >Illegal Frame
abort which is absolutely reproducable. To get out, the >user types OFF.
Quote:

>The next file-save reports a bad count field, so we investigate. This
>turns out to be in the middle of a group in a well sized file ( no
>overflow) consisting of very small records. Typically under 30 bytes
>each record including the count fields.

>We use the gfe handler to fix the offending data and lose about 40
>records which we restore from the previous night's file save.
>Coincidentally ;) the RIF problem goes away at the same time.

>I have very good reason to believe there was no data changed in the
>group, although new records may have been added and therefore >would have

gone to the end of the group.
Quote:

>So we treated and solved the problem in the time honoured way, but >the

question that I cannot answer, and would like at least a clue to, is

Quote:>what do you think are the possible causes of a bad count field in >stable
data?
>Martin Taylor (Author of "Pick for Users" and half of "Unix and Unidata")


IS Director
Affiliated Acceptance Corp
3101 Mercier, Ste 407
Kansas City, MO 64111
 
 
 

1. Bad Count Field errors and replacing a hard drive

One of our clients is running A/P PRO 6.1.25, although we are trying to
convince them to go with D3.  They've had numerous GFE's and 'Bad Count
Field' errors.  We've had them replace some of the hardware and memory,
but over the past month, they've had 2 Bad Count Field errors.  I dumped
the frames and found that both times, the bad record contained several
attributes which somehow merged into one and dropped the attribute marks
in the middle.  We recommended that they replace their hard drive and
disk controller.
Question:  What kind of drive do I recommend that will work with the
existing BIOS?  Their machine was purchased in 1996 - it's a pentium 133
mhz/256k processor, 16 mb ram.  Their existing drive is a 2 gb drive.

Thanks.

2. Database error

3. Bound Controls: bad,bad,bad

4. Rich text in SQL?

5. RDO bad, bad, bad

6. Can we turn Foxpro programs into DLL which can be called by other non-Foxpro programs

7. Tables Log retrieval

8. Oracle 7.3 and Forms 3.0 -- BAD, BAD, BAD!!!

9. Syntax error COUNT() : Using COUNT() with char field

10. delphi3 access97 index bad count.....

11. Bad performance with Visual Basic and D3 AIX (and a question for Tony Gravagno)

12. D3/Linux Bad Print Jobs; 0 bytes jobs