将应用程序从 Visual Foxpro 6 转换为 Visual Foxpro 9 有多容易？
将 Visual Foxpro 6 应用程序转换为 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 the process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的...取决于您项目中的各种元素。
我目前在 VFP9 SP1 和 VFP9 SP2 中都有应用程序（使用 HotFix3 进行报告）
在 VFP9 下使用旧格式 SQL 查询运行时遇到一些问题需要帮助
SET ENGINE BEHAVIOR 70
您可能想保留 70。8 和 9 中的一些增强功能强制使用了一个奇妙的技巧，该技巧在惰性 group by 子句中的早期查询中使用...仅按您关心的几列进行分组，尤其是在加入查找时无论如何，您知道的表总是具有相同的值。在 8 和 9 中，它要求您通过所有非聚合函数来限定分组...在这种情况下，您可能只需将这些“常量”列更改为 MAX( SomeField) as SomeField。无论如何，如果您的组基于 ID 密钥，则最大值永远不会改变。
从查询中已知的其他问题是 SELECT SUM()。如果执行查询，并且没有与查询匹配的记录，则 SUM() 列将返回 NULL，并且当您希望获得数字时，您会得到意外的数据类型。一个快速的方法是始终添加 COUNT(*) 作为 ActualRecords，它总是返回一个数字。然后，您可以检查“Result.ActualRecords = 0”是否执行某些操作来通知用户、中止报告等，否则继续。
报告在 6 的基础上得到了明显的增强，并且具有一些非常好的功能，特别是多个链接表报告区域，而无需执行“打印时间”和在某些条件下进行重叠控制。这对于您想要在最终报告中包含多个相关表来说非常有用。
SQL SUM() Group by 问题的一项更新。我发现，如果您执行
SELECT NVL( SUM(whatever ), 0 ) 作为 FinalColumn，如果您确实遇到没有合格记录的总和，则 NVL() 将采用该空值并将其强制为零，从而防止后续的 NULL 问题...同样，适用于 MIN()、MAX()、AVG() 等。
这些只是一些让我震惊的大问题...
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...
我想说，总的来说，这是相当无痛的。正如 DRapp 所提到的，您需要检查任何 SQL-SELECT 语句来权衡修改 GROUP BY 子句的利弊，或者使用 SET ENGINEBEHAVIOUR 是否会更容易。通过使用 SET REPORTBEHAVIOUR，可以使报告像 VFP6 一样工作。
另外，当您打开 DBF 时，VFP9 会执行一些表结构检查，而 VFP6 则不会。因此，您可能会发现在 VFP9 中打开 DBF 文件会抛出错误 2065，因为标题记录数不等于实际记录数，而在早期版本中它们可以正常工作。可以使用 SET TABLEVALIDATE 命令控制此行为。
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.
这周我处理了几个 VFP 6 应用程序问题，它们非常令人沮丧，因为这些问题可以很容易地用 VFP 9 SP2 解决。
另一件需要注意的事情是您的数据是否由 VFP 6 ODBC 驱动程序访问。如果您使用 VFP 7 到 VFP 9 中实现的任何新数据库功能（如数据库事件）或新数据类型（如 varchar），您的数据将转换为 ODBC 驱动程序无法处理的格式。改用新的 VFP OLE DB 驱动程序，并且某些工具无法处理 OLE DB 功能。
您会发现新的报表设计器更加强大，但是用于渲染的 GDI+ 需要对报表进行一些字段大小调整，以消除溢出的星星。正如 Alan 所说，您可以使用 SET REPORTBEHAVIOR 来避免这种情况，但您确实需要利用报告预览功能。
您可能会感到困惑的另一件事是 AFIELDS() 命令在数组中创建更多元素。因此，您可能需要调整一些代码来处理创建的数组中的附加行。
如果您遇到任何问题，请在此发帖，我们将为您提供帮助。
里克·舒默
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
这里已经有很多好的答案了。最近转换了 vfp6 应用程序，我想说这个过程相对轻松，特别是使用 vfp9 的编辑器等带来的好处。
有一项没有指出...检查所有报告，并确保“保存打印机”环境”报告选项被关闭，除非列出的打印机确实是您想要硬编码到报告文件中的打印机。
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.
我在将源代码升级到 VFP9 时遇到了一些问题。不过，其中大多数都相当轻微。
您需要做的第一件事是查看 VFP7、VFP8 和 VFP9 的新增功能文档。我知道这看起来很痛苦，但这应该是升级项目时的第一站。 VFP6 及更高版本的文档可在 MSDN。
许多新的属性和方法已添加到类中。如果其中之一与自定义属性/方法冲突，您将遇到错误。
此外，您还需要了解 Vista UAC 要求以及如何处理它们。使用VFP8或以下版本编译的程序以“兼容”模式执行。对于 VFP9，程序是使用 Vista 应用程序清单进行编译的，这意味着应用程序清单中的 requestsExecutionLevel 设置为 asInvoker。 VFP8 及以下版本不将其包含在清单中（或根本不包含清单），因此是兼容模式。
这意味着在 Vista 上运行该程序时，有些事情会失败或导致错误。
您可以选择更新应用程序清单，但我不一定推荐它，除非您的程序绝对需要管理权限。
最后，还有一些 Vista 不兼容性 - 一些专门与 Aero 相关 - VFP9 SP2 已修复该问题。因此，如果您要使用 VFP9，请务必使用 Service Pack 2。
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.
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.