End of file encountered 2

[neilwheatcroft]

Hi,

I'm not sure if this is the correct forum for this. I wonder if you could help me with this problem. I have inherited an application running on DBaseIII Plus version 1.0 which I know is really old, and I desparately need to work out another way of storing the data. The thing is that for years it has just worked, but today when users are looking at existing records they get the message:


End of file encountered.
?
GO BOTTOM--------------------------------
Called from - G:TMEOF.prg
Called from - G:TMLOCATE.prg
Called from - G:TMMENU1.prg
Cancel, Ignore, or Suspend? (C, I, or S)

Cancel or Suspend just freezes the DOS session. Ignore just takes you back to the menu. The database is on an NT4 server share, and clients are running W2K Pro SP3, nothing at all has changed on the clients or server. As I would have had to have made the changes.


The clients run: 'dbase.exe tmmenu1' to access the application.

Any help gratefully received.

Thanks

Neil

 

[dbMark]

End of File Encountered

The table being accessed by G:TMEOF.PRG with the GOTO BOTTOM command most likely has a bad index. That can easily happen when an indexed table is open when a computer crashes. Determine which table it is and REINDEX it. If you still have the problem you may have to delete the tags or indexes and recreate them.

A second possibility is that the table itself has been corrupted. In that case you have to decide whether you want to repair the table or get the latest copy from the backups. In either case, your data may not be fully up to date and you may need to verify the contents of the fixed table.

Details on how to help you depend on (1) whether you have the dBase program which it seems you do, (2) whether that table uses standalone indexes or tags which are indexes in a master index file and (3) whether this is an indexing or table problem.

I'm not sure, but I don't think you have to worry about tags since that capability may have been added to dBase after your version.

If you can't decide which table is affected, look at the code of G:TMEOF.PRG and see if you can figure out which table it is working with. If there are multiple "GOTO BOTTOM" commands, then run the program and when it errors, select SUSPEND and then at the prompt type this in order to get the exact line number:

? LINE()



dbMark

 

[1oldfoxman]

dbMark's info is most likely correct - this error is frequently due to unsynch'ed indexes. dBaseIII+ did not include index tags so he's correct you do not need to worry about those - the indexing in dBaseIII+ was very straightforward.

Additional suggestions (if you need more detail command help...):

As suggested, when the error occurs, choose <suspend>. This should leave you at "dot prompt", where you can enter interactive commands.

? lineno()
This will tell you exactly which line of TMEOF.PRG is generating the error.

disp stat to print
This will list the open data files, open indexes, and index expressions for each to your printer. You'll need this to reindex or recreate indexes.

cancel
modi comm tmeof.prg
dbase's text editor, count down to the line indicated by lineno() above. Look for the last SELECT or USE command executed before this line. This should include the name of the table being opened for use (not necessarily always, but we'll address that if it's not there later....) For the sake of illustration, let's assume the table is named MyTable. Find the index (if any) that was open in the listing produced by the disp stat to print command. Let's assume the index name is MyIndex and the index expression is MyField1 + MyField2.
<esc>
Exits the editor w/o saving changes.

From the dot prompt, reindex by executing......
clear all
use MyTable index MyIndex
reindex

This will force dBase to recreate the existing index MyIndex and hopefully resolve your problem. If you get some error message that looks like the reindex won't execute because things are too corrupt, then....

use MyTable
index on MyField1+MyField2 to MyIndex

A different and less likely scenario that could be causing the end of file encoutered error is that during program execution the record pointer is already at the the EOF marker when the GO BOTT command is exectued. From the name of the programs and the fact this problem hasn't been encoutered over many years of use, I'm inclined to doubt the original programmer left this vulnerabilty in their program. I.e. index corruption is the likely culprit.

hth
Dennis

 

[neilwheatcroft]

dbMark and 1oldfoxman thank you very much for your help on this. 1oldfoxman I tried your suggestion of ? lineno() and I couldn't get the command to work. I though I must betyping the command in wron, so I tried it a few different ways (with different spacing between the prats of the command) but I either get:

Invalid function name.

or

*** Unrecognized command verb.

I had a look at the other commands and they are very helpful, so thanks for the help with those. I can't help thinking I'm doing something wrong with the ? lineno()command!!!

 

[1oldfoxman]

Maybe I'm confusing more recent functions with older ones. Did you try ? LINE() (dbmark's suggestion)?

dennis

 

[neilwheatcroft]

Hi Dennis,

Thanks for your reply. I tried the ? LINE() command, when I noticed that the ? lineno() didn't work. Is there a command that will list all valid commands, in case it is something slightly different?

Thanks

Neil

 

[1oldfoxman]

From the dot prompt, try help or help functions. I don't have dBaseIII+ in front of me, but I think this will open a navigable list of commands/functions for reference. (It's been a long, long time......) help lineno() would display the help info for this specific function if it exists.

dennis

 

[dbMark]

The official function name is probably just as Dennis said, LINENO(). The reason I suggested using LINE() is that virtually all commands and functions available in the early dBase versions would work just fine by using just the first 4 letters of the name. One of the reasons programmers took advantage of it and shortened the names was that the early versions only allowed 254 characters, or about 3 lines of code, in a command line and so space was at a premium.

Why ? LineNo() doesn't work, I don't know. I would have thought it'd be in dBase III+.

Have you tried inserting one of these lines just before the GO BOTTOM line(s) in that program file TMEOF.PRG and keep track of the "current" database name:

? ALIAS()

DISPLAY STATUS

 

[neilwheatcroft]

Thanks guys,

I think the problem is now solved. I'm not sure what is going on, but I can't get any help functions to work (so I can check that the ? line() command is correct, as when I ask for any help the screen just goes balnk, and I get back to a . prompt

Becuase I couldn't see the specific line number refered to I couldn't see what table to reindex, or what indexes to rebuild. I used the:

modi comm tmeof.prg

and

modi comm tmmenu1.prg

commands and then used:

clear all

When I tried to re-index I got messages about files not being in use. I then went back into the DBASE app and chose the 're-index all tables' option from within the menu. (Which I tried a few times before, but to no avail). I think it is a comnbination of the clear all and the in-menu reindex that has solved the problem as I now don't get the error message. I have left the user looking back through existing records to check all is OK. She will come back to me if there are any more issues.

Thanks again

Neil

 

[neilwheatcroft]

Ok, here we go again!!! More advice needed, if possible

I left the users reviewing existing records and they have also had the need to enter a couple of new records. The current situation is that from record 1 to 5026 all is ok, the data seems to be intact and what is expected.

However we are experiencing the following problems:

Record 5027: There is data missing from some fields (it would be handy if this could be fixed, but not the end of the world if it can't be)

Record 5028: The record is completely bank

Record 5029: When Trying to access it get the message 'Record is out of range"

Records 5030 and 5031 When trying to access it get 'Record is not in an index'

Record 5031 was input yesterday, and the user said the input was accepted without errors, but ongoing back in to update some details gets this message every time.

On your advice I rebuild the indexes. By looking at the results of the 'disp stat' to show which fields were being refernced I rebuilt as follows:

index on mark+country1 to tmmarkx
index on appno+country1 to tmappnox
index on regno+country1 to tmregnox
index on country1+proprietor+mark to tmterx
index on proprietor+country1+mark to tmpropx

I then checked the date stamp of the physical files and they were all created at the time I issued the command.

I'm still getting the same errors above, when trying to access the recent record numbers (exactly the same as above)

When I try to create a new record, it correctly labels it as record 5032. However when I re-index it says '5028 Records indexed'

Any ides???

Many Thanks in advance.

Neil

 

[dbMark]

Have you used my program in the FAQs here faq290-4606 to determine whether there is bad data in the table? Sometimes reindexing (step 1) doesn't help because the underlying data is bad in one or more records. Time to proceed to step 2.

Did you find bad data? were you able to fix it? You may have to relete the record, pack the table, append a new record and input the fields again.

Sometimes the header really gets messed up and doesn't have an accurate count of the number of records. There are programs around to fix most header problems. Your problem sounds to me, though, as invalid data.

In really stubborn cases you may have to create an entirely new table. That's because as strange as it seems the table has lost track of the proper number of records it needs. Here's how to do it while preserving as much of the current information as possible without using recovery programs that fix the header.

* How to make a new table, saving info if possible
SET DELETED ON  & ignore deleted records
CLEAR ALL
USE myTable
? "Original table has "+LTRIM(STR(RECCOUNT()))+" records"
COPY STRU TO tmpTable WITH PRODUCTION
USE tmpTable
APPEND FROM myTable
? "Temp table has "+LTRIM(STR(RECCOUNT()))+" records"
RENAME myTable.DBF TO badTable.DBF
RENAME myTable.MDX TO badTable.MDX
* Note that a renamed table won't find its index
COPY TO myTable WITH PRODUCTION
USE
USE myTable
? "New table has "+LTRIM(STR(RECCOUNT()))+" records"
USE
CLEAR ALL

dbMark

 

[dbMark]

You won't have to bother with the "WITH PRODUCTION" part of the code since I just noticed you're using free-standing indexes, not a master (compound) index file.

Most likely problem: a null or CHR(0) is in one of the indexed fields. Also possible is a null or CHR(0) in the deleted flag space.

 

[neilwheatcroft]

Hi DbMark,

Thanks very much for your help on this, it really is much appreciated. I've had a look at the FAQ entry you linked to, and read the detail of your post. Sorry to be a dummy, but I'm really new to this. How do I get the code to run, do I copy it into a text editor and give it a .PRG file extension, and do I just double click to run it - I'm guessing there's more to it than that.

Cheers

Neil

 

[dbMark]

That's right. Copy the text into a text editor such as NotePad, save it as CHKTABLE.PRG - using the .PRG extension. Then run it from dBase such as this way:

DO chktable WITH "mytablename" && <- insert table's name

It will NOT edit, damage or change your table, as the file is opened only in READ mode.