为啥我从Access数据库输出来的时间插入到SQL server 数据库后 2015.08.30 01:33:45 时间01就变1了

Posted 2023-05-10

为什么我从Access数据库读取出来的时间插入到SQL server 数据库后 2015.08.30 01:33:45 时间01就变1了 只有零点的会这样 数据类型是datetime的
我是菜鸟 下面是用D7写的 我必须要用固定的时间格式 下面是想从 access数据库中读取Value:=ADOQuery1.FieldByName('ShiJian').asstring;字段插入到SQL server 数据库ADOQuery2.Parameters.ParamByName('Ruhuitime') 现在access数据库中的时间字段是‘2015.08.30 01:33:45’到时插入到SQL中就变2015.08.30 1:33:45
我应该怎么才能实现一样呢
ADOQuery2.SQL.Add('insert into Huiyuan(ID,,Ruhuitime,address,city,Kano);
ADOQUERY2.SQL.Add('values(:ID,:RuhuiTime,:Address,:city,:Kano) ; ADOQuery2.Parameters.ParamByName('Ruhuitime').Value:=ADOQuery1.FieldByName('ShiJian').asstring;

这并没有什么关系。
SQL数据库主要功能是用来管理数据的，只要它存的数据正确即可。

当你以日期的格式定义了SQL的一个表的某字段时，你不必过于关心MS SQL在它的界面里查出来的日期的表现型式，实要关心它保存的数据对不对就可以了。比如时间：2015.08.30 01:33:45，它在SQL数据库里如果以日期类型来定义保存它的字段的话，显示出来一般是
“2015.8.30 1:33:45”，甚至是“2015/08/30 1:33:45”，也可能是别的形式，只要时间是对的就可以了。

至于你要让它按你的方式表现，那是前台程序的事了，一般来说，我们不会用MS SQL自带的管理器来直接使用SQL数据库，它只负责后面的事，就象一个专业仓库，它不执行对外展示和销售的责任。当前台程序从它那儿取到这个日期之后，前台再按需要的形式表现出来。比如用Delphi写的数据库管理软件，从SQL后台取到这个数据后，以你想要的格式显示。

如果你非得让它按你的想法保存，那你可以考虑先转换成字符串形式，把它当成一串字符存入SQL数据库中。 参考技术A SQL数据库里存储时间时小时是用1-24来表示，不会用01这种方式，你若需要使用这种方式可以这样做：
convert(varchar(19),时间列,120) as 新时间列

为啥我从对等端接收的数据与预期输出不匹配？

【中文标题】为啥我从对等端接收的数据与预期输出不匹配？

【英文标题】：Why doesn't the data I'm receiving from a peer match the expected output?为什么我从对等端接收的数据与预期输出不匹配？

【发布时间】：2011-09-18 17:07:22

【问题描述】：

在业余时间，我一直致力于用 C 语言实现一个 BitTorrent 客户端。目前它与跟踪器通信，连接到 swarm，从对等点请求 torrent 文件的片段，并接收 torrent 文件的片段。但是，在验证接收到的片段是否正确时（通过获取 SHA1 哈希并将其与 .torrent 元数据中提供的哈希进行比较），它总是失败。

为了调试它，我用一个已知工作的 BitTorrent 客户端下载了一个 torrent，然后修改了我自己的 BitTorrent 实现，只请求和下载 torrent 的开头（第一部分）。然后我将这两个文件与 Emacs 的 hexl-mode 进行了比较。

众所周知的：

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
00008000: 0143 4430 3031 0100 4c49 4e55 5820 2020  .CD001..LINUX   
00008010: 2020 2020 2020 2020 2020 2020 2020 2020                  
00008020: 2020 2020 2020 2020 5562 756e 7475 2031          Ubuntu 1
00008030: 312e 3034 2069 3338 3620 2020 2020 2020  1.04 i386

我的实现：

00000000: a616 f132 7f00 0080 5066 0000 0000 0080  ...2....Pf......
00000010: 5066 0000 0000 0060 3b62 0000 0000 0098  Pf.....`;b......
00000020: 3b62 0000 0000 00d0 3b62 0000 0000 0008  ;b......;b......
00000030: 3c62 0000 0000 0040 3c62 0000 0000 0078  <b.....@<b.....x
00000040: 3c62 0000 0000 00b0 3c62 0000 0000 00e8  <b......<b......
00000050: 3c62 0000 0000 0020 3d62 0000 0000 0058  <b..... =b.....X
00000060: 3d62 0000 0000 0090 3d62 0000 0000 00c8  =b......=b......
00000070: 3d62 0000 0000 0000 3e62 0000 0000 0038  =b......>b.....8
...
0000d000: 0243 4430 3031 0100 004c 0049 004e 0055  .CD001...L.I.N.U
0000d010: 0058 0020 0020 0020 0020 0020 0020 0020  .X. . . . . . . 
0000d020: 0020 0020 0020 0020 0055 0062 0075 006e  . . . . .U.b.u.n
0000d030: 0074 0075 0020 0031 0031 002e 0030 0034  .t.u. .1.1...0.4
0000d040: 0020 0069 0033 0038 0000 0000 0000 0000  . .i.3.8........

然后，我认为我必须将接收到的片段写入错误的偏移量，从而导致正确的数据出现在文件中的错误位置。为了验证这一点，我启动了 gdb 并在从对等点接收到第一个片段后检查了它的开头，期望它包含全零，就像已知良好文件的开头一样。

(gdb) break network.c:40
Breakpoint 1 at 0x402fe7: file network.c, line 40.
(gdb) run
Starting program: /home/robb/slug/slug 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffcb58d700 (LWP 12936)]
[Thread 0x7fffcb58d700 (LWP 12936) exited]
ANNOUNCE: 50 peers.
CONNECTED: 62.245.41.28
CONNECTED: 89.178.142.45
CONNECTED: 66.65.166.17
...
UNCHOKE: 95.26.0.1
Requested piece 0 from peer 95.26.0.1.
UNCHOKE: 202.231.116.163
PIECE: #0 from 95.26.0.1

Breakpoint 1, handle_piece (p=0x42d7e0) at network.c:41
41       memcpy(p->torrent->mmap + length, &p->message[9], REQUEST_LENGTH);
(gdb) p off
$1 = 0
(gdb) p index
$2 = 0
(gdb) p p->message[9]
$3 = 46 '.'
(gdb) p p->message[10]
$4 = 67 'C'
(gdb) p p->message[11]
$5 = 0 '\000'
(gdb) p p->message[12]
$6 = 0 '\000'
(gdb) p p->message[13]
$7 = 0 '\000'
(gdb) p p->message[14]
$8 = 0 '\000'
(gdb) p p->message[15]
$9 = 0 '\000'
(gdb) p p->message[16]
$10 = 128 '\200'
(gdb) p p->message[17]
$11 = 46 '.'
(gdb) p p->message[18]
$12 = 67 'C'

如您所见，我从对等方收到的数据并不像 known-good 文件的开头那样包含全零。为什么？

我的程序的完整源代码可在https://github.com/robertseaton/slug 获得。

【问题讨论】：

这有点大，这里有人给你调试。您不能将代码简化为网络 IO（如果这就是问题所在？）。您是否在 bufferevent_read() 调用后立即进行了调试，因为这是您收到的内容，而您的代码没有任何其他更改。您是否验证了用于调用它的参数？当 network.c get_msg() 第 55 行 bufferevent_read() 失败时会发生什么？它返回-1吗？这可能就是为什么你的“LINUX”字符串字节都被加宽了。还有 network.c read_prefix() 第 78 行，您正在阅读 &p->message_length - 对吗？

不清楚您是如何接收数据的。您是否考虑了小端和大端编码。互联网协议总是以大端编码传输数据。

您似乎同时拥有 64 位位域（“global_bitfield）和 8 位位域（主要是时间），都只使用了一位。您还有 8 位位域，所有位都被使用了。我假设协议在消息中使用了它可以使用的所有位，但是为什么在收到它们时将它们分散开来？如果我错了，请纠正我。

64 位的 global_bitfield 保存了所有位域的组合信息，因此可能会使用超过 1 位。我在接收位域时展开位域的原因只是为了让我可以通过使用数组寻址轻松检查是否设置了位。我将来可能会改变这一点。

【参考方案1】：

这没有考虑到 bufferevent_read 可能会失败并返回负数：

void get_msg (struct bufferevent* bufev, struct Peer* p)

     uint64_t amount_read = p->message_length - p->amount_pending;
     int64_t message_length = bufferevent_read(bufev, &p->message[amount_read],  p->amount_pending);

替换为：

void get_msg (struct bufferevent* bufev, struct Peer* p)

 uint64_t amount_read = p->message_length - p->amount_pending;
 int64_t message_length = bufferevent_read(bufev, &p->message[amount_read], p->amount_pending);

 /* possible bufferevent_read found nothing */
 if (message_length < 0)
      message_length = 0;

【讨论】：

我想你的意思是 if(message_length

【参考方案2】：

阅读我在network.c中找到的源代码：

memcpy(&index, &p->message[1], sizeof(index));
memcpy(&off, &p->message[5], sizeof(off));

index = ntohl(index);
off = ntohl(off);
length = index * p->torrent->piece_length + off;

#ifdef DEBUG
if (off == 0)
   printf("PIECE: #%d from %s\n", index, inet_ntoa(p->addr.sin_addr));
#endif

memcpy(p->torrent->mmap + length, &p->message[9], REQUEST_LENGTH);
p->torrent->pieces[index].amount_downloaded += REQUEST_LENGTH;

我认为最后两行是：

memcpy(p->torrent->mmap + length, &p->message[9], length);
p->torrent->pieces[index].amount_downloaded += length;

顺便说一句，REQUEST_LENGTH = 16K。 更有可能这个“长度的东西”应该是 p->message_length，或者 (p->message_length - 9)

另一个 bug 可能是 strlen()+1 类型的 bug。