2018-01-05 记录

错误排查与弹窗处理技巧
本文分享了一套实用的错误排查步骤,并介绍了一个通用的弹窗提示方法,该方法通过在BaseContral中添加一个Tips方法来简化前端与后台交互时的提示信息处理流程。

一、错误排查步骤

1.排查错误之前请先默念三声:微软老大万岁! 坚定一个信念:微软是不会错的,如果错了,那肯定是我的代码写的有问题。不要产生一些质疑微软产品的念头,而是将目光转向代码,按照清晰的思路去慢慢排查。

2.如果最后全部都排查完了,仍然没有找到错误的原因,那就回头看看,哪些你认为一定不会出错的代码,或者你无法明确看到运行结果是正确的代码,这些需要重点检查下,很多时候,都是你认为他绝对不会错的东西,

但他就是错的。

 

 

二、一点经验之谈

工作中经常会用到弹窗提示。一般的做法是:后台返回result,前台对这个result判断,成功,则Do A,失败则弹窗 Do B。

弹窗在前台和后台交互时使用非常频繁且必须,于是,干脆就在BaseContral加个方法,所有的弹窗都直接调用这个方法,

方法里做这些处理:

[NonAction]
protected void Tips(string content, MessageType type = MessageType.Warning, int showTime = 3000)
{
  TempData["sysytem_message_icon"] = ((int)type).ToString();
  TempData["sysytem_message_content"] = content;
  TempData["sysytem_message_showTime"] = showTime.ToString();
}

前台

MATLAB主动噪声和振动控制算法——对较大的次级路径变化具有鲁棒性内容概要:本文主要介绍了一种在MATLAB环境下实现的主动噪声和振动控制算法,该算法针对较大的次级路径变化具有较强的鲁棒性。文中详细阐述了算法的设计原理与实现方法,重点解决了传统控制系统中因次级路径动态变化导致性能下降的问题。通过引入自适应机制和鲁棒控制策略,提升了系统在复杂环境下的稳定性和控制精度,适用于需要高精度噪声与振动抑制的实际工程场景。此外,文档还列举了多个MATLAB仿真实例及相关科研技术服务内容,涵盖信号处理、智能优化、机器学习等多个交叉领域。; 适合人群:具备一定MATLAB编程基础和控制系统理论知识的科研人员及工程技术人员,尤其适合从事噪声与振动控制、信号处理、自动化等相关领域的研究生和工程师。; 使用场景及目标:①应用于汽车、航空航天、精密仪器等对噪声和振动敏感的工业领域;②用于提升现有主动控制系统对参数变化的适应能力;③为相关科研项目提供算法验证与仿真平台支持; 阅读建议:建议读者结合提供的MATLAB代码进行仿真实验,深入理解算法在不同次级路径条件下的响应特性,并可通过调整控制参数进一步探究其鲁棒性边界。同时可参考文档中列出的相关技术案例拓展应用场景。
<think>我们有一个表,记录每个运单在网点的到达时间和离开时间。需要统计在2018-03-01 13:00到2018-03-01 15:00之间,在该网点有停留(即离开时间不等于到达时间)的运单数。 注意:停留意味着离开时间不等于到达时间。同时,我们要统计的是在这个时间区间内(2018-03-01 13:00到15:00)有停留的运单。注意,这里的时间区间指的是停留发生的时间区间,即停留事件必须有一部分落在这个时间区间内。 如何理解“在2018-03-01 13:00到2018-03-01 15:00之间在该网点有停留”? 停留事件的发生时间实际上是一个时间段(从到达时间到离开时间)。我们要求这个时间段与[2018-03-01 13:00, 2018-03-01 15:00)有重叠。 因此,条件为:到达时间 < 离开时间(即有停留)并且停留时间段与查询时间段有交集。 停留时间段与查询时间段有交集的条件是: - 停留时间段的开始(到达时间)小于查询时间段的结束(15:00)且停留时间段的结束(离开时间)大于查询时间段的开始(13:00) 即:到达时间 < '2018-03-01 15:00' AND 离开时间 > '2018-03-01 13:00' 另外,我们还要确保离开时间不等于到达时间,即停留事件成立。 因此,SQL语句可以这样写(假设表名为`express`,到达时间列为`arrival_time`,离开时间列为`departure_time`): ```sql SELECT COUNT(DISTINCT shipment_id) AS count FROM express WHERE arrival_time < departure_time -- 确保有停留 AND arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` 解释: 1. `arrival_time < departure_time` 确保该运单在这个网点有停留(停留时间大于0)。 2. `arrival_time < '2018-03-01 15:00'` 表示运单的到达时间必须在15:00之前(否则停留事件从15:00之后才开始,就不在时间段内)。 3. `departure_time > '2018-03-01 13:00'` 表示运单的离开时间必须在13:00之后(否则停留事件在13:00之前就结束了,也不在时间段内)。 注意:这里使用`COUNT(DISTINCT shipment_id)`来避免同一个运单多次出现在该网点(虽然一个运单在一个网点通常只有一条记录,但为了严谨)或者如果有重复记录的情况。 如果表中一个运单在同一个网点可能有多条记录(例如多次进出),则要根据业务逻辑判断,但根据问题描述,一个运单在一个网点的到达和离开应该是一次性记录。 如果表中的记录是一个运单在网点的完整停留记录(即一次到达和一次离开),那么我们可以直接使用上述条件。 另外,注意时间格式,确保比较的时间格式一致。这里的时间字符串是'2018-03-01 13:00'和'2018-03-01 15:00'。 如果时间列包含时区,可能需要转换,但问题中没有提到,所以按无时区处理。 因此,最终答案就是通过上述SQL查询得到结果。 注意:这里统计的是停留事件与查询时间段有重叠的运单数。也就是说,只要运单在网点的停留时间段有一部分落在查询时间段内,就统计在内。 例如: - 运单在12:50到达,13:10离开:停留时间段[12:50,13:10]与[13:00,15:00]在13:00到13:10有重叠,所以统计。 - 运单在14:50到达,15:10离开:与查询时间段在14:50到15:00有重叠,所以统计。 - 运单在12:50到达,12:55离开:整个停留时间段都在13:00之前,不统计。 - 运单在15:00到达,15:10离开:到达时间等于15:00,但是我们的条件是离开时间大于13:00且到达时间小于15:00?注意到达时间15:00不小于15:00(除非是严格小于,而15:00等于15:00,所以不满足条件)。因此不会统计。 但是,这里有一个边界问题:如果停留事件刚好在13:00开始,或者在15:00结束,是否包括? 根据条件: - 到达时间 < '2018-03-01 15:00':所以到达时间如果是15:00,则不满足(因为15:00不小于15:00)。同样,到达时间如果是13:00,满足(13:00<15:00)。 - 离开时间 > '2018-03-01 13:00':所以离开时间如果是13:00,则不满足(因为13:00不大于13:00)。离开时间如果是15:00,满足(15:00>13:00)吗?但是注意,离开时间如果是15:00,那么到达时间必须小于15:00(例如14:50),这样条件都满足,就会被统计。 所以,对于边界: - 如果停留事件在13:00开始,在13:30离开:到达时间为13:00,满足到达时间<15:00(13:00<15:00),离开时间13:30>13:00,满足。 - 如果停留事件在14:30开始,在15:00离开:到达时间14:30<15:00,离开时间15:00>13:00(因为15:00大于13:00),满足。 但是,如果停留事件在15:00开始,则到达时间为15:00,不满足arrival_time < '2018-03-01 15:00'(因为等于),所以不统计。 同样,如果停留事件在13:00结束,则离开时间等于13:00,不满足departure_time > '2018-03-01 13:00'(因为等于),所以不统计。 因此,边界条件为:左闭右开?实际上,我们统计的是停留时间段与开区间(13:00, 15:00)有重叠?不对,我们使用的是大于和小于,所以实际上是: - 停留时间段的开始时间(到达时间)必须小于15:00(即15:00及以后到达的不算) - 停留时间段的结束时间(离开时间)必须大于13:00(即13:00及之前离开的不算) 这样,停留时间段必须与(13:00, 15:00)有重叠部分。注意,由于时间段是连续的,所以即使停留事件在13:00开始,因为到达时间等于13:00,但离开时间大于13:00,所以实际上停留事件在13:00这个时间点之后还有一段时间,所以与[13:00,15:00)有重叠?但是我们的条件只要求离开时间大于13:00,到达时间小于15:00,所以实际上覆盖了[13:00, 15:00]这个闭区间内的所有停留事件?不对,因为: - 到达时间小于15:00(包括13:00,14:59:59等),离开时间大于13:00(包括13:00:01,15:00等)。 但是,如果我们想要包括在13:00开始停留的运单(到达时间为13:00)和直到15:00才离开的运单(离开时间为15:00),那么我们的条件已经包括了: - 到达时间13:00:小于15:00(成立),离开时间大于13:00(假设离开时间是13:00:01,则大于13:00,成立;但是注意,离开时间不能等于13:00,等于则不满足)。 - 同样,离开时间15:00:大于13:00(成立),到达时间小于15:00(成立)。 所以,我们实际上包括了: - 到达时间在13:00之后(大于等于13:00)且小于15:00,并且离开时间大于13:00(且可以等于15:00吗?但是离开时间等于15:00是大于13:00的,所以可以)的停留事件。 但是,如果我们有一个停留事件:到达时间12:30,离开时间13:00。则: - 到达时间12:30 < 15:00 (满足) - 离开时间13:00 > 13:00?注意,13:00>13:00是不成立的(因为等于),所以不满足。 因此,这个停留事件没有被包括。这符合我们的要求吗? 这个停留事件在13:00结束,所以它在13:00这个时间点已经离开了。也就是说,在13:00这个时间点,它已经不在网点了。那么在整个查询时间段[13:00,15:00]内,它并没有停留(因为它在13:00时已经离开)。所以不应该包括。 同理,如果在13:00到达,13:00离开(即瞬间离开),那么停留时间为0,但是我们的条件中要求`arrival_time < departure_time`,所以这种瞬间离开的记录会被排除(因为到达时间等于离开时间,不满足停留条件)。 所以,这个SQL满足需求。 总结:使用上述SQL语句即可。 另外,如果表中一个运单在同一个网点有多次停留记录(比如一个运单先到达,然后离开,然后又再次到达),那么我们需要分别统计每一次停留,但是注意,同一个运单可能被计数多次(因为同一个运单可能有多次停留事件落在该时间段内)。而问题要求的是“运单数”,即有多少个运单(而不是多少次停留事件)。所以应该使用`COUNT(DISTINCT shipment_id)`。 如果表结构中没有运单号(shipment_id)字段,那么需要根据实际情况调整,比如使用主键或者其他唯一标识。但问题描述中没有给出表结构,我们假设有运单号字段。 因此,最终SQL如下: ```sql SELECT COUNT(DISTINCT shipment_id) FROM express WHERE arrival_time < departure_time AND arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` 注意:如果时间字段的类型是字符串,那么需要用函数转换为时间类型,或者确保字符串比较是按时间顺序(例如格式为'YYYY-MM-DD HH:MM:SS'的字符串可以直接比较)。如果已经是时间类型(如datetime或timestamp),则可以直接比较。 如果数据库存储的是时间戳,同样可以直接比较。 所以,在编写SQL时需要确保时间格式一致。 如果用户需要更精确(比如包含毫秒),但问题中时间只精确到分钟,所以用这个格式即可。 此外,如果查询的时间区间非常大,可以考虑在arrival_time和departure_time上建立索引以加快查询速度。 以上即为统计方法。 </think>### 统计网点停留运单的方法 要统计在 **2018-03-01 13:00 到 2018-03-01 15:00** 期间网点内有停留的运单数(即离开时间 ≠ 到达时间),可通过以下 SQL 查询实现(假设表名为 `express_log`): ```sql SELECT COUNT(DISTINCT shipment_id) AS stayed_shipments FROM express_log WHERE -- 停留条件:到达时间 ≠ 离开时间 arrival_time <> departure_time AND -- 停留时间段与目标区间[13:00,15:00]存在重叠 arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` #### 关键逻辑说明: 1. **停留判定** `arrival_time <> departure_time` 确保运单在网点有实际停留(非即时转出)。 2. **时间区间覆盖** - `arrival_time < '2018-03-01 15:00'`:运单在 **15:00 前已到达** - `departure_time > '2018-03-01 13:00'`:运单在 **13:00 后仍未离开** 满足这两个条件时,运单的停留时间段必然与目标区间 `[13:00, 15:00]` 存在重叠[^1]。 3. **去重计数** `COUNT(DISTINCT shipment_id)` 防止同一运单多次进出网点导致的重复统计。 #### 示例场景验证: | 运单 | 到达时间 | 离开时间 | 是否统计 | 原因 | |------|--------------------|--------------------|----------|-------------------------------| | A | 12:50(13:00前) | 13:30(13:00后) | ✓ | 停留覆盖 13:00-13:30 | | B | 14:30 | 15:15(15:00后) | ✓ | 停留覆盖 14:30-15:00 | | C | 12:00 | 12:50(13:00前) | ✗ | 停留全程在 13:00 前结束 | | D | 15:05 | 15:30 | ✗ | 停留全程在 15:00 后开始 | | E | 13:00 | 13:00 | ✗ | 无停留(到达即离开) | > ⚠️ **注意**:若数据库时间字段包含时区或非标准格式,需先用函数转换(如 MySQL 的 `STR_TO_DATE()`)。 ***
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值