Valor de retorno de un procedimiento almacenado

18/11/2003 - 17:11 por JoseMiguel | Informe spam
Hola a todos,
estoy haciendo una aplicacion web que utiliza SQLServer como base de
datos y procedimientos almacenados como metodo para interactuar con este. El
caso es que necesito recuperar un resultado despues de la ejecución de un
procedimiento. Si lo ejecuto desde el codigo de mi aplicación, nunca me
devuelve el resultado, si lo hago desde el analizador de consultas sql en
modo depuración, si que devuelve el valor que yo necesito. Acaso no lo pongo
bien?:

Dim intReturn as integer
.
'Previa asignacion de valores a parametros
intReturn = myDataAdapter.InsertCommand.ExecuteNonQuery()

En el procedimiento:

CREATE PROCEDURE prpInsertCustomer
@idClientePK int output,
@otros parametros

AS
IF @@error = 0 BEGIN
COMMIT
END ELSE BEGIN
SELECT @IdClientePK = 0
ROLLBACK TRAN
END

RETURN @IdClientePK

GO

Ven ustedes algo mal en este procedimiento?

Gracias a todos por vuestras respuestas.

JoséMiguel

Preguntas similare

Leer las respuestas

#6 Carlos Sacristan
20/11/2003 - 10:44 | Informe spam
Manuel, el tema que comentas de código SQL que funcione en todas las
bases de datos me parece una utopía. Además, yo soy de la opinión que si
estás trabajando con un motor, intenta sacarle toda su potencia. Si te
limitas a los estándares te aseguro que te quedarás en la superficie, sin
saber exactamente de lo que es capaz. Toda migración supone un problema, y
nunca será de un día para otro (y si te dicen eso, no saben de lo que están
hablando): será un proyecto que se acometerá de la mejor forma posible, pero
siempre en su momento y con tiempo suficiente para realizarlo.



Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)
MVP SQL Server
Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"Manuel Conde" escribió en el mensaje
news:bphvil$1nulrs$
Hola Jesús.

Estoy de acuerdo en ke un SP es mucho más ke un select, de hecho hay


ciertos
procesos complejos ke "tiran" mucho de la BD ke es mejor hacerlos así.


Pero
lo ke yo kería decir es ke para hacer un simple select no creo ke sea
necesario toda esa parafernalia de líneas de código.

T-SQL está muy bien, pero yo ahora te digo (es un suponer, claro): "no
estamos contentos con nuestro ISP y hemos migrado el servicio a otro ke
emplea Oracle en lugar de SQL Server. Mañana tiene ke estar funcionando el
servicio."

¿Ké haces? Porke si tienes montones de SP los tienes ke traducir todos
(suponiendo ke sepas usar PL-SQL) para mañana...

Lo peor de todo es si te piden una "demo" portable de tu site, ke debe
funcionar en Access.

Ah, respecto a arrastrar cosas al entorno automático del NET... de
automatismos de microsoft no kiero saber nada. Prefiero cortar y pegar
código hecho por mi, ke sé ké hace exactamente.

Manuel Conde (http://manuel.conde.name)
Maicrosoft LVP (www.maicas.net)


"SqlRanger" escribió en el mensaje
news:#
Todo el mundo debería seguir estos pasos para ejecutar un procedimiento
almacenado que devuelva un valor de retorno. Un procedimiento almacenado


es
mucho más que un select. En un procedimiento almacenado se puede hacer


casi
cualquier cosa que permita T-SQL, no es una simple select, puede tener
decenas de líneas de código T-SQL.

Además si te quieres ahorrar escribir código, prueba a arrastrar un
procedimiento almacenado desde el explorador de servidores a un componente


o
un formulario, verás como automáticamente se te crea el código que


configura
el comando. Luego sólo tienes que darle el valor de los parámetros y
ejecutarlo.


Saludos:

Jesús López
MVP Microsoft .NET

"No darás tropezón ni desatino que no te haga adelantar camino"


Respuesta Responder a este mensaje
#7 Manuel Conde
20/11/2003 - 13:39 | Informe spam
Bueno Carlos, ahí diferimos.

Te puedo asegurar ke proyectos medianos y pekeños son perfectamente
compatibles con SQL estándar. Inclusive grandes, si se tiene en cuenta el
cambio de BD en el diseño.

Evidentemente, es muy fácil coger y aprovechar toda la potencia de "tu" BD,
empleando las "facilidades" ke aporta para hacer cosas extrañas, como,
digamos, un iif en medio de una consulta SQL. También es cierto ke cada BD
tiene su tratamiento de fechas particular. Pero no es menos cierto ke la
gran mayoría de consultas en un proyecto son simples SELECT, DELETE, etc.

Simplemente has de tener una variable global ke indike al programa el tipo
de BD usada para que sustituya las "funciones especiales" y las fechas en
las consultas SQL preparadas al efecto y tienes un sistema ke operará bien
en cualquier BD que emplees. Ah, y lo hará de un día para otro...

Manuel Conde (http://manuel.conde.name)
Maicrosoft LVP (www.maicas.net)


"Carlos Sacristan" escribió en el mensaje
news:

Manuel, el tema que comentas de código SQL que funcione en todas las
bases de datos me parece una utopía. Además, yo soy de la opinión que si
estás trabajando con un motor, intenta sacarle toda su potencia. Si te
limitas a los estándares te aseguro que te quedarás en la superficie, sin
saber exactamente de lo que es capaz. Toda migración supone un problema, y
nunca será de un día para otro (y si te dicen eso, no saben de lo que


están
hablando): será un proyecto que se acometerá de la mejor forma posible,


pero
siempre en su momento y con tiempo suficiente para realizarlo.
Respuesta Responder a este mensaje
#8 Miguel Egea
20/11/2003 - 15:40 | Informe spam
Si bien estoy de acuredo que puedes hacer aplicaciones compatibles, ninguna
será lo más eficiente posible y hay situaciones en la que eso es un factor
determinante, por otra parte, solo para que veas que ni siquiera funcionan
igual, Slq-server usa por defecto el nivel de aislamiento read-committed del
standard ansi, mientras que oracle (según tengo entendido) usa Repeatable
read, que es un nivel un poquito inferior, por lo que ni siquiera dos
selects como Select * from Tabla , se comportan realmente igual, (aunque
naturalmente si aparentemente igual).
Sin perjuicio de lo que te comento, es cierto que si el requisito es que
funcione en varios gestores, no hay más opción que quedarse en la
superficie, pero si es una aplicación para tu empresa que ha comprado
SQL-Server no creo que mañana cambie a Oracle por que sí.
Si eres un ISV entonces cambia la cosa claro.


Saludos

Miguel Egea
Microsoft SQL-SERVER MVP
Brigada Anti-Cursores


"Manuel Conde" escribió en el mensaje
news:bpicmu$1ock9h$
Bueno Carlos, ahí diferimos.

Te puedo asegurar ke proyectos medianos y pekeños son perfectamente
compatibles con SQL estándar. Inclusive grandes, si se tiene en cuenta el
cambio de BD en el diseño.

Evidentemente, es muy fácil coger y aprovechar toda la potencia de "tu"


BD,
empleando las "facilidades" ke aporta para hacer cosas extrañas, como,
digamos, un iif en medio de una consulta SQL. También es cierto ke cada BD
tiene su tratamiento de fechas particular. Pero no es menos cierto ke la
gran mayoría de consultas en un proyecto son simples SELECT, DELETE, etc.

Simplemente has de tener una variable global ke indike al programa el tipo
de BD usada para que sustituya las "funciones especiales" y las fechas en
las consultas SQL preparadas al efecto y tienes un sistema ke operará bien
en cualquier BD que emplees. Ah, y lo hará de un día para otro...

Manuel Conde (http://manuel.conde.name)
Maicrosoft LVP (www.maicas.net)


"Carlos Sacristan" escribió en el mensaje
news:
>
> Manuel, el tema que comentas de código SQL que funcione en todas las
> bases de datos me parece una utopía. Además, yo soy de la opinión que si
> estás trabajando con un motor, intenta sacarle toda su potencia. Si te
> limitas a los estándares te aseguro que te quedarás en la superficie,


sin
> saber exactamente de lo que es capaz. Toda migración supone un problema,


y
> nunca será de un día para otro (y si te dicen eso, no saben de lo que
están
> hablando): será un proyecto que se acometerá de la mejor forma posible,
pero
> siempre en su momento y con tiempo suficiente para realizarlo.



Respuesta Responder a este mensaje
#9 Javier Loria
20/11/2003 - 19:20 | Informe spam
Hola SQL Ranger:
Respecto a tu posdata: La letra Q no es ANSI ni portable a otros
lenguajes, por ende no debe usarse :)

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
"SqlRanger" wrote in message
news:%
<Manuel>
Estoy de acuerdo en ke un SP es mucho más ke un select, de hecho hay ciertos
procesos complejos ke "tiran" mucho de la BD ke es mejor hacerlos así. Pero
lo ke yo kería decir es ke para hacer un simple select no creo ke sea
necesario toda esa parafernalia de líneas de código.
</Manuel>

<SqlRanger>
¿Quien ha dicho que ese procedimiento almacenado haga algo que pueda hacerse
con una simple select?
</SqlRanger>


<Miguel>
T-SQL está muy bien, pero yo ahora te digo (es un suponer, claro): "no
estamos contentos con nuestro ISP y hemos migrado el servicio a otro ke
emplea Oracle en lugar de SQL Server. Mañana tiene ke estar funcionando el
servicio."

¿Ké haces? Porke si tienes montones de SP los tienes ke traducir todos
(suponiendo ke sepas usar PL-SQL) para mañana...
</Miguel>

<SqlRanger>
Lo que haces es desde el principio hacer la aplicación independiente del
sistema de base de datos. Pero eso no significa que no vayas a usar
procedimientos almacenados en SQL Server. Debido a que por muy estándar que
quieras ser, no es posible escribir SQL compatible con todos los sistemas de
base de datos, al final te ves obligado a escribir SQL para cada sistema de
base de datos. Además si sólo utilizas el estándar, no estás sacando todo el
partido al sistema de base de datos. Los sistemas de base de datos son
caros, así que merece la pena sacarles todo el partido, si no, estaríamos
despilfarrando dinero.
</SqlRanger>

<Miguel>
Lo peor de todo es si te piden una "demo" portable de tu site, ke debe
funcionar en Access.
</Miguel>

<SqlRanger>
¿En Access? ¿para qué quiero yo Access si puedo instalar el MSDE a partir de
Windows 98?
</SqlRanger>

<Miguel>
Ah, respecto a arrastrar cosas al entorno automático del NET... de
automatismos de microsoft no kiero saber nada. Prefiero cortar y pegar
código hecho por mi, ke sé ké hace exactamente.
</Miguel>

<SqlRanger>
Ese automatismo que desprecias puede ahorrar mucho tiempo de desarrollo, y
el tiempo es oro. No creo que sea algo como para despreciar. Visual Studio
no meterá el procedimiento almacenado en algún oscuro sitio que no se sabe
lo que hace. Visual Studio genera código igual que tú y yo, pero más rápido
y sin errores, en un sitio bien accesible: en la región de código generado,
que se puede ver perfectamente y se sabe exáctamente lo que hace.
</SqlRanger>


Saludos:

Jesús López
MVP Microsoft .NET

"No darás tropezón ni desatino que no te haga adelantar camino"

PD: la q es una letra tan digna como cualquier otra. no veo motivo para
despreciarla.
Respuesta Responder a este mensaje
#10 Salvador Ramos
20/11/2003 - 20:03 | Informe spam
Manuel:

Y ya que hablamos de conseguir una compatibilidad total, penalizando el
rendimiento.

¿ Has conseguido hacer una left join entre dos tablas en un formato que sea
compatible entre Oracle y el resto de gestores que admiten la cláusula left
join ?

La verdad que yo no lo he conseguido.

Un saludo
Salvador Ramos
www.helpdna.net

"Manuel Conde" escribió en el mensaje
news:bpicmu$1ock9h$
Bueno Carlos, ahí diferimos.

Te puedo asegurar ke proyectos medianos y pekeños son perfectamente
compatibles con SQL estándar. Inclusive grandes, si se tiene en cuenta el
cambio de BD en el diseño.

Evidentemente, es muy fácil coger y aprovechar toda la potencia de "tu"


BD,
empleando las "facilidades" ke aporta para hacer cosas extrañas, como,
digamos, un iif en medio de una consulta SQL. También es cierto ke cada BD
tiene su tratamiento de fechas particular. Pero no es menos cierto ke la
gran mayoría de consultas en un proyecto son simples SELECT, DELETE, etc.

Simplemente has de tener una variable global ke indike al programa el tipo
de BD usada para que sustituya las "funciones especiales" y las fechas en
las consultas SQL preparadas al efecto y tienes un sistema ke operará bien
en cualquier BD que emplees. Ah, y lo hará de un día para otro...

Manuel Conde (http://manuel.conde.name)
Maicrosoft LVP (www.maicas.net)


"Carlos Sacristan" escribió en el mensaje
news:
>
> Manuel, el tema que comentas de código SQL que funcione en todas las
> bases de datos me parece una utopía. Además, yo soy de la opinión que si
> estás trabajando con un motor, intenta sacarle toda su potencia. Si te
> limitas a los estándares te aseguro que te quedarás en la superficie,


sin
> saber exactamente de lo que es capaz. Toda migración supone un problema,


y
> nunca será de un día para otro (y si te dicen eso, no saben de lo que
están
> hablando): será un proyecto que se acometerá de la mejor forma posible,
pero
> siempre en su momento y con tiempo suficiente para realizarlo.



Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida