Punctuation marks
apostrophe ( ‘ ) ( ’ )
brackets ( ( ) ) ( [ ] ) ( { } ) ( 〈 〉 )
colon ( : )
comma ( , )
dashes ( ‒ ) ( – ) ( — ) ( — )
ellipsis ( … ) ( … )
exclamation mark ( ! )
full stop/period ( . )
hyphen ( – ) ( ‐ )
interrobang ( ‽ )
question mark ( ? )
quotation marks ( ‘ ’ ) ( “ ” )
semicolon ( ; )
slash/solidus ( / )
space ( ) and interpunct ( · )

Other typographer’s marks
ampersand ( & )
asterisk ( * ) and asterism ( ⁂ )
at ( @ )
backslash ( \ )
bullet ( •, more )
dagger ( † ‡ )
degrees ( ° )
number sign ( # )
prime ( ′ )
tilde ( ~ )
underscore ( _ )
vertical bar/pipe ( | )

丰子恺有七个儿女。1947年，丰先生50岁，他在杭州与子女立下“约法”。内容如下：

年逾五十，齿落发白，家无恒产，人无恒寿，自今日起，与诸儿约法如下：

（一）父母供给子女，至大学毕业为止。放弃者作为受得论。大学毕业后，子女各自独立生活，并无供养父母之义务，父母亦更无供给子女之义务。

（二）大学毕业后倘能考取官费留学或近于官费之自费留学，父母仍供给其不足之费用，至返日为止。

（三）子女婚嫁，一切自主自理，父母无代谋之义务。

（四）子女独立之后，生活有余而供养父母，或父母生活有余而供给子女，皆属友谊性质，绝非义务。

（五）子女独立之后，以与父母分居为原则。双方同意而同居者，皆属邻谊性质，绝非义务。

（六）父母双亡后，倘有遗产，除父母遗嘱指定者外，由子女平分受得。

丰先生“家无恒产”，生儿育女靠的是译著的版税和字画的润格。从这份“约法”可以看出，丰先生给儿女以平等的爱，以同等的教育机会。丰先生早年留学日本，他的绘画和音乐的才华，以及阅读日文和英文的能力都得益他的留学生涯，因而也希望儿女上大学或出国留学，但不强迫。他满腔热情地爱着儿女，但不溺爱，供养只到“大学毕业”或“留学”期满为止。“约法”中四、五两条尤其好：让已经“独立”的子女过自己的生活，鼓励已经“独立”的子女与父母“分居”。子女独立了，父子父女之间也就不再有什么“义务”，只有“友谊”和“邻谊”，这就超越了旧中国“养儿防老”和“长宜子孙”的观念。既不向儿女索取回报，也不为儿女安排所谓的舒适的生活，让儿女们走自己该走的路，过自己该过的生活，彻底的真实而纯洁。丰先生多么仁慈通达啊！

PIVOT是新引入SQL Server 2005的运算符，它让你能够将行级数据旋转成为列表数据，而不需要像先前版本的SQL Server一样使用CASE语句。

CASE语句查询

对于数据库开发人员来说，将行级数据转换为列级数据并不是什么新东西。在SQL Server以前的版本里，要获得所需要的跨表格数据集就要用到一系列CASE语句和聚合查询。虽然这种方式让开发人员具有了对所返回数据进行高度控制的能力，但是编写出这些查询是一件很麻烦的事情。

为了看一下这些CASE语句是如何使用的。我们需要一些测试数据。运行列表A里的脚本能够创建一个SalesHistory表格并把数据加载到表格里。

现在我可以编写一个基于CASE语句的PIVOT查询。这个查询的目标是按照年份将每件产品的销售状况集中起来，这些产品包括：BigScreen、PoolTable和Computer。每件产品自己的销售数据都放在专用的列里。列表B里是CASE语句查询的脚本。

这个查询虽然很简单，相对容易编写，但是很繁复。你必须明确地为每个想要转换成列表数据的行输入一个CASE语句，这一点意思都没有。如果有个程序能够帮你自动完成这项任务就好了——这就是PIVOT运算符的作用之所在。

PIVOT

由于SQL Server 2005有了新的PIVOT运算符，就不再需要CASE语句和GROUP BY语句了。（每个PIVOT查询都涉及某种类型的聚合，因此你可以忽略GROUP BY语句。）PIVOT运算符让我们能够利用CASE语句查询实现相同的功能，但是你可以用更少的代码就实现，而且看起来更漂亮。列表C是一个示例PIVOT查询，它模仿的是我们的CASE语句查询。

这个查询的关键部分是PIVOT运算符后面的括号。在括号里面，我们使用一个SUM聚合函数计算用FOR Product IN()语句列出的每个Product的SalePrice总和。这个语句可能看起来有点别扭，因为IN()语句的值没有放在（’）符号里，它们是文本值。这些值事实上被当作ColumnNames对待，它们在最终的结果集里被转换成列表字段。

如果你运行这个查询，得到的结果与我们从CASE语句查询获得的结果类似。但两者的一个重要不同之处是，这个查询仍然会为我们表格里列出的每个行返回一个行，这当然是不能令人满意的；我们希望获得一个直观的表格列表，列出每年的销售量。造成这种情况的问题在于我们一开始编写PIVOT查询的方式。

在这个查询的SELECT语句中，我们只是在SalesHistory列表里简单地列出了年，并为每个产品设定了一个字段。因此问题在于处理PIVOT语句的SELECT语句无法确定在PIVOT语句里要使用哪一个列。PIVOT语句将分组应用到了所有的列，后者既不是旋转字段也不是聚合字段。我们可以使用子查询来实现满意的结果。列表D是编写好的查询。这一小小的改动让我们能够用更少代码模拟CASE语句查询。

不足之处

PIVOT运算符在很多情况下都很有用，然而它还有一些不足之处。PIVOT运算符所提供的很多功能都要求你对旋转成为列级数据的字段进行“硬编码”。你可以利用动态TSQL语句编写PIVOT查询来解决这一问题，但是这还不是最理想的解决办法。

使用PIVOT语句的另外一个潜在问题是你或许只能在结果集里聚合一个字段；而你利用CASE语句查询可以聚合任意多的字段。

虽然这些潜在不足之处似乎可能成为阻碍使用新PIVOT运算符的障碍，但是它在TSQL开发人员的工具箱里还是占有一席之地。

一不小心将VSS 6 admin用户的密码忘记(再此证明我的粗心)，Baidu了一番,找到以下信息

the secret is to hack the um.dat file to remove the Admin password

from offset 80 the bytes are (all numbers are hex)

0:80  55 55 bc 7f 41 64 6d 69 6e 00 00 00 00 00 00 00
0:90  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0:a0  00 00 00 00 90 6e 00 00 a8 01 00 00 00 00 00 00

Just load the um.dat file into a hex editor and change the bytes from =
offset 80 to exactly what is shown above. When the SourceSafe admin tool =
starts it believes that the admin password has never been set.

the hex values above are taken from a ‘virgin’ um.dat file

of course, you didn’t get this from me….and ALWAYS backup first (just =
in case I’m wrong)
有朋友看不懂，我用中文解释一下

如果忘记了密码，打开你vss数据库所在的文件夹，打开data目录，
找到um.dat文件，用hex编辑器打开编辑它，从offset 80的55 55 开始
将值改为如上文所述的样子，然后保存，这样um.dat文件就回到了
初始状态，然后打开vss admin,用admin用户登录，不需要密码了。

thanks googlepages.com:  下载:  UM.DAT  我放了一个修改过的文件.