Guesses follow:

I suspect that you never see this on your test PC because the environment always has that alias open when you work there.

The opposite, of course, would be true at a user's PC.

The best way to preclude this kind of error is to have at least one test of the application starting with NO databases/files open to make sure of dependencies.

Good luck


>Jim,
>
>Thanks for the suggestion. I did find a filtered index on the saTests table that included the table alias in the filter expression:
>
> empty(satests.tes_dreport)
>
>I removed the alias from the filter and that seems to have resolved the problem on the PC that I have been using as a test bed. I no longer get the dialog that wants me to locate the table and the database validates OK. Hopefully, it will have the same effect on the client installation.
>
>I do have a couple of questions if you don't mind.
>
>1) Why does the alias cause a problem in the first place since it is the correct alias for the table in question?
>
>2) Any idea why I have never seen this on my development PC? I am guessing that the alias is not there on the saTests table on my development PC (I will check that this evening). Does an alias sometimes get added to a filtered index by VFP?