当我使用以下代码时：
Dim cmd As New OdbcCommand("SELECT GETDATE()", oConn)
retVal = cmd.ExecuteScalar()
结果输出为：
8/1/2013 10:10:39 AM
当我直接在Management Studio中运行完全相同的查询时，我得到：
2013-08-01 10:10:39.317
当我检查我的计算机设置与他们匹配的SQL Server设置时。
任何人都知道我需要做些什么来确保它匹配？
具体来说，我说的是日期格式差异。
答案 0 :(得分：5)
如果您希望日期输出具有特定的字符串格式，则可以将CONVERT()与样式编号一起使用。例如：
SELECT CONVERT(CHAR(20), GETDATE(), 22),
CONVERT(CHAR(23), GETDATE(), 21);
结果：
-------------------- -----------------------
08/01/13 10:53:54 AM 2013-08-01 10:53:54.943
但是，如果您将日期用于直接显示以外的其他内容，则仅在显示时应用该格式。出于所有其他目的，它应该保持日期时间类型，并且不应转换为字符串。
至于实际时间价值的差异，目前尚不清楚你在说什么问题，但我怀疑你只是将这些查询分开了半小时。如果那些是在同一时间或大约同一时间运行，看起来服务器快半小时 - 也许它在不同的时区或者可能只是很多漂移或有人不打扰使用时间服务。您的应用程序永远不应使用客户端的时间/时区，尤其是在分发时 - 始终使用服务器上的时间。
答案 1 :(得分：1)
日期没有格式。只有将日期转换为字符串时格式才会起作用。使用的格式取决于谁进行转换：服务器还是客户端？
您的VB.NET查询从服务器返回日期，并在将其写入控制台，表单或其他内容时将其转换为字符串。 VB.NET使用您的programm的CurrentCulture，其默认值来自当前用户的区域设置。
在SSMS中显示数据时，使用ISO格式，因此编辑数据时不会产生歧义。
在查询中比较日期和字符串值时，要么通过将日期转换为字符串显式，要么隐式地因为您只键入MyDate = '13/1/2013，使用列的排序规则进行转换。归类是继承的，因此列的归类与数据库的归类相同。
答案 2 :(得分：0)
试试这个：
net time \\SERVER_NAME
注意：显然SERVER_NAME是SQL Server计算机的名称。
您是否看到该通话结果有30分钟的差异？
答案 3 :(得分：-3)
我深入研究了代码，发现一些有进取心的人在之后的过程中为一行SQL添加了代码，强制在该查询上使用DMY格式。
因此VB中的代码在应用程序机器上返回正确的日期。这意味着我的计算机和应用程序计算机之间必须存在差异。
另一个编码器遇到了同样的问题，因此解决方案是将以下代码添加到从数据库中提取的SQL中。
SET DATEFORMAT dmy
这会强制SQL使用DMY格式...我删除了这段代码编译并从服务器机器运行EXE，我的问题干涸了！
感谢大家的帮助。