ERROR 3021 either BOF or EOF is true

[ralphcarter]

The above error is generated on both XP and W2K machines.
The application works on development our machines but when we try distributing and running it on another machine we get the above error.

This app is a VB 6.0 app that uses ADO to read VFP 9.0 tables to create a PDF from Active reports. I have looked at dependancies and installed MDAC 2.8 SP1 on the test machine to no avail.

All help appreciated since we have a rollout date of TOMORROW!

Thanks
Ralph

 

[genomon]

First place to start is to see if there is any data on the target PCs database; no idea what VFP 9.0 is but assume it's another RDBMS? Could also be some kind of corruption in the db? Otherwise check for missing or broken library references on the "bad" PC. Maybe the connection string doesn't work with the ODBC provider on that PC? Hope this helps (I know it's pretty basic, but the app isn't getting at the data somehow). That's a nasty deadline to meet......




I wondered why the baseball was getting bigger.
Then it hit me.

 

[BobRodes]

It's Visual Foxpro, and yes, it's like any other ISAM DB. Agreed about the nasty deadline.

The reason that this error comes up is because you have tried to access a record when you have run past either the beginnning or the end of a file. This can happen either when that is literally what you have done in your code or because you have tried to access an empty recordset. (BOF and EOF are both true when a recordset is empty.) Given that your program works in the dev environment, this latter is more likely to be the case. Reasons could be any of those that genomon mentions, and another could be that the access rights differ on the production test machine. I would check that first.

Troubleshooting a compiled program generally involves logging stuff to a file. If you're in a hurry, you can just msgbox the things you want to see. For example, each time you open a recordset, msgbox the eof and bof. Also, try disabling your error handlers and see what you get. Also, don't forget to check the errors collection of the connection object. Sometimes multiple errors in multiple layers are generated by an attempt to connect, and the one you're looking for isn't the last one generated. (That's why there's an errors collection for the connection object.)

I would strongly recommend also that you spend time refactoring your architectural and engineering processes from the ground up. If your process permits distributing and running your application in the production environment for the first time (I can't imagine that this has come up after multiple testing iterations, but anything can happen of course) the day before scheduled release, I'm afraid it is flawed beyond all repair.

HTH

Bob

 

[SBerthold]

It looks like the connection is fine and the data table is available and a recordset object has opened on it.

There could be several different actions could cause this.

Is there really data in the data table in question on the test machine?
If so, is the data in the tables identical in both locations?

 

[rickyoswaldiow]

with your recordset, try:

 If Not(.eof or .bof) then

...

 

[BobRodes]

Well, yes, Ricky, but that still begs the question of why it works in development and not in production. In some ways your suggestion is to ignore the error. While that's certainly one thing that can be done, there's a risk involved. It's like treating symptoms and thereby masking a disease. Not always the best thing to do.

I personally have the feeling that the OP is unable to properly access the database in the production context and able to do so in the development context. This can be for any number of reasons independent of the program itself, and those need to be troubleshot first. It wouldn't help much to ignore an empty recordset if you need the records later on in the code, you'll just turn a runtime error into a logical one and compound the problem. Furthermore, it doesn't make sense to modify the code and then find out that the compiled program's security context isn't allowed to access the production database. So I say make sure that the program has the rights to access the db first.

Bob

 

[ralphcarter]

Thanks for all the help. We actually discovered that the date format was incorrect. The computers where the program worked had the short date format set to mm/dd/yyyy. The computers where the program didn't work had the short date format set to dd-mmm-yy. Once we discovered this we were able to manipulate the input dates that we were filtering on to be in the format we needed. And everything worked.
It appears the error was actually being thrown in a section of Active reports code so we could not do anything with it.

 

[JoeAtWork]

So I think the question the OP needs to answer is, on a fresh install of the system, is there expected to be data in the recordset?

If the recordset is based on a table that requires to be populated by the user (let's say an Orders table), one would expect the table to be empty on the installation day, and therefore adding a "BOF And EOF" check (with the appropriate behaviour if the recordset is empty) might be the solution.

If the recordset is expected to always be populated, the first thing to check is if the source table actually has data. On roll-out day, one would expect that certain lookup tables would be pre-populated. Did someone mistakenly clear a lookup table before the rollout?

Without knowing the nature of the recordset in question, it is impossible to give good advice here.

 

[JoeAtWork]

The OP's latest post makes mine obsolete.

I am wondering if this reveals that a potential error still exists. It sounds like if you try to run this report with a date range that would return no data, you would still get the error. If you haven't already done so, I would suggest intercepting this error so it is handled gracefully.

 

[ralphcarter]

We actually have a trap in the code to exit with message if no data is selected. Data was being selected but, we can only assume because of the date format conflict, the active reports module was somehow generating the error. Any other insight is welcome. I will continue to monitor this thread for all help.

 

[SBerthold]

Either an error handler was causing an actual error to be ignored (because of the incorrect date format), or no error occured and the "bad" criteria was returning no data (01-02-2007 could be 1 Jan or 2 Feb, depending on the local or user defined format)

Therefore, to start with, when passing dates as criteria, it is safest to always use a date format of YYYY-MM-DD (Format$(Date, "YYYY-MM-DD") - ISO atandard. This should correctly handle any system date formats set in any local. Then no matter what format the system is set in, and as long as the user enters the date in this format, it will get correctly converted.