采集 文章(第二步，后台执行SQL语句SELECT(dede)的问题)

　　采集 文章(第二步，后台执行SQL语句SELECT(dede)的问题)

　　第二步，后台执行SQL语句SELECT * FROM dede_archives order by id DESC limit 1

　　这样就可以看到刚才添加的所有字段值文章。

　　#p#Subtitle#e#观察以下数据：

　　发布日期：1231846313

　　发送日期：1231846313

　　排序：1231846313

　　其中，1231846313为时间数据。

　　然后是替换。

　　更新 dede_archives SET sortrank = 1231846313;

　　更新 dede_archives 设置发送日期 = 1231846313；

　　更新 dede_archives SET pubdate = 1231846313;

　　首先，当你看到第一句话时，你应该能够通过他。先说一下这个方法的问题（注意：如果执行sql语句或者需要修改数据库，必须先备份数据库）。

　　对应数据库的dede_archives表，请根据自己的实际情况替换前缀。

　　此表中有三个表示时间的字段：

　　pubdate：发布时间（可以在前台更改）

　　senddate：存储时间

　　sortrank：前台调用最新的文章。实际利用这个时间。

　　这一段没有问题，我会详细说：

　　1.pubdate：发布时间（可在前台更改）

　　在高级参数中可见，并且可以在发布新的 文章 或编辑 文章 时进行更改。也是系统在内容页和列表页上调用的时间。当发布时间为 1970 时，列表页面将显示 1970-01-01，从 文章 页面获取的发布时间为“尚未”。当然，这是基于 dede 默认模板。如果你修改它，它可能还有其他的结果。例如：我的待审核文章审核发布时会自动更新到当前系统时间（如果没有设置，见dedecms未审核文档自动更新发布时间）

　　2.senddate：存储时间

　　从字面意思可以理解，但是所谓的存储时间体现在哪里呢？是dede后台文件列表中的“进入时间”。理论上dede后台是不能修改的，但实际上可以通过sql语句修改，没有意义。如果你的文章命名规则是“{typedir}/{Y}/{M}{D}/{aid}.html”，也会在你的文章页面的url中直接提到.

　　3.sortrank：前台调用最新的文章。实际利用这个时间。

　　这个时间我们一般是看不到的，但是如果前端模板设置为“orderby='public'”，系统就会按照这个时间调用。我讲了很多就是为了强调这些细节，可以看作是一个原则。

　　其次要明白，即使是优采云采集，或者dede采集，pubdate、senddate、sortrank的3次也不可能完全一样，所以会出现一些问题到这里，不过也无妨，最后一点，这个方案就是修改整个系统的数据库pubdate、senddate和sortrank这三个时间段，也就是说从你发的第一个文章到最后一个，它会改变。现在是你修改的时间。经过我的第一次修改，整个网站的文章在3月19日发布，可以说几乎是一团糟。每个人都应该能够理解这一点。所以我说备份很重要，转载这个文章的人确实是很害人的。我不

　　二、1970的正确解法

　　优采云采集发布时唯一不能出错的是系统入口时间，所以我们以此为标准，将public和sortrank时间改为senddate（声明下，备份先操作，再操作）。同时，在网站采集的考虑下，部分文章的发布时间和入库时间是不是相差很大？比如3-19采集有很多文章，发布为待审，通过插件控制每天自动更新，4-19更新完成。如果你执行两条命令，那些最新审查的 文章 也会在 3-19 日发布，但你可以选择只执行一条命令。)

　　如果你不介意我上面说的，如果你真的需要解决1970的问题，在dede后台-system-sql命令行工具中，执行如下命令：

　　更新 dede_archives SET sortrank = senddate;

　　该命令是将前台的调用时间改为入库时间。如果您是我上面提到的那个，请不要执行它。至于1970会不会有其他影响，大家可以自行判断。

　　更新 dede_archives SET pubdate = senddate ;

　　这个命令是把发布时间改成存储时间，就不解释了。上面都说了。