早晨上微信，发现有好友请求提示，看头像是个美女，请求验证的信息是：“我是客服XXX，麻烦您通过一下。”以往这种情况我都是直接无视，因为这个验证请求明显不专业，专业的骗子都会说出自己的工作单位，比如“我是联通客服XXX…”

(图源 ：Pexels.com)

但是看在她头像是美女的份上，我决定提点她一下，于是回复：“是哪里的客服？”，结果她回了一条信息：“我是华泰证券客服，麻烦你通过下”。至此我100%确定她是个骗子了，因为证券公司客服都是通过客服电话服务的（或许我没够档次？），不过恰巧我也华泰开了户，不知道骗子是蒙正的还是做过功课。

于是通过了她的好友验证，打算看看有啥伎俩。开场白倒是很像是为客户考虑：“我是证券客服-XXX，大盘走势不是很好，特别提醒广大投资者多多关注，注意风险”。不过细一品味，这都都是废话嘛，谁不知道注意风险，不过这玩意注意就行嘛？这时候骗子已经开始给我下套了。

接下来骗子又问：“那您现在还持股吗？”如果是证券公司客服并且负责对应用户的，其实用户的资产都是一清二楚的，至少我在其它证券公司是这样的。我反问到：“你不是客服吗？持股与否应该可以查到啊？”然后骗子很机智地回复：“那你们还有隐私吗？”。不过骗子没有想到，人家查询是侵犯我隐私，你这么直白地问我就不要隐私啦？

(图源 ：Pexels.com)

不过我还是配合她把戏演下去，“有一点股票，没多投，就几百万吧”。哈哈，反正吹牛不担心被识破。骗子又问，“那您平时都是自己选股操作吗？”。“啊，我从来不操作，就放那扔着，反正也没多少钱！”。这牛吹的，我自己给自己一个满分。

这时骗子应该双眼冒星星，然后夸我“大哥，您有有钱”才对吧。结果骗子来了一句：“做长线还是被套了？” 我😡，你才被套了，你全家都被套了，气死我了，竟然不按套路出牌。我已经懒得搭理她了，于是回复：“长线”。

然后骗子的真面目冒了出来，估计也没时间和我闲扯、听我吹牛了（莫非骗子识破了我伎俩？）直接向我推荐分析师，什么方便交流沟通啊，什么帮我看我的股票啊，什么拼服务搭扣碑不收费啊，并直接把微信号分享了过来。

说了这么多无外乎以后想让我帮他们的股票抬轿或者骗我的钱。哼哼，做梦去吧，我哪有钱让你们去骗😭

(图源 ：Pexels.com)

哎，说不好是谁调戏了谁，况且这美女头像的背后没准就一和我一样的抠脚大汉呢，我是多么无聊和她/他扯半天！果断拉黑，还是写程序好玩，继续写程序去了，虽然我啥也没写出来，😭

This page is synchronized from the post: 调戏“美女”客服

因为要在一个程序中用到Access数据库，所以从头学了一系列的用程序操作Access数据库的东西。比如连接数据库、插入数据、查询数据、插入时间日期类型等等。终于程序可以用了，然后放到另外一台电脑上试一下， 不出所料，果然跑不起来，提示信息大概如无法连接数据源等等。

(图源 ：pixabay)

查看数据源

这其实是在我的意料之中的，因为我程序中使用的是64位的Microsoft Access Driver (*.mdb, *.accdb)，所以只有安装了对应数据源驱动的电脑才可以运行我的程序。

用户可以在Control Panel\All Control Panel Items\Administrative Tools路径下选择ODBC Data sources(64-bit)来查看数据源。

这个就是我这里看到的哦。

安装数据源

因为的电脑上装有Microsoft Office 2010 (64-bit)，安装的时候自动附带安装的上述数据源驱动。如果其它电脑上没有安装2007版本以后的Office或者安装的是32位版本，就无法使用我的程序喽。

当然了，一直方案是我Build出来一个32-bit版本的，连接32-bit的Microsoft Access Driver (*.mdb, *.accdb)，但是如果没有安装过Office的朋友同样会遇到问题，所以还是研究了一下如何安装。

Microsoft网站上提供Microsoft Office相关的一些软件以及Redistributable包。
https://www.microsoft.com/en-us/download/office.aspx

其中，Microsoft Access Database Engine 2016 Redistributable以及Microsoft Access Database Engine 2010 Redistributable 均包含有64位的ODBC、OLEDB驱动。

点击对应的链接（我当然是选新不选旧啦），选择AccessDatabaseEngine_X64.exe，按提示下载并安装即可。然后运行我的程序，一起OK了。

果断弃坑

尽管其实这段时间和Access打交道，觉得它也挺好玩的，但是我准备弃坑了，所以这篇文章的标题是使用Access数据库最后一个坑。

之后准备试试在程序中用SQLite玩，别了，Access！

相关链接

• Microsoft Access Database Engine 2016 Redistributable
• Microsoft Access Database Engine 2010 Redistributable
• 每天进步一点点：MFC中使用Access数据库
• 每天进步一点点：MFC中向Access 数据库插入数据
• 踩了Access数据库的两个坑，吐血中
• 每天进步一点点：向Access数据库中插入数据重复的问题
• 每天进步一点点：使用SQL语句在Access中插入日期时间类型数据

This page is synchronized from the post: 每天进步一点点：使用Access数据库最后一个坑（驱动）

昨天等了一整天，宽带也没恢复，LOS红灯一直闪啊闪啊，像是对我的嘲讽。联通给我预约昨天下午五点上门维修的师傅只是给我打了个电话，说是上游故障他们也没法解决云云，然后杳无音讯了。

(图源 ：pixabay)

于是今天早起继续报故障，联通继续重新派单，继续约时间，给我约到11:30。大概11：20左右，维修师傅打来电话，说外线他已经弄好了， 让我重启光纤猫试试，结果重启后故障依然，然后11:30，维修师傅拎着一大堆设备准时上门了。

我问既然是大面积故障，那应该是上游某处的问题，哪有故障修哪里就好了，怎么还需要上门呢？师傅说这事他们也纳闷呢，按说上游故障解决完毕，这边各家各户的网络就应该通畅了，结果还有好多家故障依然，上门检测发现都是各家的故障，只好逐一修复。

这就奇了怪哉，上游光纤故障能影响到终端？我表示不能理解，要说是打雷把光纤猫劈坏了，我还有可能相信。师傅说咱别研究理论了，直接上设备测试吧。

(实拍：熔接光纤的设备）

于是把光纤从我的光纤猫上拔了下来，测试了一下什么数值说是37，据说理想的范围是15-30，超出或者小于这个范围都会导致光纤猫无法调制解调光信号。总之，结论就是我家里光纤猫这一小段光路有问题。

于是大剪刀上去咔咔剪断，重新熔接光纤，结果一会提示折角过大，一会融好了一碰就折断了，折腾了半天，总算熔接好了，套上套管在用设备固定好，这回就不怕一碰就断了。然后接到光猫上，终于看到了久违的绿灯。

尽管我和师傅依旧对上游故障导致终端这边光路的问题表示不解，但是解决就好，不然4G流量马上就要超标了。师傅说不用纠结为什么了，事实上已经几十家他都重新熔接的光纤，要累吐血了。

(图源 ：pixabay)

在我测试上网表示一切正常之后，师傅拎起他的大箱子，急匆匆地走了， 说是还有无数家等待修复，可怜的师傅。😰

This page is synchronized from the post: 重新熔接光纤，宽带终于恢复啦

今天用一上午的时间写帖子，到下午一点多钟即将完工的时候却发现电脑断网了。我使用的是联通的100M光纤，偶尔也有断网的时候，一般等它个三两分钟会自动回复。

(图源 ：pixabay)

然而我等了N个三两分钟也没见网络自动恢复，只好用我的万能重启大法了。好在我所有的网络设备（光纤猫、路由器等）都在一个带按钮的插座上，一键重启。一般来讲重启总会解决我的问题的，然而我重启了N次以后，发现还是没能连上网。

莫非是我欠费了？不应该啊，我记得我这个月已经提前交的话费（捆绑宽带），不过为了确认我还是用宽带捆绑的电话拨了一下另外一部电话，一切正常。再用4G登陆网厅查询了一下，也没欠费。

于是只好电话报修了，接线员说从后台看我的网络一切正常，说派单给师傅，让师傅来查查，只好耐心等待喽。等待的间隙，我观察了一下光纤猫上的指示灯，发现LOS一直闪红灯。手机查了一下，这个代表的是光纤信号衰减厉害或者没有信号。如果不是猫坏了，就是外线问题。

(图源 ：pixabay)

等了大约一个多小时，维修师傅打来电话，告诉我不光我自己的网络故障，整个小区已经几十上百户报修了，之所以这个数量不是上千户，估计是因为有人上班没在家。问及原因，说是市内一段干线的光纤被挖掘机挖断了。

额，想起很久很久之前，经常能看到诸如光纤没有铜偷了也没用或者光缆一断损失百万类似的标语，现在回想起来，这干线光缆被挖断了，有形无形的损失应该不止百万了，毕竟现在大家都太依赖网络了。

强烈谴责这个开挖掘机的，一定不是蓝翔毕业的，没好好深造过就出来干活😡（开个玩笑）。不过话说这些乱七八糟的部门施工之前为啥不好好沟通一下呢？真愁人。

(图源 ：pixabay)

这都6、7小时了还没修好，真愁人，还好有4G可用，否则都不想活了。

This page is synchronized from the post: 光缆一断损失百万

在做小工具玩的时候，我需要使用程序在Access中插入日期时间类型数据，比如说steem上文章的创建日期。从steem读回的时间格式一般是这样的'created': '2018-05-20T02:42:00'，这是我昨天一篇文章的发布日期。

(图源 ：pixabay)

T的含义

以往我们都见惯了2018-05-20 02:42:00这样的日期时间串，那么这个中间的大写T有什么特别含义呢？在Microsoft网站找到双眼冒花也没找到和这个有关的内容，可能是我没找对地方，最后终于在W3C的网站中找到这样一篇文章Date and Time Formats，其中说到

Note that the “T” appears literally in the string, to indicate the beginning of the time element, as specified in ISO 8601.

原来就是把日期和时间放一起表示的时候用于分隔日期和时间的，吐血，害我找了半天。

插入时间日期

既然知道 T就是个分隔符，那么我来向Access表中插入日期啦。首先在表中加入created字段，类型设置为Date/Time。然后使用SQL尝试插入数据：

insert into test(created) values('2018-05-20T02:42:00');

不出意料的失败了。看手册中有一个CData函数，说是可以把字符串转换成时间日期类型，拿来试试

insert into test(created) values(CDate(‘2018-05-20T02:42:00’));

还是不行，我晕，它咋就不匹配呢？

Data type mismatch in criteria expression

既然都不行，我试试不要这个T呢？结果

insert into test(created) values('2018-05-20 02:42:00');
insert into test(created) values(CDate('2018-05-20 02:42:00'));

两条语句都可以正确插入时间日期，这期间和我还DateValue以及Format等函数各种较劲，无一例外地没能成功，其中的辛酸不足为外人道也。😭

解决

既然知道了问题所在，解决起来就好办多了，在程序中，我先把得到的时间日期中的T替换成空格，然后在传入SQL语句，之后无论是直接插入还是使用CDate转换后插入，都没什么问题。

不过我还是倾向于使用带CDate的插入语句，这样可以和数据库中字段类型对应。估摸直接插入时间字符串是Access自动处理的转换而已，具体情况就不深究了。

另外，虽然费了了些周折，走了些弯路，但是总算搞懂了T的含义，算是一点点收获吧。尽管这个T除了给我制造了一些麻烦没起啥作用。

参考链接

• Date and Time Formats
• ISO_8601
• Access Functions (by category)

This page is synchronized from the post: 每天进步一点点：使用SQL语句在Access中插入日期时间类型数据

因为要在程序中使用到文章的URL，所以调查了一下文章和回复的URL规则，并记录在此处备忘。

(图源 ：pixabay)

url 字段

在get_content等从区块链上获取文章的API调用中，结果中包含一个url字段。比如说下列调用：

{"jsonrpc": "2.0", "method": "call", "params": ["condenser_api", "get_content", ["oflyhigh", "esteem-surfer"]], "id": 1}

结果中包含如下url字段：

'url': '/surfer/@oflyhigh/esteem-surfer',

而读取我回复 @fr3eze 的内容

{"jsonrpc": "2.0", "method": "call", "params": ["condenser_api", "get_content", ["oflyhigh", "re-fr3eze-re-oflyhigh-esteem-surfer-20180520t054117176z"]], "id": 1}

结果中包含的url字段内容又变成了这个样子

'url': '/surfer/@oflyhigh/esteem-surfer#@oflyhigh/re-fr3eze-re-oflyhigh-esteem-surfer-20180520t054117176z',

代码

上述测试中读取主贴以及回复中的url都是如何得到的呢？

阅读condenser_api.cpp的代码，我们发现实际上get_content是tags_api.cpp
中get_discussion的简单映射。

继续看get_discussion的代码，里边调用了set_pending_payout( result );而这个函数在末尾又调用set_url( d );而set_url又做了什么呢？

答案很简单，就是生成上述规则的URL，和我们用API调用返回的一样。

另外一点就是上边代码中的category是咋来的

这段代码解释了这个问题。

效果

除了url以外，我还很关心steemit.com 上不同url的的显示效果。

文章的url不用说啦
https://steemit.com + url就会显示对应文章
比如：

https://steemit.com/surfer/@oflyhigh/esteem-surfer

回复也是如此，比如：

https://steemit.com/surfer/@oflyhigh/esteem-surfer#@oflyhigh/re-fr3eze-re-oflyhigh-esteem-surfer-20180520t054117176z

但是上述回复显示的是整篇正文加所有回复，然后定位到对应的回复并高亮显示。

如果文章超长回复超多，这样加载起来和看起来都不是很方便。

所以其实可以用另外一种url方式(https://steemit.com/ + category + permlink)

https://steemit.com/surfer/@oflyhigh/re-fr3eze-re-oflyhigh-esteem-surfer-20180520t054117176z

相比之下，我更喜欢第二种方式。

结论

对于主贴而言，url为： /category/@author/permlink 对于回复而言 url为 /root.category/@root.author/root.permlink#@author/permlink

而另外一种方式为 /category/@author/permlink ，亦即与主贴一样的规则。

知道了url生成规则以后，我们就可以自己按规则生成url了，无需使用从get_content等API中读回的url。讲真，我一直觉得这些API有时候会返回一些多余的重复数据，url就是一例。

This page is synchronized from the post: 记录一下steem上文章和回复的URL规则