David Anderson noted in his "other" blog that he was going to offer 99 reasons to upgrade to VFP 9. His first one "stability".
While I certainly agree that the Fox team has done their job on improving the stability of the product in VFP 9, I was dismayed recently to get an email from someone who just upgraded from 6 to 9 and found:
" I have been trying to convert my application system from Foxpro 6 to 9. I have noticed that if the system abends during test runs, tables tend to become easily corrupted. In all the times I have worked with Foxpro 5 & 6, I have never run into this problem of table corruption during abends. In Foxpro 9, it happens all too frequently!"
Part of the issue here is the network environment so I recommended he try the SET TABLEVALIDATE command introduced in VFP 8.
But his other comments were interesting as well:
When I tried to open up the Foxpro 6 application using Foxpro 9, it complained that the project table was corrupted. It refused to open it. Only way to fix the problem was to open up the application under Foxpro 6, select PROJECT, then CLEAN UP PROJECT. I was then able to open up the application under Foxpro 9.
Had a syntax error for a LOCAL statement that had multiple variables separated by blanks. New syntax insists variables be separated by commas.
- frustrating yes, but I would be happy that FoxPro is now identifying these little syntax errors.
Updateable tables became corrupted if the application abended. Turned off table validation for each table.
The application toolbar displays differently under Foxpro 9 (larger font?). The toolbar is now too long when the executable is run, truncating the last icon on the toolbar. Fixed by removing some separators, shortening the toolbar.
This is a strange one. A logic bug was introduced that did not exist under Foxpro 6. A table containing a list of years had its record pointer reset from the 1st record to the last record, which we didn't want. What was odd was that this occurred after running a subroutine that does not even access this table! Easy to fix - just added a GO TOP for the year table after this subroutine was called. But I cannot explain why it happened. It worked fine under Foxpro 6.
The Fox team has done a great job on VFP 9 but as seen above, there are little minor "irritations" that older devs may find when moving to the newer environment. Certainly these can be dealt with with minor code fixes.
There are many times that something that is FIXED in a newer version BREAKS the workarounds that users have been using for years.
In many cases, these can be resolved by RTFM (Read the Fine Manual) or at least Read What's New in VFP 9 in the help file. The challenge for many programmers, though, is that time is not on their side. I know the SET TABLEVALIDATE caused MAJOR problems for one of my clients who distribute a fairly wide application. As a result, they had to patch their code to turn off or lower the table corruption checks. Argh!?!?! Why take it away?
Because many networks sadly aren't as robust as they should be and the level of corruption checks that VFP does by default, caused more end user complaints than areas where corruption was actually occurring.
99 Reasons - #1
While I certainly agree that the Fox team has done their job on improving the stability of the product in VFP 9, I was dismayed recently to get an email from someone who just upgraded from 6 to 9 and found:
" I have been trying to convert my application system from Foxpro 6 to 9. I have noticed that if the system abends during test runs, tables tend to become easily corrupted. In all the times I have worked with Foxpro 5 & 6, I have never run into this problem of table corruption during abends. In Foxpro 9, it happens all too frequently!"
Part of the issue here is the network environment so I recommended he try the SET TABLEVALIDATE command introduced in VFP 8.
But his other comments were interesting as well:
When I tried to open up the Foxpro 6 application using Foxpro 9, it complained that the project table was corrupted. It refused to open it. Only way to fix the problem was to open up the application under Foxpro 6, select PROJECT, then CLEAN UP PROJECT. I was then able to open up the application under Foxpro 9.
Had a syntax error for a LOCAL statement that had multiple variables separated by blanks. New syntax insists variables be separated by commas.
- frustrating yes, but I would be happy that FoxPro is now identifying these little syntax errors.
Updateable tables became corrupted if the application abended. Turned off table validation for each table.
The application toolbar displays differently under Foxpro 9 (larger font?). The toolbar is now too long when the executable is run, truncating the last icon on the toolbar. Fixed by removing some separators, shortening the toolbar.
This is a strange one. A logic bug was introduced that did not exist under Foxpro 6. A table containing a list of years had its record pointer reset from the 1st record to the last record, which we didn't want. What was odd was that this occurred after running a subroutine that does not even access this table! Easy to fix - just added a GO TOP for the year table after this subroutine was called. But I cannot explain why it happened. It worked fine under Foxpro 6.
The Fox team has done a great job on VFP 9 but as seen above, there are little minor "irritations" that older devs may find when moving to the newer environment. Certainly these can be dealt with with minor code fixes.
There are many times that something that is FIXED in a newer version BREAKS the workarounds that users have been using for years.
In many cases, these can be resolved by RTFM (Read the Fine Manual) or at least Read What's New in VFP 9 in the help file. The challenge for many programmers, though, is that time is not on their side. I know the SET TABLEVALIDATE caused MAJOR problems for one of my clients who distribute a fairly wide application. As a result, they had to patch their code to turn off or lower the table corruption checks. Argh!?!?! Why take it away?
Because many networks sadly aren't as robust as they should be and the level of corruption checks that VFP does by default, caused more end user complaints than areas where corruption was actually occurring.
99 Reasons - #1
Comments