OCIDate 在进入 Oracle 的道路上遭遇重创

发布于 2024-11-05 15:52:48 字数 1152 浏览 1 评论 0原文

我有一些 C 代码来填充纪元时间的 OCIDate

在我的主程序中:

OCIDate ocidate;
epoch_to_ocidate(c.f, &ocidate);

在库中:

void epoch_to_ocidate(double d, OCIDate* ocidate) {
  time_t t = (time_t)d;
  struct tm *ut = localtime(&t); /* convert to a Unix time */

  OCIDateSetDate(ocidate, ut->tm_year + 1900, ut->tm_mon + 1, ut->tm_mday); 
  OCIDateSetTime(ocidate, ut->tm_hour + 1, ut->tm_min + 1, ut->tm_sec + 1);
}

我非常确定这是正确的,因为我在调用例程中进行了检查:

#ifdef DEBUG
    char* fmt = "DD-MON-YYYY HH24:MI:SS";
    ub4 dbufsize=255;
    debug("testing converted OCIDate:");
    OCIDateToText(h.err, (const OCIDate*)&ocidate, (text*)fmt, (ub1)strlen(fmt), (text*)0, (ub4)0, &dbufsize, (text*)dbuf);
    debug(dbuf);
#endif

并且我将其绑定为:(

OCIBindByPos(s, &bh, h.err, (ub4)p, (dvoid*)&ocidate, (sb4)sizeof(ocidate), SQLT_ODT, 0, 0, 0, 0, 0, OCI_DEFAULT);

dbuf 已定义)。这正是我所期望的。但当它到达 Oracle 时,它​​是乱码,导致出现无意义的日期(例如 65-JULY-7896 52:69:0 或 ORA-1858 或 ORA-1801)。以前有人见过这样的事情吗?谢谢!

I have some C code to populate an OCIDate from the epoch time:

In my main program:

OCIDate ocidate;
epoch_to_ocidate(c.f, &ocidate);

And in a library:

void epoch_to_ocidate(double d, OCIDate* ocidate) {
  time_t t = (time_t)d;
  struct tm *ut = localtime(&t); /* convert to a Unix time */

  OCIDateSetDate(ocidate, ut->tm_year + 1900, ut->tm_mon + 1, ut->tm_mday); 
  OCIDateSetTime(ocidate, ut->tm_hour + 1, ut->tm_min + 1, ut->tm_sec + 1);
}

I am pretty certain this is correct, because I have a check in the calling routine:

#ifdef DEBUG
    char* fmt = "DD-MON-YYYY HH24:MI:SS";
    ub4 dbufsize=255;
    debug("testing converted OCIDate:");
    OCIDateToText(h.err, (const OCIDate*)&ocidate, (text*)fmt, (ub1)strlen(fmt), (text*)0, (ub4)0, &dbufsize, (text*)dbuf);
    debug(dbuf);
#endif

And I am binding it with:

OCIBindByPos(s, &bh, h.err, (ub4)p, (dvoid*)&ocidate, (sb4)sizeof(ocidate), SQLT_ODT, 0, 0, 0, 0, 0, OCI_DEFAULT);

(dbuf is already defined). And that displays exactly what I would expect. But when it arrives in Oracle it's gibberish, resulting either in a nonsensical date (e.g. 65-JULY-7896 52:69:0 or a either ORA-1858 or ORA-1801). Has anyone seen anything like this before? Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

天邊彩虹 2024-11-12 15:52:48

解决了 - 问题是 ocidate 是堆栈分配的,并且绑定不会将值复制到绑定句柄中,它只是设置一个指针,因此当它超出范围时,它可能会指向对任何事情。所以我改为堆分配它。现在我当然必须记账,但我想这很简单。干杯!

Solved it - the problem was that ocidate was stack allocated, and binding doesn't copy the value into the bindhandle, it merely sets a pointer, so when it went out of scope, that could have been pointing to anything. So I heap-allocated it instead. Now of course I have to bookkeep it, but I guess that's straightforward enough. Cheers!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文