Orden y prioridad de los parámetros de OleDbCommand

He estado depurando esta consulta durante los últimos 40 minutos, y el problema aparentemente es el orden de los parámetros después de todo.

SELECT * FROM tblSomeThing WHERE id = @id AND debut = @dtDebut AND fin = @dtFin 

Luego agrego los parámetros de esta manera, observe que los dos últimos parámetros están cambiados, no obtengo ningún resultado.

 cmd.Parameters.Add("@id", OleDbType.Integer).Value = idSociete; cmd.Parameters.Add("@dtFin", OleDbType.Date).Value = dateTraitementFin; cmd.Parameters.Add("@dtDebut", OleDbType.Date).Value = dateTraitementDebut; 

Cuando declaro los parámetros de la forma en que aparecen en la querella, todo funciona perfectamente.

¡Pensé que los parámetros nombrados estaban en primer lugar para abordar este problema! ¿que me estoy perdiendo aqui?

Gracias

De acuerdo con http://msdn.microsoft.com/en-us/library/system.data.oledb.oledbcommand.parameters.aspx OleDbCommand no es compatible con el parámetro nombrado

El proveedor OLE DB .NET no admite parámetros con nombre para pasar parámetros a una instrucción SQL o un procedimiento almacenado llamado por un OleDbCommand cuando CommandType está establecido en Texto. En este caso, se debe usar el marcador de posición de interrogación (?). Por ejemplo:

 SELECT * FROM Customers WHERE CustomerID = ? 

Por lo tanto, el orden en el que se agregan los objetos OleDbParameter a OleDbParameterCollection debe corresponder directamente con la posición del marcador de posición del signo de interrogación para el parámetro en el texto del comando.

Por lo tanto, el orden del parámetro es importante.

Si recuerdo correctamente, si el OleDbCommand en ADO.NET funciona de manera similar a la librería / bibliotecas ADO más antiguas (usadas en VB6, VBA, etc.) entonces la colección de parámetros no define parámetros por nombre, solo por posición dentro de la colección. Este parece ser el comportamiento que estás experimentando.

No es positivo, pero no parece que sus parámetros se agreguen en la misma secuencia, ni los mismos valores con nombre que sus contrapartes “@” de la consulta …

 @id, @dtDebut then @dateTraitementFin