我有一堆通过嵌入式 SQL 访问数据库（Oracle、DB2 和 Sybase）的 C 代码：基本代码是相同的，但是使用三种不同的预编译器，构建了三种可执行文件，每个数据库/平台一个。
我工作得很好，但我们现在需要迁移到使用 ODBC 访问的解决方案。
问题是：可以使用哪些工具/api？一种直接的方法似乎是编写自定义预编译器（或修改现有的）来包装所有 SQL 和主机变量调用，以调用 ODBC 连接。
有人可以推荐用于该任务的工具或 api 以使其保持简单吗？
或者它是一种更简单的方法，另一种方法？
谢谢
【问题讨论】：
标签： sql migration odbc legacy embedded-database
对于此类情况，通常没有现成的答案；人们的代码库中总是有许多惊喜，而这种组合使 COT 工具无法在个别情况下变得经济。
您想要的是一个program transformation system (PTS)，它带有一个 C 前端，可以定制以解析嵌入式 SQL。此类工具可以应用源到源重写规则（“如果你看到 this 模式，则将其替换为 that 模式”）来解决问题。
这些工具需要一些技术上的努力来配置。在您的情况下，您必须调整 C 前端来处理嵌入式 SQL；这通常不在 C 解析器中。 （如何以当前形式处理这些东西？）C 预处理器会有问题，因为人们用它做滥用的事情，这确实违反了解析器对宇宙的嵌套结构视图。然后你必须编写和测试规则。
这项工作是一种沉没成本，可以与手工完成工作或一些更临时的脚本（例如 Perl）的工作进行交易，后者部分完成工作，让您清理它。我们的经验是，低于 100K SLOC 的麻烦是不值得的，超过 1M SLOC 您没有机会进行手动/临时修复，并且您的里程会有所不同。
在这些中等大小的情况下，您可以为权衡取舍而苦恼；这也需要精力和时间。有时，最好还是硬着头皮做任何可以清理的事情。
我们的 DMS 软件再造工具包就是这些 PTS 之一。它有一个可定制的 C 解析器和预处理器，正是为了帮助处理这些配置问题。我相信，维基百科文章中提到的其他 PTS 没有任何与它们相关的严重 C 解析器。 （我是 DMS 背后的人）。
【讨论】：