我刚刚下载了SQL Server的新版本：我的先前版本是2008；新版本是2014，我这样做是因为2014提供的功能比我过时的2008版本还要多。将表从2008 Server复制到2014 Server非常容易。我只是去了Tasks并执行了从2008版本的数据库到2014版本的导入，所有操作都顺利进行了。
下一步是复制可编程对象（视图，过程，函数等），这也是一个相当简单的过程。我去了2008版本，并使用了“脚本为...” /“创建为...”。这些创建功能然后将所有这些功能保存在一个文件夹中（为简单起见，我将其称为“ 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
几件事：
要从旧系统转换到新系统？只需在较旧的系统上创建一个备份，然后在新的系统上将其还原。那将传输所有内容-索引，视图，存储过程，所有内容。恢复备份（.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 provider。
一旦选择了提供程序，那么“遵循”连接和命令对象的代码就是所有3个提供程序的相同。
现在，这里的问题当然是，如果您有现有的工作应用程序，那么毫无疑问会存在大量的ado代码。在这种情况下，该应用程序很可能是从VB6开始的。
因此，我将完全承认建议更改所有现有代码，而已知的有效代码显然不是一个好主意。如果代码库很小，那么我将转储ADO。但是，如果代码库很大，那么只有在值得升级的情况下才能进行调用。如果可能的话，我希望有一个小的代码库转储ADO（它不是托管代码，并且随着时间的流逝将出现问题-无论如何也将超过使用寿命）。
以及这三个提供商之间的选择？我会采用sql提供程序。如果您执行一些asp.net + vb.net编码，这也往往会更好地工作。是否存在将来可以与其他服务器一起使用的计划？我实际上建议使用ODBC提供程序！
ADO的问题是您使用并引入了一种非托管依赖关系，与较新的.net对象相比，它不是很好用。这可能会使您失去稳定性，但如果您想使用许多内置的.net功能（数据网格等），也可能会陷入困境。也许有人可以发表评论，但是非托管ADO对象甚至可以自动转换为组合框，数据网格等.net对象吗？我怀疑它们可能是由于从VB6迁移代码所致-但这是很久以前的事情了。
而且您还将失去使用数据集设计器的能力。 （或现在称为“实体框架”的较新版本）。
因此，新的“ ado.net”对象实际上与ADO的关系为零，您可以选择上述提供者中的任意三个，然后与ado对象一起使用，不管选择的提供者如何，都可以使用相同的ado对象。
如果您想提升一些代码等以与asp.net（Web应用程序）一起使用，这会发挥更大的作用。通过使用ADO，您将失去使用某些.net控件的能力。
并且请记住，ADO在很多年前就已贬值。实际上，最新版本的SQL Server声明它们不正式支持oleDB连接。 （它们可以工作，但是可以提供生命支持-以及基于该技术的ADO）。
您当然可以像过去一样使用ADO对象模型来创建视图等。只是您使用的是非.net库，而是Windows非托管库。它不是很多，以至于它是“较旧的”，但并不是围绕.net对象和模型真正设计的。
如前所述，如果您有很多现有代码，这对您可能不切实际。但是，如果您很少或正在考虑引入和使用ADO？不要！
您发现使用sql provider的学习曲线非常短-几乎不会错过任何机会。与ADO相比，您还被迫以.net方式执行操作，并且与ADO相比，您可以更轻松地获得更多断开连接的对象。
因此ado.net与ADO并没有真正的关系。而且，您可以将任何提供程序与内置的ado .net对象一起使用。调用ado.net可能不是最佳选择，但是再次出现.net时，一个不怕开发人员的友好名称因此是一个不错的选择。
我强烈建议您在这里避免使用ADO。使用sql provider-它确实是内置的。虽然我可能会遇到一些麻烦？在sqlprovider之后，我的下一个选择是ODBC提供程序-它是一个开放标准，不仅限于Windows，而且具有广泛的支持-即使在非Windows系统上也是如此。