具有Firebird数据库的IBPP接口的经验

Question

我想问一下那些有Firebird和IBPP经验的人（特别是后者）。我找到了很多关于Firebird的正面帖子，但我有一个问题需要决定IBPP。界面本身干净简洁，但似乎项目没有太多活动（可能因为它非常稳定）。

• 您会推荐IBPP用于生产环境吗？
• 是线程安全吗？
• 任何已知的错误？

感谢。

Answer 1

IBPP非常稳定，我推荐它用于生产。也就是说，如果您打算将它用于常规应用程序。

如果你想构建一个管理工具或类似的东西，那么请准备好进入内部并弄脏你的手，因为不支持SQL但不改进API的一些新功能（即Firebird 2.5的东西）。例如，它缺少一个可以公开新跟踪API的层。

无论如何，继续我使用它。我有一堆IBPP应用程序正在生产多年，并且正如Douglas所写，FlameRobin正在使用IBPP，它可以完美地工作（至少就DB层而言）。

唯一需要注意的是NUMERIC字段，它们在Firebird内部存储为整数+比例。 IBPP通过C / C ++“double”暴露那些，但也通过16/32/64位整数。因此在检索此类值时要非常小心，因为您不会收到任何警告。例如，如果你有DECIMAL（18,2）字段，其值为254.00，并且你不小心将其读成一个整数，那么你将得到25400而不是254.确保你要么读取为double，要么稍后自己缩放。这很有用，因为你可以安全地将25400转换为字符串然后添加一个小数点，这样你就不会失去双精度（这完全取决于你的应用程序的类型和当然的数字）。

Answer 2

除了米兰提到的观点：

• 当连接到不同的数据库时，目前无法使用多个客户端库，甚至无法指定将使用哪个客户端库。有一些硬编码的客户端库位置序列被探测，找到的第一个将用于所有连接。改变这种情况的IBPP版本已被暗示很长一段时间，但尚未到来。 SVN trunk包含一些处理此问题的代码，但我最多会说这是alpha质量 所有这一切都适用于Windows，因为在所有其他平台上，Firebird客户端库无论如何都不会在运行时加载。

• 该库不是线程安全的。这在大多数情况下并不重要，因为您应该让每个线程都有自己的连接，事务和其他各种各样的对象。但是IBPP使用自己的智能指针实现，既不是完全异常安全也不是线程安全的。仍然，只要你从主线程初始化库（在创建任何其他线程之前）并在同一个线程中创建和销毁IBPP对象（所以绝对没有与其他线程共享对象！）在多个线程中使用IBPP应该工作细

• 如果您能够满足上述要点（对您来说可能无关紧要），它肯定可以用于生产。你可以随时更改遇到的事情，就像我们对FlameRobin所做的那样。

Answer 3

我无法从经验中得知，因为我从未使用过IBPP 但显然它被火焰神经项目使用，所以我相信它“足够稳定”。