PRB: ADO EOF restituisce true in SQL Server 7.0, errore di timeout di imposta in SQL Server 6.5

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

252405
Questo articolo è stato archiviato. L’articolo, quindi, viene offerto “così come è” e non verrà più aggiornato.
Sintomi
Quando si apre un recordset ADO (ActiveX Data Objects) con il blocco pessimistico in già bloccato dati e quindi controllare il recordset per la proprietà EOF , visualizzato risultati diversi in Microsoft SQL Server 6.5, Microsoft SQL Server 7.0 e Microsoft SQL Server 2000. Con Microsoft SQL Server 6.5, un errore di timeout verrà generato nella chiamata Open del recordset ADO. Quando si utilizza Microsoft SQL Server 7.0 o Microsoft SQL Server 2000, che la chiamata Open ha esito positivo e controllo EOF restituisce true e che non viene generato alcun errore.
Cause
Questa discrepanza si verifica perché il computer che esegue SQL Server 6.5 non sta inviando che i pacchetti TDS (Tabular Data Stream) eseguire il backup stesso modo in cui il computer che eseguono SQL Server 7.0 è. Di conseguenza, il provider è reagisce di conseguenza.

Quando si esegue la chiamata rs.Open , rende SQL Server 6.5 due API Netlibrary chiama insieme, uno per sp_cursoropen e l'altro per raccogliere i metadati per il set di righe restituito. La chiamata sp_cursoropen torna immediatamente (e correttamente) ma la chiamata riportata di seguito per ottenere i metadati è bloccata sul server e del timeout della connessione. Poiché queste due chiamate vengono eseguite come unità, la chiamata di intero rs.Open avrà esito negativo e viene restituito l'errore di timeout.

Con SQL Server 7.0, queste due chiamate inoltre rilasciate insieme, ma la chiamata a ottenere i metadati non è bloccata sul server perché è più ottimizzato a questo proposito e non bloccare i metadati. Inoltre, poiché entrambi eseguono correttamente tra loro, la chiamata a rs.Open viene completata senza errori. Quando viene chiamato EOF, ADO non esegue nessun errore verifica se i dati effettivamente sono bloccati in questo metodo e pertanto non viene generato alcun errore. ADO è soddisfatta fino a quando è effettivamente recuperare i dati con una chiamata a sp_cursorfetch e rileva che i record sono bloccati e quindi viene generato l'errore.

Tutti i server back-end che è possibile separare creazione del cursore e i metadati dal recupero di dati effettivi in genere visualizza lo stesso comportamento EOF chiamate a quello di SQL Server 7.0.
Risoluzione
Poiché EOF non è la posizione per restituire errori, è necessario utilizzare un metodo MoveFirst oppure fare riferimento direttamente il recordset in modo che è possibile rilevare il blocco sui dati.

Un consiglio è controllare rs.Status (che chiama internamente il metodo MoveFirst ), poiché viene restituito che l'errore di timeout se è uno ed errori di timeout di blocco delle anche piena onestà notifica se EOF/BOF restituisce true e consente di ottenere lo stato di set di record.
Status
Questo comportamento legato alla progettazione.
Informazioni
Indipendentemente, se si utilizza il provider OLE DB o il driver ODBC, il comportamento è identico.

Procedura per riprodurre il problema


Consente di aggiungere il codice riportato di seguito a un progetto Visual Basic a riprodurre l'errore:

Nota <username>È necessario modificare l'ID utente = valore <nomeutente> e la password = < strong password > valore i valori corretti prima di eseguire questo codice. Assicurarsi che tale utente ID disponga di autorizzazioni appropriati eseguire questa operazione sul database.
Dim cnRead As New ADODB.Connection, cnWrite  As New ADODB.Connection    Dim rsRead As New ADODB.Recordset, rsWrite As New ADODB.Recordset    Dim strConn As String, strSQL As String        strConn = "Provider=SQLOLEDB;Data Source=SQLServer1;Initial Catalog=Pubs;User ID=<username>;Password=<strong password>;"    'strConn = "Provider=MSDASQL;Driver={SQL Server};Server=SQLServer1;Database=Pubs;UID=<username>;PWD=<strong password>;"    cnRead.CommandTimeout = 12    cnRead.Open strConn    cnWrite.Open strConn    strSQL = "SELECT * FROM Authors WHERE Au_ID = '341-22-1782'"    rsWrite.Open strSQL, cnWrite, adOpenKeyset, adLockPessimistic, adCmdText    rsWrite.MoveFirst  '  This locks the data    'open the same table with adLockPessimistic again    rsRead.Open strSQL, cnRead, adOpenKeyset, adLockPessimistic, adCmdText     'SQL6.5 server, Open will fail with time-out error        If MsgBox("Check EOF?", vbYesNo) = vbYes Then        If rsRead.EOF Then   ' SQL7.0 hangs here for time-out period            MsgBox "No Data, No Error"        Else            MsgBox "Not EOF", , rsRead!Au_ID        End If    Else        MsgBox rsRead!Au_ID    End If				
Riferimenti
(c) 1999 Microsoft Corporation, tutti i diritti riservati. Con il contributo di Rick Anderson, Microsoft Corporation.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 252405 - Ultima revisione: 02/23/2014 16:22:06 - Revisione: 3.1

  • Microsoft Data Access Components 2.1
  • Microsoft Data Access Components 2.5
  • Microsoft Data Access Components 2.6
  • Microsoft Data Access Components 2.7
  • Microsoft SQL Server 6.5 Standard Edition
  • Microsoft SQL Server 6.5 Service Pack 1
  • Microsoft SQL Server 7.0 Standard Edition
  • kbnosurvey kbarchive kbmt kbdatabase kbprb KB252405 KbMtit
Feedback