Cannot read database error

[Jill_(Guest)]

We are using R&R 6.0 for reporting on FoxPro 2.6 database. We are now frequently getting the error "Cannot read xxx database" on one of our reports as the users page through the report or try to print it. ____We have tried reindexing all the tables used by the report, restoring backup of the indexes then reindexing, having all the users exit the tables so that only one user is using the tables but still to no avail.____The only thing that we have been able to do to resolve the error is, oddly enough, copying the tables from our production area to our test area. Then when we run the report again in production, it seems to work (until the next day that is).____Any suggestions?____Jill

[Randal_Ferguson_(Guest)]

Jill,____Actually the answer to this problem is probably very simple. When you design a report in R&R, R&R saves the location of the data and index files with the report, in this case the test area. When you run the report this is where either the data and/or index files are being read from. Could be one or the other or both but in your report you^ve probably programmed it so the index files are being read from the test area and the data files from the production area.____The reason it cannot read the data files is because the index file(s) are not the same in the test area as they are in the production area, i.e. you^ve added records to the database.____The solution of course is to specify the production area when designing the reports or move the test folder to another computer. If R&R doesn^t find the data and index files in the folder that was saved with the report it will look in the current directory (i.e. the production folder). Hope this helps.____Regards,__Randal Ferguson______>We are using R&R 6.0 for reporting on FoxPro 2.6 database. __>We are now frequently getting the error "Cannot read xxx __>database" on one of our reports as the users page through __>the report or try to print it. __>__>We have tried reindexing all the tables used by the report, __>restoring backup of the indexes then reindexing, having all __>the users exit the tables so that only one user is using the __>tables but still to no avail. __>__>The only thing that we have been able to do to resolve the __>error is, oddly enough, copying the tables from our __>production area to our test area. Then when we run the __>report again in production, it seems to work (until the next __>day that is). __>__>Any suggestions? __>__>Jill __