How easy is it to convert an application from Visual Foxpro 6 to Visual Foxpro 9?_问答_开发者

Are there any problems converting a Visual Foxpro 6 application to Visual Foxpro 9; or is this straight forward?

Any gotchas that I should watch out for during th开发者_开发知识库e process?

yes... depending on a variety of elements in your project. I currently have apps in both VFP9 SP1, and VFP9 SP2 (with HotFix3 for reporting)

Some issues to HELP run under VFP9 with older format SQL queries

SET ENGINE BEHAVIOR 70 You probably want to stay with 70. some of the enhancements in 8 and 9 force a wonderful trick that was utilized in early querying in lazy group by clauses... only group by the few columns you cared about, especially when joining to a lookup table that you knew would always have the same value anyhow. In 8 and 9, it requires you to qualify the group by, by all non-aggregate functions... In such case, you might have to just change those "constant" columns to MAX( SomeField) as SomeField. The max would never change if your group was based on an ID key anyhow.

Other issues known from the query was with SELECT SUM(). If you did a query, and there were no records that matched the query, the SUM() column would come back as NULL, and you would get an unexpected data type when you were hoping for a number. One quick catch was to always add a COUNT(*) as ActualRecords which would ALWAYS return a number. Then, you could check if the "Result.ActualRecords = 0" do something to notify user, abort report, whatever, otherwise continue.

The reporting is obviously enhanced from 6 and has some really good features, especially mutiple linked table reporting regions without having to do "Print When" and overlap controls under certain conditions. This is great for multi-related tables you want in a final report.

ONE UPDATE on the SQL SUM() Group by issue. I've found that if you do a

SELECT NVL( SUM( whatever ), 0 ) as FinalColumn, if you DO run into a sum with no qualifying records, the NVL() will take that null value and force it to zero and thus prevent subsequent NULL issues... Similarly, apply to things like MIN(), MAX(), AVG(), etc.

Those are just some of the big ones that glare out at me...

I would say it is fairly painless in general. As mentioned by DRapp you will need to review any SQL-SELECT statements to weigh up the pros and cons of amending GROUP BY clauses, or if it would be easier to use SET ENGINEBEHAVIOUR. The reporting can be made work like VFP6 by using SET REPORTBEHAVIOUR.

Also VFP9 does some table structure checking when you open a DBF that VFP6 doesn't. As a result you may find that opening DBF files in VFP9 will throw an error 2065 because the header record count does not equal the actual record count, whereas they would work fine in the earlier version. This behaviour can be controlled with the SET TABLEVALIDATE command.

I have dealt with a couple of VFP 6 app problems this week and they have been frustrating as heck because the problems could easily be addressed with VFP 9 SP2.

One other thing to be careful on is if your data is accessed by the VFP 6 ODBC driver. If you use any of the new database features implemented in VFP 7 to VFP 9 like database events, or the new data types like varchar your data will be converted to a format that the ODBC driver cannot handle. The new VFP OLE DB driver is used instead, and some tools cannot handle the OLE DB functionality.

You will find the new report designer way more powerful, but the GDI+ used for rendering will require some field size tweaking on reports to get rid of the overflow stars. You can avoid this using the SET REPORTBEHAVIOR as Alan notes, but you really are going to want to take advantage of the report preview capability.

One other thing you might get burned on is the AFIELDS() command creates more elements in the array. So you might have to tweak some code to handle the additional rows in the array created.

If you run into any problems, please post here and we will help you out.

Rick Schummer

Lots of good answers here already. Having converted a vfp6 app recently, I'd say the process was relatively painless, especially for the benefit that comes from using vfp9's editor, etc.

One item not pointed out... Check all your reports, and make sure the "Save printer environment" report option is turned OFF, unless the printer listed there is really the one you want hard-coded into your report files.

I have run into a few issues upgrading our source to VFP9. Most of them rather minor, though.

The first thing you need to do is review the What's New documentation for VFP7, VFP8 and VFP9. I know this seems like a pain, but it should be your first stop when upgrading a project. Documentation for VFP6 and up can be found on MSDN.

Many new properties and methods have been added to classes. If one of these conflicts with custom properties/methods, you'll run into errors.

Also, you will need to become aware of Vista UAC requirements and how to deal with them. Programs compiled with VFP8 or below are executed in "compatibility" mode. With VFP9 programs are compiled with a Vista Application Manifest, meaning the requestedExecutionLevel in the application manifest is set to asInvoker. VFP8 and below do not include this in the manifest (or do not include a manifest at all), hence the compatibility mode.

This means that when running the program on Vista, several things will fail or cause errors.

Attempting to write to HKEY_LOCAL_MACHINE in the registry will fail.
Attempting to write a file to %programfiles% or any protected folder will generate an error. Programs should only write to common folders.

You have the option of updating the Application Manifest, but I wouldn't necessarily recommend it, unless your program absolutely requires administrative priviledges.

Finally, there are a number of Vista incompatibilities - some dealing specifically with Aero - that were fixed with VFP9 SP2. So, if you are going to be using VFP9, be sure to use Service Pack 2.