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

Question

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

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

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

谢谢

格雷姆

Answer 1

我认为理查德的建议是这样的:

原始代码:

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 就不会关心它们的顺序。

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