二． Lotus Domino 中的日期处理
---- 在使用ODBC族对象类与关系数据库进行交互的代码里，有下面一段：
[Copy to clipboard]CODE:
If Isdate(value) Then
If value = Datevalue("0:00:00") Then
value = ""
Else
value = Format(value,"mm-dd-yyyy")
End If
Set item = doc.AppendItemValue(field,value)
End if
---- 这一段代码的作用是：判断从关系库中读取出来的字段是否为日期型字段，如果是，那么判断此日期型字段的值，看它是否为空，如果为空则在写入Notes库的时候做处理，保证写入的是空日期类型，如果此字段的值不为空则直接写入Notes库；如果此字段不是日期型字段，则不做任何处理。也许有人会问：为什么对于日期型字段要单独做此番处理？
---- 答案是：如果不做上述处理，那么通过ODBCResultSet类取出的日期型字段的值如果为空，则写入Notes库的时候会出现一个特殊日期：“1899年12月30日”。为什么会出现这个日期，目前尚不得而知。但是在Lotus Script中由于没有单独的Date数据类型，所以Notes的日期变量是以8个字节的浮点数的形式存在的，其整数部分表示公元某年某月某日，其小数部分表示小时分秒，从午夜开始计数。
---- 其日期类型可以表示的范围从公元100年1月1日（-657434），到9999年12月31日（2958465）这一天，然后Notes会把9999年12月31日对应的整数日期以及所有超过上述日期范围的日期都换算成1899年12月30日。Notes为什么会用这种方法处理日期型变量，以及为什么把1899年12月30日作为无法换算日期的默认值这一点目前还没有比较好的解释，但是作为一个数据库转换程序，应该保证转换前后的两个数据库中内容的一致性，因此由于Notes本身没有解决这个问题那么就只能由程序来解决。解决的思想是：如果取出来的日期型变量的值为空，那么就应该向Notes库中写入空日期，于是就有了上面的代码。
---- 在代码中，使用到了一个DateValue（string）函数，此函数的功能是将字符串参数转换成日期数据类型，如果字符串所表示的内容找不到合法的日期数据与之对应，那么此函数将保留字符串的值不变，而仅仅把其数据类型转换成日期型，即实现了强制类型转换函数的功能。而代码中的“0：00：00”字符串是个特殊字符串，在通过ODBC数据源读取关系数据库的记录时，如果关系库中的日期型字段值为空，那么取出的值就是“0：00：00”形式的日期（这也许与Microsot公司的ODBC驱动及相关程序有关，因为不只是Notes取出空日期为此值，其他软件甚至包括微软自己的MS Query组件通过ODBC读取同一关系数据库中的日期型变量时也会出现同样的问题）。使用DateValue（“0：00：00”）语句就可以判断取出的日期型变量的值是否为空，如果为空则将变量Value的值赋成空字符串，然后再写入Notes库中，则可避免出现1899年12月30日这个特殊日期。
---- 虽然Lotus Script中没有提供专门的日期数据类型，但是Lotus却提供了NotesDateTime对象类，其中包括了日期数据的相关处理，如果开发者必须要在程序中处理日期数据而又觉得Lotus Script提供的函数不够的话，可以考虑使用NotesDateTime对象。
三． Notes中视图与表单的关联
---- 在开发过程中，由于一次错误意外地发现了Notes中视图与表单的关联技巧。Notes为每个表单都设置了名称与别名两个属性，这两个名字都能标识表单。在开发过程中，所开发的库有两个表单，分别命名为Form1和Form2，其各自的别名由于疏忽都设成了Document，而每个表单都有一个视图与之对应，在设计Form2的视图时，虽然指定视图中的列都与Form2中的域相关联，但是在运行的时候从视图中双击某条文档欲对其进行编辑时，切换到的表单却是Form1的，多方查找均不能解决这个问题，于是报着试试看的心理改变了表单的别名，分别为Document1和Document2，问题解决。但是又从出现Form1的视图无法切换到表单的情况，于是又将Form1的别名改回Document，两个视图均能正确切换到自己的表单上。
---- 由此发现，Notes在建立视图与表单的关联的时候，首先看表单是否具有别名，如果有，则用别名进行关联，一旦对表单的别名进行了改变就得重新设计视图，如果不想重新做视图就不能改变表单的别名。当然同时也可以应用这一技巧实现从视图中切换到不同表单的功能。如果表单没有别名，则使用名字进行关联。
