llamar a un sp que recibe parametros nvarchar..

Entendido. Gracias por la aclaracion.



"Alberto Poblacion" wrote
in message news:%23nJpw$
Mostrar la cita

"Pedro" wrote in message
news:
Mostrar la cita

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).

Mostrar la cita

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.

Entendido. Gracias por la aclaracion.



"Alberto Poblacion" wrote
in message news:%23nJpw$
Mostrar la cita

"Pedro" wrote in message
news:
Mostrar la cita

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).

Mostrar la cita

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.

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$
Mostrar la cita

"Pedro" wrote in message
news:
Mostrar la cita

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).

Mostrar la cita

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.

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$
Mostrar la cita

"Pedro" wrote in message
news:
Mostrar la cita

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).

Mostrar la cita

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.

"Pedro" wrote in message
news:
Mostrar la cita

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.