Geoff Barnard wrote:
> Joe,
>
> Firstly, seems you ARE in the correct group. Looks like the CMS system
> does use one of the Sequiter products, from the full error message you
> quoted could be one of the versions of CodeBasic, a variety of the
> CodeBase that I use. The error -70 is well known!
>
> Looks like the software used .DBF files, but in this case with the dBase
> IV style .MDX indexes. I don't know off-hand what the partic features
> of those are.
>
> Looking at the Cougar Mountain Software web site, I see that the version
> you now have (10 ?) should be a fully WinDoze version, replacing an
> older DOS system? If it is a fully WinDoze version, then the
> 'available memory' question should be irrelevant. Yes, there may be a
> question about system resources, but not about the TPA (which is the
> usual question for older DOS systems which were based within the initial
> 640k of the computer's memory). If CMS are making an issue about the
> TPA, then either their system is NOT actually a WinDoze system, or
> they're just wrong? BUT - I don't claim any sort of expertise with
> WinDoze systems, I'm still happily using DOS which is far far from dead
> yet!!
>
> I note the message comes up while accessing hfpbhgen.mdx - this is one
> of the index files. Have you any idea what this file is about?
>
> The -70 error (this error code is standard to all the Sequiter systems,
> so I've experience of it) usually results from:
>
> a) a damaged index file, leading to a faulty read of the data file - in
> effect the index tells the system to go to a record in the main file
> that doesn't exist, either Rec 0 or a record past the End of File. Fix
> by re-generating the index.
>
> b) a damaged data file, usually because the record count number in the
> header of the datafile thinks there's one or more records in the file
> MORE than the operating system thinks there are, so when the prog tries
> to read record nnn the operating system says NO. A little bit more
> fiddly to fix.
>
> BUT, your error -70 is re****ted as being from reading the .MDX file, so
> this is something different. Certainly, re-generating the index should
> fix the problem, as I assume the index IS damaged. Does your system
> include any facility to re-generate the index. There are utilities
> that will do this, that will work with the different varieties of the
> dBase family. I have utilities for .NDX, .NTX and .CDX but not for
> MDX, maybe someone could point you somewhere??
>
> The big question is - what is causing this problem??
>
> You say the data file (same name as the index ?) is 4.5Mb, but the index
> is 9.6Mb. Hmmm - there are certainly instances where an index will be
> bigger than the data file, but THAT much? An index comprises a lot of
> linked blocks of data, and as the file is used and added to the blocks
> will get very fragmented, even to the point where the index could be
> twice the size that it could be if it were newly generated. The act of
> maintaining/updating an index does use a lot of memory, the more that's
> available the faster the process will be, but the figures you give still
> seem excessive. Unless the file contains a single field, which is also
> the key field?
>
> Maybe an indexing or re-indexing process is being interrupted, so that
> a) the index is left uncompacted, and b) one or more block pointers
> within the file are left wrong, giving rise to the -70 error. This
> interruption could be the result of lack of memory, BUT the Sequiter
> products would normally grab themselves whatever memory they can and
> adjust their task to suit the memory they've grabbed, so they should not
> be running out part way through.
>
> It may be a help to know what the file is, and what the data is that's
> within it. If the problem is restricted to this file, in this partic
> module of the software, then it could be something to do with the nature
> of the data.
>
> Please e-mail me directly about further matters.
>
>
> Geoff Barnard NB not not but net for reply
>
>
> PS - which Queen are you referring to, and what should God save him
from?
> Is this a topical reference to Elton John getting 'married'?


|