文章采集调用(第二步，后台执行SQL语句SELECT(FROMdede)_)

　　文章采集调用(第二步，后台执行SQL语句SELECT(FROMdede)_)

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

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

　　观察以下数据：

　　pubdate：1231846313

　　senddate：1231846313

　　sortrank：1231846313

　　其中，1231846313为时间数据。

　　然后它被替换了。

　　UPDATE dede_archives SET sortrank = 1231846313;

　　UPDATE dede_archives SET senddate = 1231846313;

　　UPDATE dede_archives SET pubdate = 1231846313;

　　首先，你看到第一句话应该就可以通过他了。说一下他的方法的问题（注意：这种SQL语句或者需要修改数据库的，必须先备份）。

　　对应数据库的dede_archives表，请根据实际情况修改前缀。

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

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

　　senddate：存储时间

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

　　这一段说的没有错，我再详细说明一下：

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

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

　　2.senddate：存储时间

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

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

　　我们一般看不到这个时间，但是如果前端模板设置为“orderby='public'，系统会根据这个时间来调用。很多讲只是强调这些细节，而也算是一个原则吧。。

　　其次，我们应该明白，即使是优采云采集，或者dede采集，pubdate、senddate、sortrank这三个时间也不能完全一样，所以这里有点问题，但是这是无害的。重点是这个方案是修改整个系统的数据库pubdate、senddate、sortrank三个时间段，也就是说从你第一个文章发到最后一个，都变成你的修改现在这个时候，我第一次修改后，整个网站的文章就在3月19日发布了。可以说，几乎什么都搞砸了。这个大家应该都能理解。所以，我说备份很重要。 , 转载这个文章的人真是害人。我觉得这个方法不可取，完全没用。

　　二、1970 的正确解

　　优采云采集 发布时唯一不能出错的就是系统进入时间。因此，我们以此为标准，将public和sortrank时间改为senddate（语句下，先备份，后操作）。同时，经过对网站采集的更多考虑，有的文章的发布时间和存储时间有很大的区别吗？比如3-19采集有很多文章，发布审核，插件控制，每天自动更新，4-19才更新。如果执行两条命令，最近文章审核过的也会在3-19号放出，但是你可以选择只执行一条命令。 )

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

　　UPDATE dede_archives SET sortrank = senddate ;

　　该命令是将前台呼叫时间更改为存储时间。如果你是我上面提到的那种，就不要执行了。至于1970年会不会有其他影响，请自行考虑

　UPDATE dede_archives SET pubdate = senddate ;

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

　　上一篇：织梦DedecmsError: no csrf hash code的解决方法！在后台编辑模板时