在我目前的工作中，我们正在寻求实现自己的odbc驱动程序，以允许许多不同的应用程序能够作为数据源连接到我们自己的应用程序。现在，我们正在尝试权衡根据规模庞大的实现规范来开发自己的驱动程序的选择，或者尝试使用允许程序员“填写”数据特定部分并允许更高级别抽象的SDK。
是否还有其他人实现了自定义odbc驱动程序？您遇到了什么陷阱？您自己做得到了什么好处？您大概需要多少工时？您是否使用了SDK，如果这样，您从该方法中看到了什么好处/缺点？
任何意见和答案将不胜感激。谢谢!
编辑:我们正在尝试使用C语言编写的代码保持可移植性。
最佳答案
我还没有，但是我曾经在一家做到了这一点的公司接受过采访。他们做了
一种称为AMPS的4GL / DBMS产品，与MUMPS具有相同的体系结构-一种集成了4GL的层次数据库(这类系统的完整类型在1970年代问世)。他们有相当大的遗留代码库，客户希望使用MS Access连接到它。
采访我的首席开发人员分享了一些与此有关的 war 故事。显然，这样做非常痛苦，不应该掉以轻心。但是，他们实际上确实成功地实现了它。
一种替代方法是提供一个数据集市/ BI产品(沿着SAP BW)，该产品将您的应用程序数据显示在外部数据库中，并将其按星型或雪花模式等更友好的格式显示。
这将遭受不支持实时访问的困扰，但与ODBC驱动程序相比，它可能更易于实现(更重要的是维护)。如果您的实时访问要求是合理可预测且受限制的，则可以公开一个Web服务API来支持这些要求。