楼主这水平要是才8、9K。。。那谁能拿2W？

下一个来学习一下～～
我也很喜欢做懒人～～偷懒不是每个人都会的，这个一定要学好。

不知道博主有没测试过？实际调用时会导致相应的方法被调用两次，第一次是EnhancedWebService中调用的；第二次是直接访问的。不知道有没办法避免重复执行？

引用

胡尐睿丶：
@Carrod
-0-正好和你相反，我最早是用jquery.validate.js，现在转用国人写的插件了。

之前也是贪国人写的比较了解国人需求～但用着用着也感觉不太爽。
jquery.validate.js刚用，也有点不爽了，特别是要占class，又必须name的。不过好在有一些辅助方法～

引用

胡尐睿丶：
@Carrod
是因为这个问题啊，看来习惯得养好。

呵呵，我现在改用jquery.validate.js了～

看到第2个问题就知道为什么压缩版会出错了，很多地方估计都没加分号～

整得挺漂亮的~~支持！

啥都不理，申请一份先~
carrod@foxmail.com

引用

红色壁虎：
楼主不是我打击你哦。
就凭你这个博文，我如果是tx hr，本来有你名单的，我说不定也会删你的哦。
当然我不是。

同意。心态很重要~~~
楼主加油，还年轻，慢慢调整状态~

其实最好就是不用html()返回值进行判断~
要不像下面这样——
<div id="user">
jack
<div>
hh</div>
</div>
trim也没办法保持各浏览器结果一致。

不一定是纯粹的message~...

引用：“卡通一下：
@Carrod
通过业务逻辑层来生成流水号并没有错，我的意思是对于基础数据的控制要慎重，呵呵！
说一个不是笑话的笑话吧！在早年使用SQL 2000时，出于安全的考虑，有些基础数据只能引用，而绝对不能修改(只有管理员才可以)。当然，你可以说通过权限设置来保证，但仍不放心。
最后，干脆就在这些基础数据表上建立触发器，无论对这些数据做任何修改，都将被自动回滚。哈哈...
”
呵呵，我基础数据也搞“通用”了，其实我觉得没什么特殊的东西就可以搞成“通用”，方便“通常使用”。
你说的情况好像我以前也弄过，也是用触发器在那防着。其实我觉得这个是管理不规范才比较容易出现的吧？

务需求简单的关系）。至于数据库内部嘛，那就还是看具体设计了，不一定就是拿流水号做主键的~~
多点瞎想也是好事，没准想想下就琢磨出个好东西了。...

not null, -- 流水号长度
SeqCycle int not null, -- 流水号周期
SeqNumberSystem int not null, -- 流水号制数
SeqFormat nvarchar(200) not null, -- 流水号格式
CurrentSeqString nvarchar(50) not null, -- 当前流水号字符串
LastReleaseTi

算是用触发器，也要进行并发控制，当然，这个博主那个存储过程里已经干了。这样的情况下使用触发器就基本上可以排除并发问题了。
我说的周期性，是指比如昨天流水号已经用到了100129100，到了新一天（今天）就从100130001开始，而不是100130101。类似这样的意思，满足一些业务需求，按小时、日、月、季度、年等周期生成流水号。...

引用

卡通一下：
我还是先说个场景吧，呵呵！
有一张表，用的是int自增主键，同时在记录中有一个字段，它是用“某种标识+日期+主键号”。这样，在添加记录成功后，便使触发器动作，自动生成这个字段的值。

了解了。就我说的业务提交时利用该表的触发器去生成流水号。
那么这个时候生成流水号仍旧需要去访问流水号的键值表，对吧？
还是说“某种标识+日期+主键号”这里的“主键号”即对应“int自增主键”？如果是的话，那么怎么保证周期性呢？
如果是使用博主的键值表生成流水号，我之前也说了，怎么用（包括什么时候用的意思），就只是各自业务自己需要处理的了。
不知道我有没理解错呢？

再想了一下，不知道你的意思是不是在业务处理提交时利用该表的触发器去获取新的流水号？...

引用

卡通一下：
@Silent Void
楼主，我到现在也没有看代码，只是跟着自己的感觉走，呵呵！
我的意思是，假如用的是一个“完整的时间”，那会不会出现在并发情况下，后提交的反而时间靠前？

你的意思是“2011-01-29 22:00:00.000”提交了“P110129002”，而“2011-01-29 22:00:10.999”时却提交了“P100129001”么？
如果必须严格要求先提交的流水号比后提交的靠前，那么自己的业务中肯定需要控制好并发，不可能在“通用”流水号中控制了。“我”已经按顺序给了你流水号，怎么用？那就是“你”的事了。