llamar a un sp que recibe parametros nvarchar..

08/10/2008 - 00:56 por Ariel Larraburu | Informe spam
Hola, tengo una duda medio sencilla, si llamo a un stored procedure usando
ado.net, y supongamos que los parametros
del stored procedure son nvarchar(255)... Cuando creo los sqlparameters cual
es el Length que deberia indicar?. los nvarchar utilizan 2 bit por caracter,
y mas alla de que cuando diseñanos la tabla dice 255 si eso es lo que
ponemos, si consultamos las tablas de sistema siempre dira que el max_length
es el doble, 510 en este caso.

Entonces, debo crear el parametro con 255 o con 510 de length?.

Muchas gracias.

Preguntas similare

Leer las respuestas

#1 Pedro
09/10/2008 - 03:36 | Informe spam
Entendido. Gracias por la aclaracion.



"Alberto Poblacion" wrote
in message news:%23nJpw$
"Pedro" wrote in message
news:
Creo que en ado.net también está el tipo SqlDbType.NVarChar y alli le
pones la misma longitud que tenga en el store proc. de sql server.



En la declaración del parámetro se pone el número de caracteres, no de
bytes, así que en tu ejemplo sería 255 (no 510).

Otra opcion es agregar los parámetros con AddWithValue(), y ado.net se
encarga de poner la longitud apropiada.



Conviene que NO hagas esto con los parámetros de tipo varchar o
nvarchar. Lo que hace el AddWithValue es declarar internamente un
parámetro de la misma longitud que el string que le pasas en ese momento.
Cada vez que vuelves a hacer la llamada con un nuevo string, declara de
nuevo el parámetro con una nueva longitud. El resulado es que el Sql
Server recibe múltiles sentencias que, desde su punto de vista, son
distintas puesto que tienen un parámetro diferente. Esto poluciona el
caché de procedimientos, ya que por cada sentencia distinta tiene que
compilarla y optimizarla y crear una nueva entrada en el caché, en lugar
de reutilizar una única entrada como ocurriría si declarases en tu código
correctamente el parámetro con su longitud exacta.


Respuesta Responder a este mensaje
#2 Pedro
09/10/2008 - 03:36 | Informe spam
Entendido. Gracias por la aclaracion.



"Alberto Poblacion" wrote
in message news:%23nJpw$
"Pedro" wrote in message
news:
Creo que en ado.net también está el tipo SqlDbType.NVarChar y alli le
pones la misma longitud que tenga en el store proc. de sql server.



En la declaración del parámetro se pone el número de caracteres, no de
bytes, así que en tu ejemplo sería 255 (no 510).

Otra opcion es agregar los parámetros con AddWithValue(), y ado.net se
encarga de poner la longitud apropiada.



Conviene que NO hagas esto con los parámetros de tipo varchar o
nvarchar. Lo que hace el AddWithValue es declarar internamente un
parámetro de la misma longitud que el string que le pasas en ese momento.
Cada vez que vuelves a hacer la llamada con un nuevo string, declara de
nuevo el parámetro con una nueva longitud. El resulado es que el Sql
Server recibe múltiles sentencias que, desde su punto de vista, son
distintas puesto que tienen un parámetro diferente. Esto poluciona el
caché de procedimientos, ya que por cada sentencia distinta tiene que
compilarla y optimizarla y crear una nueva entrada en el caché, en lugar
de reutilizar una única entrada como ocurriría si declarases en tu código
correctamente el parámetro con su longitud exacta.


Respuesta Responder a este mensaje
#3 Pedro
09/10/2008 - 20:29 | Informe spam
Hola Alberto,

Yo he visto a veces en el profiler que si por ejemplo un campo
System.DateTime de ado.net tiene valor NULL y uno lo manda como parametro
con AddWithValue o en general sin especificar el tipo, resulta que el
parametro se muestra como nvarchar(4000). A que se debera eso?

Otro punto es por que todos los campos System.string se transforman en
nvarchar, veo que nunca son varchar directamente. Incluso no son nchar ni
char aunque se les especifique una longitud fija. Tampoco entiendo las
razones de eso.

Gracias again.


"Alberto Poblacion"
escribió en el mensaje news:%23nJpw$
"Pedro" wrote in message
news:
Creo que en ado.net también está el tipo SqlDbType.NVarChar y alli le
pones la misma longitud que tenga en el store proc. de sql server.



En la declaración del parámetro se pone el número de caracteres, no de
bytes, así que en tu ejemplo sería 255 (no 510).

Otra opcion es agregar los parámetros con AddWithValue(), y ado.net se
encarga de poner la longitud apropiada.



Conviene que NO hagas esto con los parámetros de tipo varchar o
nvarchar. Lo que hace el AddWithValue es declarar internamente un
parámetro de la misma longitud que el string que le pasas en ese momento.
Cada vez que vuelves a hacer la llamada con un nuevo string, declara de
nuevo el parámetro con una nueva longitud. El resulado es que el Sql
Server recibe múltiles sentencias que, desde su punto de vista, son
distintas puesto que tienen un parámetro diferente. Esto poluciona el
caché de procedimientos, ya que por cada sentencia distinta tiene que
compilarla y optimizarla y crear una nueva entrada en el caché, en lugar
de reutilizar una única entrada como ocurriría si declarases en tu código
correctamente el parámetro con su longitud exacta.


Respuesta Responder a este mensaje
#4 Pedro
09/10/2008 - 20:29 | Informe spam
Hola Alberto,

Yo he visto a veces en el profiler que si por ejemplo un campo
System.DateTime de ado.net tiene valor NULL y uno lo manda como parametro
con AddWithValue o en general sin especificar el tipo, resulta que el
parametro se muestra como nvarchar(4000). A que se debera eso?

Otro punto es por que todos los campos System.string se transforman en
nvarchar, veo que nunca son varchar directamente. Incluso no son nchar ni
char aunque se les especifique una longitud fija. Tampoco entiendo las
razones de eso.

Gracias again.


"Alberto Poblacion"
escribió en el mensaje news:%23nJpw$
"Pedro" wrote in message
news:
Creo que en ado.net también está el tipo SqlDbType.NVarChar y alli le
pones la misma longitud que tenga en el store proc. de sql server.



En la declaración del parámetro se pone el número de caracteres, no de
bytes, así que en tu ejemplo sería 255 (no 510).

Otra opcion es agregar los parámetros con AddWithValue(), y ado.net se
encarga de poner la longitud apropiada.



Conviene que NO hagas esto con los parámetros de tipo varchar o
nvarchar. Lo que hace el AddWithValue es declarar internamente un
parámetro de la misma longitud que el string que le pasas en ese momento.
Cada vez que vuelves a hacer la llamada con un nuevo string, declara de
nuevo el parámetro con una nueva longitud. El resulado es que el Sql
Server recibe múltiles sentencias que, desde su punto de vista, son
distintas puesto que tienen un parámetro diferente. Esto poluciona el
caché de procedimientos, ya que por cada sentencia distinta tiene que
compilarla y optimizarla y crear una nueva entrada en el caché, en lugar
de reutilizar una única entrada como ocurriría si declarases en tu código
correctamente el parámetro con su longitud exacta.


Respuesta Responder a este mensaje
#5 Alberto Poblacion
09/10/2008 - 21:48 | Informe spam
"Pedro" wrote in message
news:
Yo he visto a veces en el profiler que si por ejemplo un campo
System.DateTime de ado.net tiene valor NULL y uno lo manda como parametro
con AddWithValue o en general sin especificar el tipo, resulta que el
parametro se muestra como nvarchar(4000). A que se debera eso?

Otro punto es por que todos los campos System.string se transforman en
nvarchar, veo que nunca son varchar directamente. Incluso no son nchar ni
char aunque se les especifique una longitud fija. Tampoco entiendo las
razones de eso.



En cuanto a los DateTime, no tengo respuesta, pero en cuanto a los
strings sí: Todos los Strings en .Net se guardan internamente en Unicode.
Cuando los mandas al sevidor de BD usando el AddWithValue, este método crea
un parámetro asignándole el tipo que deduce del argumento que le pasas. Si
le pasas un String, como el String es Unicode, genera un parámetro de Sql
capaz de contener Unicode, que se precisamente el NVarchar.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida