如何强制 SQL Azure 在查询字符串中接受 DMY？

Question

我们正在尝试将一系列遗留应用程序迁移到 SQL Azure。这些应用程序是用经典 ASP 编写的，带有大量基于字符串的查询。有很多东西需要重写才能使其值得迁移。

任何带有日期的查询都会失败，因为 SQL 字符串查询使用 UK DMY 格式。 SQL Azure 用户和数据库似乎很难使用美国英语格式。

如果我添加 SET DATEFORMAT dmy;在查询字符串之前，查询将起作用。然而，这需要更改数千个查询。是否有强制 SQL Azure 使用 DMY 格式作为连接字符串的一部分？那个或其他一些解决方案可以帮助我们节省重写数千个查询的时间？有什么方法可以将登录设置为始终使用 DMY 格式或让整个数据库使用 DMY 等？

谢谢格雷姆

​

Answer 1

我认为 Richard 的建议是这样的：

原始代码：

Dim rs
Set rs = Server.CreateObject("ADO.Recordset")
... recordset shiznit ...
Set rs = nothing

新代码：

Dim rs
Set rs = New cHomegrownAdoRecordsetWrapper
... same unchanged recordset shiznit ...
Set rs = nothing

如果代码是用 VBScript 编写的，那么您将很难实现这一点。

[如果您尝试在 VBScript 中本地执行此操作]，您遇到的第一个问题是 ADO Recordset 对象在其方法中大量使用可选参数，并且您根本无法在 VBScript 中创建函数（或类方法）有可选参数。因此，您将无法对任何有用的内容进行子类化。

不过，您可以在 JScript 中子类化 ADo 记录集对象 - 可以在同一页面中使用的同一脚本中混合和匹配两种语言；只要意识到 JScript 的任何内容都会首先执行，无论它位于页面中的哪个位置。 ASP 首先运行 JScript 解释器，然后运行 ​​VBScript 解释器。

您也许还可以创建自己的基于 Com 的 DLL 来包装 ADO 对象...但您必须自己进行研究。

现在。

如果是我，我会认真考虑搜索和搜索。替换，具体取决于代码的一致性。

如果您可以使代码达到内联查询使用“dd FullMonthName YYYY”（即明确的日期格式）的程度，则您无需担心数据库的 DMY 问题，并且代码将在任何版本上生存它所运行的 SQL 的。

只要日期具有基于文本的月份名称和全年，SQL 就不会关心它们的顺序。

我怀疑您甚至可以在较小的范围内采用理查德的想法，并放置一个包装器只要有内联日期，就可以运行，进行一些运行时嗅探，然后让一切重新工作。

Answer 2

您可以对连接本身进行子类化，以便每当发送命令时都会在其前面加上 SET DATEFORMAT 命令。这将需要重构您的引擎，但这可以通过搜索替换来实现。