2011-04-28 55 views
1

我有一个奇怪的现象,我无法解释,也没有重现,我希望你有一个想法如何有可能为用户输入一个无效的值。MS Access 2003:用户能够输入无效值;怎么样?

我有一个表单包含一个编辑字段,应该只接受没有任何日期信息的时间值的Access-MDB。

该编辑字段的相关属性如下:

  • 绑定到一个日期/时间数据库值(因为访问知道有没有时间,只有数据类型)
  • 格式:“时间,24小时”
  • 输入格式:“99:99”

(我用访问的德国版本,所以属性名称可能会略有不同,但你看到的图案)

现在我发现用户能够在该字段中输入日期值。我几乎100%确定这是一次意外事故,并且没有以直接打开表格和编辑相应的日期/时间字段的形式出现“巧妙的破解”。自从2009年进入该项目以来(没有人发现错误),我没有机会询问用户它是如何完成的。

我发现两个错误的日期为“01.06.2000”和“01.07.2000”的条目,我猜想用户想输入时间“06:00”和“07:00”。

我想尽输入我能想象(如“6.0”,“6; 0”,“6,0”,复制粘贴&),但我无法欺骗接入和进入,除了数字和冒号什么。

您是否了解正在进行的操作以及用户如何能够意外输入这些日期?

+0

来解决这个问题是改为使用未绑定的最简单的方法控制并使用它的BeforeUpdate字段来验证输入内容,然后使用AfterUpdate事件写入基础字段。 – 2011-04-29 02:18:24

回答

0

几种可能性:看原始表

    • 开发人员(?你)这样做是偶然的客户端访问软件就瞬间疯狂和损坏的条目。这发生在我们身上(幸运的是非常少见),我们的Access表将以字符串字段中的非ASCII字符结束。
    • Access运行时中的一个错误允许过去出现该问题,但已在Service Pack中得到纠正。

    最后,如果你放了90个小时,它会溢出到4天吗?这可能会做到。

  • +0

    23:59之后的所有内容都会给出错误。 – VVS 2011-04-28 17:49:58

    1

    Jet/ACE日期/时间值永远不会“没有任何日期信息”存储。如果您试图只存储时间分量,它实际上将在第零天(1899年12月30日)的同一时间存储。

    我们只能推测在2009年如何添加不正确的数据。如果您希望数据库引擎要求日期/时间值作为日期组件存储,则可以添加表级别验证规则。从表属性表,尝试一下本作验证规则:如果你想允许空值your_date_field

    DateValue([your_date_field])=CDate("1899/12/30") 
    

    ,试试这个版本:

    IsNull([your_date_field]) Or DateValue([your_date_field])=CDate("1899/12/30")