0

我刚刚下载了新版本的SQL Server：我之前的版本是2008；新版本是 2014，我之所以这样做是因为 2014 提供的功能比我过时的 2008 版本更多。将表从 2008 Server 复制到 2014 Server 非常简单。我只是去Tasks并执行了从2008版数据库到2014版的导入，所有这些都顺利进行。

下一阶段是复制可编程对象（视图、过程、函数等），这也是一个相当简单的过程。我去了 2008 版本，并使用了“Script As...”/“Create To...”。然后我将这些创建功能保存在一个文件夹中（为简单起见，我将其命名为“C:\ObjectFolder\”，然后运行我编写的一些 VB.Net 例程：ReturnFilesInFolder()列出文件序列，并ReturnFileContents()返回特定文件的内容作为字符串。目的是让 ADODB 连接执行产生相关对象的文本，但在我的服务器的 2014 版本中。这利用了我已经开始的工作并提供了我的 2014 服务器与我在 2008 年建立的相同信息。但是，该技术不起作用，

为了解决手头的问题，我运行了我在 2014 年服务器上创建的文件，并忠实地执行了该过程。我现在想知道将编程对象从一台服务器传输到另一台服务器的最佳实践是什么。如果不使用 ADODB 连接，那么自动化批发转移的技术是什么？谢谢你。 

Sub Build_SQLObjects_2014()
    Const strObjectFolder As String = "C:\ObjectFolder\"

    Dim Conn_2014 As ADODB.Connection = Return_SQLServer_2014Connection()

    Dim strFiles() As String = ReturnFilesInFolder(strObjectFolder)

    Dim iCount As Integer

    For iCount = 0 To UBound(strFiles)
        Conn_2014.Execute(ReturnFileContents(strObjectFolder & strFiles(iCount)))
    Next
End Sub
4

1 回答 1

0

一些东西：

从旧系统转移到新系统？只需在旧系统上创建备份，然后在新系统上恢复即可。这将转移一切——索引、视图、存储过程，一切。不仅恢复备份（.bak 文件）的速度非常快，而且还确保移动旧数据库中的所有内容，并通过一个简单的操作进行移动。

接下来：您可以使用 ADO，但如果可以，我会避免这样做。主要原因是这些库不仅非常旧，而且您错过了使用所有较新的 .net 对象。

在 .net 中，您可以/必须选择一个提供者。最常见的3个是：

oleDB provider - this works with say Access, and you can use sql server.  

ODBC provider     This again works with Access, and you can use sql server

SQL Provider.     most common and best for use with sql server

如果可能的话，我当然会选择 sql 提供程序。

一旦您选择了一个提供者，那么“跟随”连接和命令对象的代码对于所有 3 个提供者来说都是相同的。

现在，当然这里的问题是，如果你有一个现有的工作应用程序，毫无疑问存在大量的 ado 代码。既然如此，该应用程序很可能是从 VB6 开始的。

因此，我将完全承认建议更改所有现有代码以及已知的工作代码显然不是一个好主意。如果代码库很小，那么我会转储 ADO。但是，如果代码库很大，那么只有在值得升级的情况下才能调用。如果可能的话，我会使用一个小的代码库转储 ADO（它不是托管代码，并且随着时间的推移会出现问题 - 而且它也已经过了生命周期）。

以及 3 个提供商之间的选择？我会采用 sql 提供程序。如果您进行一些 asp.net + vb.net 编码，这也往往会更好地工作。如果未来有计划使用不同的服务器？我实际上建议使用 ODBC 提供程序！

ADO 的问题是您使用并引入了非托管依赖项，与较新的 .net 对象相比，使用它并不是那么好。这可能会使您失去稳定性，但如果您想使用许多内置的 .net 功能（数据网格等），也会使您陷入困境。也许有人可以发表评论，但非托管 ADO 对象是否会自动转换为 .net 对象，如组合框、数据网格等？我怀疑他们可能是由于从 VB6 迁移代码 - 但那是很久以前的事了。

而且您也失去了使用数据集设计器的能力。（或者现在称为“实体框架”的较新的花式版本）。

因此，新的“ado.net”对象与 ADO 的关系确实为零，您可以选择上述任何 3 个提供程序，然后使用与您选择的提供程序相同的 ado 对象。

如果您想提升一些代码等以用于 asp.net（Web 应用程序），这将发挥更大的作用。通过使用 ADO，您将失去使用某些 .net 控件的能力。

请记住，ADO 在几年前就已经贬值了。事实上，最新版本的 SQL Server 声明它们并不正式支持 oleDB 连接。（它们可以工作，但需要生命支持——以及基于该技术的 ADO）。

您当然可以像过去一样使用 ADO 对象模型创建视图等。只是您使用的是非 .net 库，而是 Windows 非托管库。与其说它“旧”，不如说它不是真正围绕.net 对象和模型设计的。

如前所述，如果您有大量现有代码，这对您来说可能不实用。但是如果您很少或正在考虑引入和使用ADO？不！

您会发现使用 sql 提供程序的学习曲线非常短——而且您几乎不会错过任何一个节拍。与 ADO 相比，您还被迫以 .net 方式做事，并且与 ADO 相比，您可以更轻松地获得更多断开连接的对象。

所以 ado.net 与 ADO 并没有真正的关系。您可以使用任何具有内置 ado .net 对象的提供程序。称它为 ado.net 可能不是最好的选择，但是当 .net 出现在现场时，一个不吓跑开发人员的友好名称因此是一个好的或好的选择。

我强烈建议您在这里避免选择 ADO。使用 sql 提供程序 - 它确实是内置的。虽然我可能会遇到一些问题？在 sqlprovider 之后，我的下一个选择是 ODBC 提供程序——它是一个开放标准，不限于 Windows，并且具有广泛的支持——即使在非 Windows 系统上也是如此。

于 2020-06-09T06:44:17.120 回答