Internal Consistency Error 1

[amartureo]

I've been using DOS Foxpro (currently 2.5) for years without ever running into this error. It now appears to crop up randomly. I've recompiled my programs and recreated my indexes, but my program still aborts unexpectedly with the internal consistency error. Is this usually related to indexing issues? Could it be from a problem in my set relationships handling? I have a relationship set up on an ID index, but display the file with a date/time index. It works fine for quite a while, then bang - ICE.

 

[Scott24x7]

Amartureo,
In my experience, Internal Constency errors have been the result of memory issues. Have you installed any new software on your machine around the same time the problem began? (Not necessarily related to FoxPro?) I don't think I've ever seen an IC error in association with an Index. My advise is, look closer for something "Random", it's probably not.
Best Regards,
Scott

Please let me know if this has helped

 

[URSTraining]

I've narrowed this problem, in my case, down to the files= statement in my config.sys. When running my FPW 2.6a application over a network, setting my config.sys too high resulted in the Internal Consistancy Error. Lowering it a bit (243 seems to ring a bell) alleviated the problem. Of course, I then had to contend with Too Many Files Open. I had to experiment until I found a happy medium.

 

[DSummZZZ]

When you recreated your indexes, did you delete the .CDX file and recreate them from scratch or just do a REINDEX? Doing a REINDEX doesn't always cure the problem, especailly if the index header is corrupt.

Dave S.

 

[amartureo]

I appreciate the replies, but none of the three have resolved the issue. The internal consistency error raises its ugly head on a computer with 256Mb of RAM and 96% free resources, with various files settings, and after deleting and recreating the CDX file.

I'm still guessing its from my SET RELA coding. Rather than setting the relationship into the child, I set the relationship into the parent. This is necessary to allow me to work in the child records with information displayed from the parent that is associated with it. (An appointment book that refers to the patient file to display names, phone numbers, etc.. The can be many appointments for a single patient) If I set the relationship into the parent, the Patient information isn't automatically grabbed.

Do you think the 'internal consistency errors' are caused by the many to one relationship?

 

[DSummZZZ]

I can't see the many-to-1 relationship causing any trouble, but if these are live tables, and someone is trying to update them at the same time you are trying to report on them that could cause the error.
I have had these errors reporting or even browsing related tables which are being updated live because of record pointer positioning in relation to a changing EOF().
My suggestion is that you run a query on the table for the record you need to report on then run your report from the query. It will be much more stable that way.

Dave S.

 

[dgrewe]

Any New Hardware been added lately?

I got that same problem a lot in the past when I moved files across 16-32 bit FAT's on different hard drives.
It ended when I stopped using the DOS copy command to copy DBF&CDX's and used the copy with cdx command instead.
David W. Grewe
Dave@internationalbid.com

 

[amartureo]

It's really discouraging that I couldn't zero in on the source of the 'internal consistency error'. Rewriting my code to eliminate the SET RELA eliminated the problem, but it certainly is ugly that I must now SELE <parent> SEEK <match by ID) SELE <child> every time I move the pointer in <child>. SET RELA should be doing this for me without randomly crashing my program. And now I'll have to use a list subroutine since BROWSE won't be able to output a window with fields from both tables.

Thanks for all your input. I tried it all.