tutorial tiempo real notificaciones enviar detectar dependency datos con cambios .net sql ado prepared-statement

.net - tiempo - AddWithValue sin DBType que hace que las consultas se ejecuten lentamente



sqldependency tutorial (3)

El problema está relacionado con la forma en que el servidor SQL realiza las conversiones de tipo implícito. Si filtra una columna VARCHAR utilizando un valor NVARCHAR (es decir, N''some text ''), SQL no tiene más remedio que convertir la columna en NVARCHAR, ya que NVARCHAR no se puede convertir implícitamente a VARCHAR.

La mejor solución es especificar el tipo o cambiar la columna de la base de datos para que sea NVARCHAR.

He estado usando cmd.Parameters.AddWithValue, y no he especificado un DBType (int, varchar, ...) para ejecutar consultas. Después de observar el Analizador de SQL, parece que las consultas que se ejecutan con este método se ejecutan mucho más lentamente que cuando se especifica el tipo de datos.

Para darle una idea de cuánto más lento es, aquí hay un ejemplo. La consulta es una búsqueda simple en una sola tabla y la columna en la instrucción where está indexada. Al especificar el tipo de datos, una consulta determinada se ejecuta en aproximadamente 0 MS (demasiado pequeña para que el servidor SQL mida) y requiere 41 lecturas. Cuando elimino el DBType, puede tomar alrededor de 200 ms y 10000 lecturas para completar la consulta.

No estoy seguro de si solo se trata de valores incorrectos del Analizador de SQL, o si estos valores son realmente correctos, pero es reproducible, ya que puedo agregar y eliminar el DBType y generará los valores que se proporcionan en el Analizador de SQL.

¿Alguien más ha encontrado este problema y una forma simple de solucionarlo? Me doy cuenta de que podría agregar el tipo de datos en todo mi código, pero eso parece como un montón de cosas para agregar, y si hay una manera más fácil de solucionarlo, sería muy apreciado.

[EDITAR]

Después de algunas pruebas iniciales (ejecutando ambos escenarios en un bucle), parece que los valores que da el perfilador son precisos.

Al igual que la información adicional, estoy ejecutando .Net 2.0 en Windows XP Pro y SQL Server 2000 en Windows 2000 para la base de datos.

[ACTUALIZAR]

Después de investigar un poco, pude encontrar esta publicación de blog , que puede estar relacionada. Parece que los valores de cadena en .Net (ya que son unicode) se crean automáticamente como parámetros nvarchar. Tendré que esperar hasta el lunes cuando entre al trabajo para ver si puedo hacer algo al respecto que solucione el problema. Todavía parece que tendría que establecer el tipo de datos, que era lo que estaba tratando de evitar.

Este problema no aparece con cada consulta que hice, solo unos pocos, por lo que aún puedo recurrir a establecer DBType en las consultas con problemas, pero estoy buscando una solución más general al problema.


Me encontré con este problema EXACTO. Tengo una base de datos heredada con muchas columnas char. Sin especificar el tipo de columna, los resultados tardaron un par de minutos en una de mis consultas. (Por defecto es nvarchar.) Especificar el tipo de columna causó que los resultados tomaran segundos.

cmd.Parameters.AddWithValue("charcolumn", "stringvalue"); cmd.Parameters[0].SqlDbType = SqlDbType.Char;

Creo que voy a tratar de tener todas las cadenas de consulta como un tipo de caracteres y ver cómo va eso.

[editar]

En realidad ... después de leer esto: http://www.u2u.info/Blogs/U2U/Lists/Posts/Post.aspx?ID=11

He decidido ir con esta solución:

cmd.Parameters.AddWithValue(colName, val); if(val is string) cmd.Parameters[i].DbType = DbType.AnsiString;


¿Cuál es la declaración SQL generada en ambos casos?

Estoy sospechando que asume el valor como varchar cuando no lo especifica explícitamente.

por ejemplo, SELECT OrderId FROM Orders WHERE OrderId = 1001
vs SELECT OrderId FROM Orders WHERE OrderId = ''1001''