Quickfix 1.13.3-使用ODBC存储在StartTime时SeqNum未正确重置

我使用的是用ODBC重新编译的quickfix 1.13.3，我的接受器上有一个奇怪的行为两个接受器在不同的机器上共享同一个ODBC数据库并启用热故障切换。 我的每日会话设置为：

RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y

以及必要的Odbc设置

在23:54，发起者发送一个注销消息，MsgSeqNum=1711，我的quickfix接受器用注销消息MsgSeqNum=1711进行响应，因此没有问题

在00:05:16，发起程序发送一个MsgSeqNum=2的登录，但我的quickfix接受器以Logout MsgSeqNum=1712响应

在00:05:18，发起程序在Logon和MsgSeqNum=4的情况下重试，这次，我的quickfix接受器以Logon-MsgSeqNum=1响应

考虑到可能在表会话中，传入和传出的_seqnum没有通过ODBC正确重置，我甚至尝试在00:00手动强制重置，但徒劳，我仍然得到相同的行为

目前我的猜测是，具有此配置的quickfix仍然与昨天会话的登录请求相匹配，从而导致使用昨天序列号注销

使用相同的StartTime、EndTime、1个接受程序（而不是2个）、FileStore和no RefreshOnLogon设置，因为我只有1个接受程序用于quickfix 1.12.4

我还尝试了RefreshOnLogon=N，但问题仍然是一样的。。。SeqNum在午夜未正确重置

有什么想法吗

---

非常感谢，

在多次尝试使用不同的设置之后，我终于回滚到使用ODBC重新编译的1.12.4。 使用相同的设置，旧库正常工作，SeqNum在00:02:00时正确重置

RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y

---

您的配置文件中是否设置了UseLocalTime？如果是这样，您应该注意QuickFIX在1.12.4之后将其破坏。打破它的版本是2160，正如我在这个bug上注意到的：

谢谢你的回答。我没有使用UseLocalTime，引擎在UTC上工作。QuickFIX确实在1.12.4之后破坏了很多东西。这个版本可能很旧，但它是一个很好的版本。1.13.3与会话开始和结束相关的bug比您发现的多——到目前为止，我自己也遇到过两个，其中一个在开发报告中修复。不好的。