I removed some DBFs from my VFP project but one of them is still causing an error when I try opening my form to edit. I removed all references to the DBFs in the code (from the form objects/methods), and the DBFs are not included as data tables within the project.
The error also occurs if I try to open the SCT file on its own outside of the project. The error:
I opened the SCT file in a text editor and found an entry for the deleted DBF, but I'm not sure what the entry actually is or what the proper way of removing it is. Can I just remove lines #7 and 8?
Why/how was this created in the first place and why did it stick around?
You SHOULD be able to get rid of them by simply open the form in VFP
Then right-click anywhere in the open area of the form and select data environment. It will list any possible table/view/relationship entities associated with the form. Just click on each of the items and delete them and save the form. That should get you good to go.
ADDITIONALLY,
Within VFP, forms and classes are nothing but .DBF files with a changed suffix
.SCX = .DBF
.SCT = .FPT
.VCX = .DBF
.VCT = .FPT
In addition, project and reports are the same thing...
.PJX = .dbf
.PJT = .fpt
.FRX = .dbf
.FRT = .fpt
So, now that you know its a database file, you can open directly within VFP
use MyForm.scx
browse normal nowait
Now, look at the rows and double-click on the "Class" column. You probably have the data environment and cursor references in the second and third rows showing class content as "dataenvironment" and "cursor".
you could also do
browse normal nowait for atc( "dataenvironment", class ) > 0 OR atc( "cursor", class ) > 0
You can delete these records.
There could also be "relationship" links between tables as well, but just on its own, editing the data environment from the designer is the safest manner to do so. Lots of interesting stuff within the screen and class version .dbf tables though.
FEEDBACK
When designing a form, you can add whatever tables and relationships to the form. This prevents you from having to manually open the tables, setting index order, setting relationships before the form even loads. I personally have not built that way going all the way back to 1993 when VFP 3 came out. I preferred coding opening tables. This allowed for customizable path setting such as supporting multiple "company" such as in an accounting application. Anyhow, probably not what you are involved in but glad it worked for you.