SQL Server 2008 R2中記錄apears沒有創建

Question

環境：SQL Server Express的2008 R2，EW4時，Windows XP SP3

下面是ASPX頁面的幾個重要的程序語句。

conn=Server.CreateObject("ADODB.Connection") 
conn.Open (connString) --> conn.State = True 
sql1 = USE [my_db]; SELECT * FROM [dbo].[CustomerTable]; 
rs=Server.CreateObject("ADODB.Recordset") --> rs(create).State = False 
rs.Open (sql1,conn) --> rs(open).State = False 
conn.State = True 
do until (rs.EOF) // produces fatal exception 

從我的日誌文件（C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\Log\ERRORLOG）：

2017-01-02 12:31:06.33 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x54b, state: 3. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

這些是Procmon.exe（SysInternalsSuite）

Date & Time: 1/2/2017 12:21:33 PM Event Class: File System Operation: DeviceIoControl Result: INVALID PARAMETER Path: C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\ MSSQL\DATA\my_db.mdf TID: 4972 Duration: 0.0000050 Control: IOCTL_MOUNTDEV_QUERY_DEVICE_NAME

Date & Time: 1/2/2017 12:21:33 PM Event Class: File System Operation: CreateFile Result: NAME INVALID Path: C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\ MSSQL\DATA\my_db.mdf TID: 4972 Duration: 0.0000107 Desired Access: Read Attributes, Synchronize Disposition: Open Options: Synchronous IO Non-Alert, Open Reparse Point Attributes: N ShareMode: Read, Write AllocationSize: n/a Impersonating: servername\mainuser

---

至於有關解決所提到的問題SPN以前所做的努力在SQL Server ERRORLOG中，我找到了以下參考：

https://msdn.microsoft.com/en-us/library/ms191153(v=sql.110).aspx#Defaults

因此，Kerberos用於遠程連接。在這種情況下只有本地連接。所以Kerberos不在本地使用 ，在這種情況下可能並不重要。本地使用NTLM。

因此，在這種情況下，SPN的未註冊可能不是問題。

一度無法註冊ERRORLOG中提到的SPN和Kerberos身份驗證警告似乎是唯一可以跟進的項目。這是列出的唯一重大錯誤（警告），一度似乎是唯一的領先。

最初，SPN問題似乎是由於某些權限設置不足造成的。此外，許多網頁似乎都歸因於SPN問題和無法使查詢運行到權限設置不足的情況。該用戶開始認爲權限不足是他想象中的記錄集創建對象失敗的根本原因。

具體而言，此用戶認爲sql server啓動帳戶無法創建記錄集對象，因爲它沒有足夠的權限來完成任務。此外，建議使用Active Directory授予Read和WriteServicePrincipalName權限的MSDN網絡文章（爲遠程連接啓用Kerberos身份驗證）進一步加深了用戶錯誤的理解。最終，這種思路被證明是不正確的，因爲計算機是獨立的（而不是聯網的），並且不是一個服務器操作系統不能具有AD DC（本地），沒有任何遠程數據庫連接並且不需要Kerberos身份驗證用於遠程連接。

因此，在這種情況下，sql server ERRORLOG中的SPN和Kerberos警告最終被判定爲非問題。但是這部分調查耗費了大量的時間和精力，非常混亂。

儘管關於權限，但將sql server啓動帳戶登錄類型從本地服務設置（更改）到本地系統（更高特權帳戶）似乎改善了事情。

---

請接受我對您（和其他人）對我的計劃所提供的幫助和努力的讚賞。我懷疑你可能擁有比我以往任何時候都更多的sql server經驗，因此值得尊重。但是我的目標不同，爲了讓網站完全正常運行。我正在認真地嘗試遵循你的建議。

一般來說，關於這個程序，重要的是，因爲直到修復沒有可用的數據庫，沒有可用的網站，工程公司不能打開它的大門。

關於此程序，我嚴重懷疑實際上只有一個（主要）持久性問題（後來顯示爲格式錯誤的查詢字符串）。最初它看起來像一個數據庫連接或權限問題導致創建記錄集對象失敗（rs.State = 0），但事實證明這是不正確的。數據庫連接證明是足夠的，並且rs.State = 0（對於create rs對象）不是一個錯誤，更像是一個天生的零記錄消息。最初的rs.State = 0（對於rs創建對象）被誤解並被證明是非常混亂的。更令人困惑的是，rs.State實際上返回一個枚舉值（本質上是一個整數）而不是一個布爾值（例如代碼段視圖窗口中顯示的False）。在那裏顯示了意外的數據類型不匹配（非預期的非法轉換）。所以原來的代碼片段視圖窗口並不完全正確。

當程序最終運行正確時rs（創建）.State = 0和rs（打開）.State = 1，這不是預期的結果。事實上，最初的期望是rs（創建）.State和rs（打開）.State應該都等於1，證明不正確。這個用戶仔細觀看了rs（create）.State方法對象的屬性值被證明是一個無用的職業。 （它並沒有真正的幫助。）

當從sql查詢字符串中刪除「USE [my_db];」部分時，數據庫開始正確查詢並且RS.State = 1（對於rs.Open ）。至此，「USE [my_db];」殺死了每個查詢。事情開始清理，然後顯而易見的是（或曾經）一個三重數據庫連接規範，通常（或總是）有害的。兩個在連接字符串中，帶有AttachDBFilename參數和Database參數。 SQL查詢字符串中的第三個「USE [my_db];」。這三個db連接無疑會導致一些軟件問題（因爲超過了指定的），即使所有三個條目都相同且正確（對於人）。使用Procmon.exe（SysInternalsSuite）進一步測試時，顯示與AttachDBFilename參數關聯的錯誤，單獨使用時（連接字符串）數據庫參數的錯誤爲零。所以數據庫參數被選擇在連接字符串中單獨使用。

關於多活動結果集（MARS）屬性連接字符串參數，以下MSDN網站文章稱它默認情況下最初處於禁用狀態。顯然它是一種高級數據庫功能，它涉及多個高級問題，同步，異步，緩存以及多個批處理命令會話。雖然MARS功能很有價值，但它被認爲應該被禁用，直到用戶變得足夠先進以在代碼中正確處理它爲止。所以這個MARS連接參數不推薦給db初學者。 https://msdn.microsoft.com/en-us/library/h32h3abf(v=vs.110).aspx

通常與MARS一起使用時，「DataTypeCompatibility = 80;」參數將db數據類型限制爲2005集。這似乎不必要和不利。除非使用MARS，否則不推薦使用此參數。 https://msdn.microsoft.com/en-us/library/ms131002(v=sql.110).aspx

最後一個等效的鍵值對：「Integrated Security = SSPI」等於「Trusted_Connection = yes」。
所以選擇一個以避免冗餘。

一條評論說：「看看這裏瞭解如何創建正確的連接字符串：https://social.technet.microsoft.com/wiki/contents/articles/1409.how-to-create-a-sql-connection-string-for-an-application-udl-file.aspx。」我確實感覺這個UDL過程很有用，因爲它提供了系統確認什麼是正確的提供者（以及其他一些東西）。即使如此，我終於使用了自定義連接字符串。

關於確認連接字符串，確切的結果是：

[OLEDB] ;此行後的所有內容都是OLE DB initstring
Provider = SQLNCLI10.1; Integrated Security = SSPI; Persist Security Info = False; User ID =「」; Initial Catalog = my_db; Data Source = serverName \ SQLEXPRESS; Initial File Name = 「」; Server SPN =「」

---

我特別要感謝Nick。他付出了很大的努力，並一直陪伴着我直到成功的解決方案。他關於刪除「USE [my_db]」的評論直接導致了修復。完成之後，最簡單的測試sql查詢實際上可以正確運行。而所有其他的錯誤都像一幢房子一樣掉了下去（一件好事）。所以我猜他找到了我的問題的根源。真心感謝尼克。

Answer 1

這是部分理論，可能不完全正確，但這是我的理解。

看來，當Recordset.Open返回任何記錄，它與一個state=0

返回當您運行此查詢：

USE [my_db]; SELECT * FROM [dbo].[CustomerTable]; 

它返回從第一條語句的第一個記錄。在這種情況下，第一條語句是

USE [my_db]; 

，因爲它已經完美運行

返回任何記錄

所以沒有錯誤會在打開的零件被拋出 當您檢查rs.EOF因爲

錯誤將被拋出該記錄集關閉（因爲該語句沒有返回任何記錄或列）

如果您看到致命異常的封面下，您會看到類似的錯誤。

我懷疑如果您從空表中選擇，結果會有點不同，即打開的記錄集沒有記錄。

這是非常相似的SET NOCOUNT ON要求時編寫存儲過程