In Andrew’s The FoxShow #34 podcast he mentioned my frustration with DBFs I posted as “DBFs cause hair loss”. He noted in his show how my views broke when I changed the structure of my table. This was not correct. Breaking views is something that never, ever happens to me when I change DBF table structures.
My frustration post was about the DBF structure not matching what the DBC thought it should be. The DBC contains metadata about all the DBF columns (and much more). This is how VFP determines the mismatch. There is only one way I know to accidentally cause error 1984. You can copy a different set of DBC files (DBC/DCX/DCT) or a different set of DBF files (DBF/CDX/FPT) into the appropriate folders. This would cause the mismatch between the DBF and the DBC. I guess something programmatically could go wrong. I can see this problem occurring if you issue an ALTER TABLE, and between the changing of the DBF and the update to the DBC the power goes out or VFP crashes. I think this possibility is extremely low. No matter how it happens – it is a frustrating error.
The view problem Andrew mentioned is fairly common. So how can I claim my views never break when I change table structures? It happens to everyone right? No. The simple solution is to never write views which have the asterisk as the fields clause. You see, the view with an asterisk tells VFP you want all columns, so in the DBC the columns are specifically listed when the view is saved. If you change the table structure and do not modify the view, the DBC still only knows about the original list of columns, not the new ones added or the ones you removed.
Every view I create has the individual columns specified in the view (the ViewEditor Professional helps with this via the columns to clipboard feature). It does mean I have a little extra maintenance when I change table structures, but the trade off is well worth it to me. If you use Stonefield Database Toolkit (SDT) to maintain your table structures it automatically validates the views and updates the DBC so this problem does not bite you in the behind. Either way works great. I use SDT for reindexing and updating the structures in production all the time, but prefer xCase for data modeling and table structure changes.
So Visual FoxPro developers have at least two different ways to code views and not have them break. I would not doubt if there are more.
