Elgin,

>Thanks so much. Turning off the "Use resource file" option worked. While it was off, I was able to open my reports and run my app fine. Out of curiosity, I browsed the Foxuser.dbf file (changed nothing) and turned the "Use Resource File" option back on and I am still able to work and run the reports OK.

Foxuser.dbf as any VFP table with memo fields has tendency to get corrupted from time to time. :) So if VFP start acting up, the first place to look is foxuser.dbf.

>Do you have time to tell me why that is? If it's the resource file "foxuser.dbf" causing the problem why when I tested it on a different system where I verified that the resource file was a different file, I had the same problem? And why when I turned the resource file back on I was still able to work OK. Did it delete the Foxuser.dbf and re-create a new one when I turned the option off?

I don't have ready explanation for you. My guess is that something was corrupted and turning Foxuser.dbf on and off somehow fixed it. VFP wouldn't create new foxuser.dbf if you only turned it off and than on.
BTW, did you try to exit VFP and come back to see if everithing still okey? Does it wor now on another PC?

>I can see that the Foxuser.dbf file holds settings, windows states, etc. Is it better to work with or without a resource file?

Yes, Foxuser.dbf stores all this info. I find it hard to work w/o foxuser.dbf in development because all your settins get lost between sessions. Runtime is different story. If you don't need foxuser.dbf in runtime, turn it off by placing RESOURCE=OFF into config.fpw.