从 varchar 字段返回有效日期的函数
我们有一个函数可以从字符串的前 8 个字符中提取日期。由于该系统的编写方式,用户被告知必须在字段中以 8 个字符的格式输入日期。例如,必须输入 12/06/10。按照原始函数的编写方式,12/6/10 或 12/06/2010 将生成错误的日期。
我将函数修改为下面的代码来纠正这个问题,并想知道是否有人有任何其他建议来使其更加防弹。我假设返回日期时间将始终返回 19xx 或 20xx 的有效日期。我不确定 SQL 使用什么来确定何时使用 19xx 与 20xx,并且我不担心小于 1980 和大于 2100 的日期。
此应用程序仍然使用 SQL Server 2000。
Alter FUNCTION [dbo].[GetDateFromField] ( @FieldString varchar(256) )
RETURNS datetime AS
BEGIN
DECLARE @tempResult varchar(8)
SET @tempResult = left(@FieldString,8)
IF isdate(@tempResult) = 0
BEGIN
SET @tempResult = NULL
END
RETURN @tempResult
END
We have a function that pulls the date from the first 8 characters of a string. Because of the way this system was written, the users are told they have to enter the date in an 8 character format in the field. For example, 12/06/10 must be entered. The way the original function was written, 12/6/10 or 12/06/2010 would generate a wrong date.
I modified the function to the code below to correct this issue and wonder if anyone has any other suggestions to make this more bullet proof. I'm assuming that returning the datetime will always return a valid date for both 19xx or 20xx. I'm not sure what SQL uses to determine when to use 19xx vs. 20xx and I'm not worried about dates less that 1980 and greater than 2100.
We are still on SQL Server 2000 for this app.
Alter FUNCTION [dbo].[GetDateFromField] ( @FieldString varchar(256) )
RETURNS datetime AS
BEGIN
DECLARE @tempResult varchar(8)
SET @tempResult = left(@FieldString,8)
IF isdate(@tempResult) = 0
BEGIN
SET @tempResult = NULL
END
RETURN @tempResult
END
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
“世纪截止”日期由 SQL Server 设置控制 - 请查看此博客文章< /a> 以获得很好的解释。
执行此命令以查看您当前的设置:
您还可以根据需要更改此选项。
The "century cut-off" date is controlled by a SQL Server setting - check out this blog post for a great explanation.
Execute this to see your current setting:
You can also change this option as needed.
您可以使用 TRY 和 CATCH 语句来提高稳健性。
You could use TRY and CATCH statements to increase robustness.
仅在 SQL2000 上进行了半测试,但我认为这可以处理大多数类似日期的输入。
Only semi-tested on SQL2000 but I think this handles most date-like input.