如何将多个用户的访问数据库迁移到单个SQLServer数据库

我倾向于上传完整的数据库并在服务器上运行转换。

无论哪种情况,你都需要写一个转换程序。真正的问题是您在客户的计算机上部署和运行了多少转换。我会尽可能的简单,也就是说,只是上传。这样,如果在转换过程中发现任何错误或意外数据,您只需更新服务器,而不需要重新部署转换程序。

你所说的数据总量并不是太大,无法上传,而且听起来大部分数据无论如何都需要上传。

如果在本地安装转换程序,则需要一种方法从中途停止的转换中恢复。这可能比简单地重新启动access数据库的上载复杂得多。

另外,在转换完成之后,您也不表示需要web服务。将这些服务组合在一起,并在转换过程中保持它们的运行和安全性的工作远不止是一个简单的上传应用程序或web表单。

另一个因素是你的客户转变的速度。如果其中某些应用程序将在一段时间内运行当前应用程序,则可能需要随着服务器数据库的时间变化而更新转换应用程序。如果上载数据库并在服务器上运行转换,则只需要更新服务器转换程序。客户下载转换程序但在服务器数据库更新之前不运行它不会有任何风险。

我们有一个类似的例子,我们选择在服务器上运行转换。我们建立了一个网页供用户上传他们的文件。在这种情况下,没有任何东西可以为新应用程序部署。我们发现的唯一缺点是让用户选择正确的文件。如果使用web表单进行上载,则由于安全限制,无法为用户预先选择文件名。在我们的案例中,我们知道文件的位置,但客户不知道。我们在上传页面上为用户提供指导,帮助他们解决问题。通过编写一个小型桌面应用程序来为用户执行上载,可以避免这种情况。

我看到的编写基于服务器的转换的唯一缺点是一些模板数据将被上传,这是不需要的。不管怎样,这是一小部分数据。

服务器专业: -由于错误、意外数据或对服务器数据库的更改,无需重新部署转换 -更容易保护(可能),只有一个访问点-上传。当然,您接受的是access数据库形式的客户数据,因此仍然不能信任其中的任何内容。

服务器缺点: -上传不需要的模板数据

桌面专业人士: - ? 我很难想出任何

桌面缺点: -可能需要部署多个版本

直接与服务器数据库通信。我有一个应用程序直接与托管数据库对话,以避免创建web服务。它工作正常,但如果有机会我不会再走那条路了。internet定期中断,SQL提供程序恢复得不太好。我们训练我们的客户在这种情况下再试一次。我们这样做是为了避免为桌面应用程序创建web服务。我们只是引用服务器连接字符串中的IP地址。有一个完整的安全原因清单不采取这条路线-我们对我们的安全设置和可能的风险感到满意。最后,在不做任何修改的情况下使用桌面应用程序是不值得拥有一个不稳定的产品的。

既然新的数据库服务器可能是业界的标准数据库引擎之一,为什么不考虑将access应用程序链接到此数据库服务器?这样,您就可以简单地将数据以这种方式发送到sql server。

我不太清楚,当access支持到数据库引擎的ODBC链接时,您为什么会考虑建议对数据库引擎使用一组web服务。因此,一个潜在的升级路径是简单地在Access中发布一个新的应用程序,该应用程序必须与当前的现有数据文件(和应用程序)所在的目录相同。然后在启动时,这个应用程序可以简单地将所有表重新链接到您现有的数据库,再加上一个预先链接的表集到数据库服务器。在构建某种类型的web服务方法时,这项工作要少得多。我认为其中的一部分是围绕着数据库服务器将被托管的地方,但是在大多数情况下,也许在迁移期间,您让数据库服务器运行在每个人都可以访问它的地方。现在很多网络提供商都允许外部链接到他们的数据库。

也不清楚在数据库服务器系统中,您将为每个数据库创建单独的数据库,或者正如您在标题中建议的那样,将所有数据库都放在一个数据库中。因为将被放置到一个数据库中,所以在升迁过程中,将在升迁过程中添加一个额外的列,该列标识用户位置或您计划如何区分每个数据库,以区分每个用户数据集。

这种迁移的容易程度将取决于开发人员用于新系统的模式和数据库布局。希望并且很明显,它为每个用户或位置提供了条件,或者您计划区分系统的每个单独用户。因此,我不建议使用web服务,但建议将表从Access应用程序链接到SQL server实例(或运行的任何服务器)。

如何最好地做到这一点将取决于引用完整性和必须执行的业务规则(如果有的话)。例如,合并数据库时是否存在重复的可能性?我认为它们是从你的一些含糊不清的声明中合并而来的:“是的,所有人都有一个数据库,用户id是aspnet成员身份”。

如果你无法控制A1的1000多个用户,你将如何让他们全部转换成A2?

你考虑过给他们一个SQL Server Express数据库来升级,让他们在自己的服务器上托管Web应用吗?