运行经典 asp 时，我的输出似乎在 IIS Express (8.0) 中被裁剪。
我猜这是一条很长的线，正在响应中被裁剪。
相同的经典 asp 在 Windows Server 2003 上的 IIS6 中似乎可以正常工作。值得注意的是，它仍然在网络分析器（F12 工具）中被裁剪，但复制到文本编辑器时不会被裁剪。
然而，非常奇怪的是，ETX 恰好插入了 666 个字符（包括空格）。
我在 IIS Express 中找不到对最大行长的引用。
编辑：
为了澄清，我想知道为什么 ETX 字符会裁剪响应以及为什么它正好是 666 个字符。
经过一番诊断。
看着各种分析器和附加调试器来回运行，我可以看到我们的 vbscript 数据层返回了一个小“L”。有问题的列是 ntext。从调试器复制到纯文本编辑器的小“L”揭示了臭名昭著的 ETX 字符。
ETX 字符似乎告诉经典 asp 立即刷新响应，而不是继续处理页面。
我只能假设运行 SQL Server 2012 Local DB 和 ADODB 存在兼容性问题。特别是因为我必须想出解决方法才能让它首先工作，即使用 SQL Server Native Client 11.0 的 ODBC 连接，然后将经典 asp 连接到 DSN。由于 SQL Server Native Client 11.0 本身在经典 asp 中无法处理 NOCOUNT 为 OFF 和 PRINT 语句。
让所有东西一起工作是一个漫长的过程（在对 ADO 进行了大量试验之后，这是迄今为止最好的选择），所以会出现（非常）奇怪的兼容性问题是可以理解的。
幸运的是，这只是一个开发人员工作站，因此在生产中无需担心。