Quando OleDbDataAdapter non dice la verità...
Stamattina sono impazzito una buona mezz'ora per capire perché non andasse questa query:
sqlQuery = "SELECT IDFile,IDTicket,FileName FROM files WHERE (IDTicket=" & idTicket & ");"
Per dovere di cronaca l'accesso ai dati è fatto con questo poco di codice .NET:
Dim sourceAdapter As System.Data.OleDb.OleDbDataAdapter
Dim conn As System.Data.OleDb.OleDbConnection
Dim dsResult As New System.Data.DataSet("Result")
Dim rows As DataRowCollection
conn = New System.Data.OleDb.OleDbConnection(connString)
conn.Open()
sourceAdapter = New System.Data.OleDb.OleDbDataAdapter(sqlQuery, conn)
If (Not sourceAdapter Is Nothing) Then
sourceAdapter.Fill(dsResult)
sourceAdapter.Dispose()
End If
conn.Close()
conn.Dispose()
If (Not dsResult Is Nothing) AndAlso (dsResult.Tables.Count > 0) Then
rows = dsResult.Tables(0).Rows
Else
rows = Nothing
End If
Solo che non arriva un record che sia uno, nonostante l'unica table presente nel DataSet riempito sia popolata correttamente con le tre colonne che mi aspetterei. Se fate più o meno la stessa identica query da Access funziona tutto magicamente: mi ritrovo proprio le righe che vado cercando. Dopo un po' l'arcano salta fuori qui. Se faccio questa interrogazione:
sqlQuery = "SELECT IDFile,IDTicket,FileName FROM [files] WHERE (IDTicket=" & idTicket & ");"
Allora la DataRowCollection è popolata perfettamente coi record. A quanto pare l'OleDbDataAdapter non gradisce files, mentre gradisce [files], quindi ne desumo che files sia parola riservata, più o meno come lo è anche GUID. Ma tirare un'eccezione che sto usando una parola riservata è una cattiva idea? O forse se files lo scrivo senza parentesi quadre, vuol dire in SQL qualcos'altro?
|