SQL日期时间不能早于1753年
SQL日期时间不能早于1753年
1.公元元年的第一天，也就是公元1年1月1日，那天是星期六。
2.
现行的公历是格利戈里历法，这个历法并不是连续的，中间缺少了11天。1752年9月2日的后一天并不是9月3日，而是9月14日。也就是说，从1752年9月3日到9月13日的11天并不存在。
3.抹掉这11天是由英国议会在1752年做出的决定。（详情见如下
“历史的空白”
）
……
微软和Sybase两大公司决定不允许在各自数据库的日期型数据早于1753年
，如果想使用早于1753年的日期，就不能用日期型格式，得想别的法子。
---------------------------------------------------------------------------------------------------------
历史的空白：1582年10月5日至10月14日（英国：1752年9月3日至13日）
在现在通行的历法记载上，全世界居然有十天没有任何人出生过，也没有任何人死亡过，也没有发生过大大小小值得纪念的人或事。这就是1582年10月5日至10月14日
持续时间为0的一年是什么意思？
事实上，目前世界通行的公历中，就有持续时间为0的10天，即公元1582年10月5日至14日。事情是这样的：
西
方历法的第一次改革是罗马朱利乌斯·凯撒大帝于公元前45年亲自引进的。当时采用的数字是一年365.25天，于是朱利安历法成为最简单的历法：第一、
二、三年都是365天，三年余下的0.25天给第四年，第四年就有366天，这就是闰年。于是重复365，365，365，366的周期，每年都是整
数。
但是，一个太阳年不刚好是362.25天，而是
362.242199…天，每年相差11分14秒，也就是朱利安历法中每年多算了11分钟14秒。由于误差不太大，头几年没什么关系，凯撒活着时影响还不
大。但是，一年又一年，误差累积起来，朱利安历法就与实际的太阳年不合拍了。例如每年春分在3月21日前后，但几个世纪后，春分在朱利安历法上的日期越来
越提前了，这对农民种地不方便，对教会确定复活节在哪一天也带来麻烦。由于朱利安历法是凯撒亲自制定的，上述情况对他的威信是一个沉重打击。
16
世纪时，教皇格利戈里八世进行了一次校正。因为到16世纪，每年11分14秒已经累积成10天，也就是历法上多了10天，这对于确定复活节造成严重困难，
不得不采取措施补救。为此，格利戈里采取了解决此类难题的最古�
相关文档：
熟练使用SQL Server中的各种用法会给查询带来很多方便。今天就介绍一下EXCEPT和INTERSECT。注意此语法仅在SQL Server 2005及以上版本支持。
EXCEPT是指在第一个集合中存在，但是不存在于第二个集合中的数据。
INTERSECT是指在两个集合中都存在的数据。
测试如下：
create table t1(id int,mark char(2))
go
create ta ......
1：exec sp_addlinkedserver 'ITSV ', ' ', 'SQLOLEDB ', '192.168.*.12'
exec sp_addlinkedsrvlogin 'ITSV ', 'false ',null, 'sa ', 'F00000'
2：
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'Ad Hoc Distributed Queries', ......
SQL Server 索引结构及其使用（二）
作者：freedk
一、深入浅出理解索引结构
改善SQL语句
很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：
select * from table1 where name=''zhangsan'' and tID > 10000
和执行:
select * from table1 where tID ......
客户反映程序很慢，开始以为数据量大，在表中查询使用的字段上，添加了索引，没有明显的效果，检查时发现以前的同事在sql server中写的函数中使用了in，而在in的结果集中会有2500条记录左右，执行时间需要13秒。找到问题根源，
修改方法： 把in后面的子查询作为一个表和主表关联，添加限制条件。
原来写法： select * fro ......
