问题标签 [migration]

是的，我知道。2008 年的运行副本的存在SQL Server 6.5是荒谬的。

6.5那规定，从 迁移到的最佳方式是2005什么？有没有直接的路径？我发现的大多数文档都涉及升级6.5到7.

我是否应该忘记本机SQL Server升级实用程序，编写所有对象和数据的脚本，然后尝试从头开始重新创建？

我打算在这个周末尝试升级，但服务器问题将其推迟到下一个。因此，任何想法都会在一周内受到欢迎。

更新。这就是我最终这样做的方式：

• 备份有问题的数据库并在6.5.
• SQL Server 2000对Master执行instcat.sql。6.5这允许SQL Server 2000OLEDB 提供程序连接到6.5.
• 使用SQL Server 2000'sstandalone"Import and Export Data"创建 DTS 包，OLEDB用于连接 6.5。这成功地将所有的表复制6.5到一个新的2005数据库中（也使用OLEDB）。
• 使用6.5的企业管理器将所有数据库的索引和触发器脚本化为 .sql 文件。
• 在 2005 年的 Management Studio 中针对数据库的新副本执行该 .sql 文件。
• 使用 6.5 的企业管理器编写所有存储过程的脚本。
• .sql针对2005数据库执行该文件。几十个存储过程存在问题，使它们与2005. 主要是non-ANSI joins和quoted identifier issues。
• 更正了所有这些问题并重新执行了.sql文件。
• 重新创建了6.5的登录名2005并授予他们适当的权限。

更正存储过程时有一些冲洗/重复（有数百个需要更正），但升级效果很好。

能够使用 Management Studio 而不是Query AnalyzerandEnterprise Manager 6.5是一个如此惊人的区别。一些需要 20-30 秒的报表查询6.5 database现在在 1-2 秒内运行，无需任何修改、新索引或任何东西。我没想到会有这种立竿见影的改善。

跟踪和/或自动化数据库架构更改的最佳方法是什么？我们的团队使用 Subversion 进行版本控制，并且我们已经能够通过这种方式自动化我们的一些任务（将构建推送到临时服务器，将经过测试的代码部署到生产服务器），但我们仍在手动进行数据库更新。我想找到或创建一个解决方案，使我们能够在具有不同环境的服务器上高效工作，同时继续使用 Subversion 作为后端，通过该后端将代码和数据库更新推送到各种服务器。

许多流行的软件包都包含自动更新脚本，可以检测数据库版本并应用必要的更改。即使在更大规模（跨多个项目，有时跨多个环境和语言），这是否是最好的方法？如果是这样，是否有任何现有的代码可以简化流程，或者最好只是推出我们自己的解决方案？之前有没有人实现过类似的东西并将其集成到 Subversion 提交后挂钩中，或者这是一个坏主意？

虽然支持多个平台的解决方案更可取，但我们肯定需要支持 Linux/Apache/MySQL/PHP 堆栈，因为我们的大部分工作都在该平台上。

从 PHP4 到 PHP5 的顺利迁移需要遵循哪些好的步骤。哪些类型的代码可能会被破坏？

有没有一种方法可以轻松地将 Crystal Reports 报表转换为 Reporting Services RDL 格式？我们有很多报告很快需要转换。

我知道手动过程（基本上是在 SSRS 中从头开始重建所有报告），但我的搜索指出了与几家咨询公司自动转换“加速”的一些可能性。（如 .... 所述 - 链接断开）。

你们中的任何人对这个特定问题有任何有效的经验或建议吗？周围有什么我不知道的工具吗？

我们目前正在将 MySQL 用于我们正在构建的产品，并且渴望尽快迁移到 PostgreSQL，主要是出于许可原因。

有没有其他人做过这样的举动？我们的数据库是应用程序的命脉，最终将存储 TB 的数据，所以我很想听听性能改进/损失的经验，转换 SQL 和存储过程的主要障碍等。

编辑：只是为了向那些询问我们为什么不喜欢 MySQL 许可的人澄清一下。我们正在开发一种商业产品，该产品（目前）依赖于 MySQL 作为数据库后端。他们的许可证规定我们需要向他们支付每次安装标价的一定百分比，而不是固定费用。作为一家初创公司，这并不吸引人。

有人知道将 SQLite3 数据库迁移到 MySQL 的快速简便方法吗？

我们正在 .NET 3.5 中重新设计我们网站的面向客户的部分。到目前为止进展顺利，我们使用相同的工作流和存储过程，在大多数情况下，最大的变化是 UI、ORM（从字典到 LINQ），当然还有语言。到目前为止，大多数页面都是微不足道的，但现在我们正在处理最繁重的工作流页面。

我们的报价接受部分的主页是 1500 行，其中大约 90% 是 ASP，可能还有另外 1000 行函数调用包含。我认为 1500 行也有点欺骗性，因为我们正在使用这样的宝石

到目前为止，我一直在使用的标准做法是花一个小时左右的时间阅读该应用程序，既要熟悉它，又要删除注释掉/弃用的代码。然后以深度优先的方式工作。我将从顶部开始，复制文件中的一段代码aspx.cs并开始重写，在我去的时候进行明显的重构，特别是为了利用我们的 ORM。如果我得到一个我们没有的函数调用，我会写出定义。

在我完成所有编码后，我将在重构/测试中进行几次传递。我只是想知道是否有人对如何使这个过程更容易/更有效有任何提示。

我需要添加到 .NET 2.0 网站的 web.config 以使其成为 .NET 3.5 的最低要求是多少？

Visual Studio 添加了所有配置部分和脚本处理程序，但如果您不使用它们，它们真的有必要吗？

是否有命令行工具可以将 .NET 2.0 web.config“升级”到 3.5？

推动新功能上线的最大风险可能在于新代码所需的数据库修改。在 Rails 中，我相信它们具有“迁移”功能，您可以在其中以编程方式对开发主机进行更改，然后将相同的更改与使用修改后的模式的代码一起进行。如果需要，以同步的方式回滚。

有没有人遇到过类似的 PHP/MySQL 工具集？很想听听它，或任何程序化或流程解决方案，以帮助降低风险......

源数据库相当大。目标数据库不会自动增长。它们在不同的机器上。

我来自 MS SQL Server，MySQL 背景和 IDS11 似乎过于复杂（我敢肯定，有充分的理由）。