Windows Server 2019上的VFP7应用程序出现问题 [英] Having problem with VFP7 app on Windows Server 2019

问题描述

我有一个客户端在一个有5个用户的网络上运行VFP7应用程序。客户使用4台Windows 7 PC和1台Windows 10 PC。

I have a client running a VFP7 application on a network with 5 users. The clients are using 4 Windows 7 PCs and 1 Windows 10 PC.

网络是Windows 2008服务器。但是上周崩溃了。

The network was a Windows 2008 server. But this crashed last week.

当2008服务器运行时，一切都运行良好。 VFP7应用程序运行良好。

Everything was running great when the 2008 server was running. The VFP7 App performed great.

几天前，客户IT公司推出了一台运行Windows 2019服务器的新服务器。

A couple of days ago, the clients IT company put up a new server running Windows 2019 server.

现在客户端遇到VFP7应用程序问题。

Now the client is having problems with the VFP7 app.

1：查询执行时间为20秒而不是亚秒。这种情况发生在所有客户端PC上。

1: Queries are taking 20 seconds to perform instead of sub-second. This happens on all client PCs.

2：当VFP7应用程序尝试创建索引时，所有客户端都会收到此错误："表没有索引顺序设置"

2: All clients get this error when the VFP7 app tries to create an index: "Table has no index order set"

3：2客户端PC出现以下错误，导致它们退出VFP7应用程序。该应用程序尝试在此错误时加入2个大表："致命错误：异常代码= C0000094 @ 05/17/19 06:30:45 PM ....." ;

3: 2 client PCs get the following error that knocks them out of the VFP7 app. The app is trying to join 2 large tables at the time of this error: "Fatal error: Exception code=C0000094 @ 05/17/19 06:30:45 PM....."

问题： 

- 在Windows上运行VFP7应用程序服务器2019？

-Can a VFP7 app run on Windows server 2019?

- 有什么我可以尝试让这个VFP7应用程序在这种环境下工作吗？

-Is there anything that I can try to get this VFP7 app working in this environment?

- 将它转换为VFP9工作？或者VFP9会更好用吗？

-Will converting it to VFP9 work? Or will VFP9 work better?

- 还有其他任何建议吗？

-Any other advice?

我意识到Foxpro不受支持，但客户真的很喜欢这个应用程序并且想要使它工作。

I realize that Foxpro is not supported, but the client really likes this app and wants to make it work.

推荐答案

服务器的作用是什么，通常它只是数据的文件服务器。您是否正在运行EXE并且客户端正在连接远程桌面？请不要说EXE位于服务器上，客户端有一个启动exe的快捷方式。

What's the role of the server, typically it's just the file server for data. Are you running the EXE and clients are connecting with remote desktop? Please, don't say the EXE is located on the server and clients have a shortcut to start the exe.

另外，为什么客户会索引数据？

Also, why would clients index data?

您可以在数据库的设计时创建索引一次，使用DBF的CDX文件部署数据库，并在任何数据更改时更新索引。只有IDX索引不会自动打开数据并且可能不同步。

You create your indexes once at design time of the database, you deploy your database with CDX files of the DBFs and the indexes update with any data changes. Only IDX indexes don't automatically open with data and can get out of sync.

http://fox.wikis.com/wc.dll?Wiki~C0000094错误 告诉你，如果你索引，你应该首先删除TAG ALL然后索引，但实际上你的问题可能会消失你根本没有在运行时
期间编制索引。我甚至认为你没有考虑多用户，像"表没有索引顺序设置"这样的错误在运行时进行索引时应该是预期的。没有无缝（重新）索引这样的东西。除非你在游标上创建本地IDX索引或
索引，否则这是一个很大的并发问题，无论什么服务器版本，它都可能开始发生，因为表变得更大而不是因为哪个操作系统。



如果这是远程桌面（或Citrix或类似的）甚至是"本地"的IDXes不是本地的，也不是一个用户专用的，除非你在用户会话特定的文件夹中创建它们，如果你移动到远程桌面你在applidcation中生成的任何内容
之前引入远程桌面的东西是单个用户独有的现在已经分享了。因此，在这方面集中应用程序本身在终端服务器上的安装意味着您需要重新组织用户特定的本地数据和索引，并且
唯一在这方面自动的是游标，在会话ID分隔的TEMP文件夹中生成。

http://fox.wikis.com/wc.dll?Wiki~C0000094Error tells, if you index, you should, first DELETE TAG ALL and then index, but indeed your problem might go away when you don't index during runtime at all. I even think you're not taking multi user into account, an error like "Table has no index order set" is to be expected when you index during runtime. There is no such thing as seamless (re)indexing. Unless you create local IDX indexes or indexes on cursors this is a big concurrency problem, no matter what server version, it's likely to start occurring because tables grew larger and not because of which OS.

If this is remote desktop (or Citrix or similar) even "local" IDXes are not local and exclusive to one user, unless you create them in the user session specific folders, if you move to remote desktop anything you generate in the applidcation folde that previous to introducing remote desktop was exclusive to a single user is now shared. So in that aspect centralising the installation of the application itself on a terminal server means you need to reorganise user specific local data and indexes and the only thing that's automatic in that respect are cursors, generated in the session id separated TEMP folders.

除了可能性，如果它仍然是一个基于操作系统的问题，你是Windows的oplock设置的受害者，如果服务器只是文件服务器。如果EXE与其上的本地数据一起运行，则不会出现该问题。
Win2008服务器仍然允许关闭smb3并恢复到smb2，现在这已经不可能了，所以如果你使用一些注册表项来处理这个问题，它们在今天的Windows服务器版本中没有任何影响。

Besides that the likelyhood, IF its still an OS based problem is, you are victim of the oplock settings of Windows, if the server is just the file server. If the EXE runs on it together with the data being local there, that problem doesn't arise, though. Win2008 server still allowed to turn smb3 off and revert to smb2, nowdays this is no possibility anymore, so if you used some registry entries to handle this, they're not having any effect in todays Windows server versions.

所有这一切现在都应该是众所周知的。

All of that should be really well known by now.

Bye，Olaf。

这篇关于Windows Server 2019上的VFP7应用程序出现问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！