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

Siga el debate

16 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#11 Manuel Conde

21/11/2003 - 09:56 | Informe spam

Hola Salvador.

Precísamente cada BD tiene alguna diferencia con las demás, mismo el caso de
tratamiento de fechas vale también como ejemplo. Yo no estoy diciendo ke
existan consultas SQL universales para todas las BDs y que hagan todas las
cosas posibles, sino que con SP no podrás hacer lo ke te pongo a
continuación.

Lo ke yo hago para ke mis aplicaciones sean multiBD es emplear la consulta
común y según la BD tratada, separar las partes si es el caso.

Te pongo un ejemplo de una que estoy haciendo ahora ke debe poder emplearse
en Informix (para una organización en concreto) y en Access (para sistemas
baratos monousuario). El ejemplo es uno de los peores, porque se necesita un
outer join y en Access para hacer uno es un coñazo, mientras ke en Informix
es muy sencillo (igual ke sería en Oracle). Cuando son siempre Inner Join,
la consulta es igual en Access e Informix (u Oracle).

Sql = "select GH.NUMEROHC," _
& " TC.TIPO_CIRUGIA, C1.NOMB As CIRUJ" _
& " from "

Select Case GkBD
Case 0
'Access
Sql = Sql _
& " PERSCLIN C1 right join (" _
& " FICUS FI right join (GQ_HIST GH left join (" _
& " GQ_HIST_PLUS GHP left join TIPOS_CIRUGIA TC" _
& " on (GHP.COD_TIPO_CIRUGIA = TC.COD_TIPO_CIRUGIA))" _
& " on (GH.NUMEROHC = GHP.NUMEROHC and GH.NUMICU_HOSP GHP.NUMICU_HOSP and GH.NUMICUQUIR = GHP.NUMICUQUIR))" _
& " on (GH.NUMEROHC = FI.NUMEROHC and GH.NUMICU_HOSP FI.NUMICU))" _
& " on (GH.CIRUJANO = C1.CODPERS))" _
& " on (GH.AYUDANTE1 = C2.CODPERS))" _
& " on (GH.AYUDANTE2 = C3.CODPERS)"
& " where GH.NUMEROHC = " & strNumHistoria _
& " and GH.NUMICU_HOSP = " & strNumEpisodio _
& " and GH.NUMICUQUIR = " & strNumIntervencion
Case 1
'Informix
Sql = Sql _
& " GQ_HIST GH," _
& " outer (GQ_HIST_PLUS GHP," _
& " TIPOS_CIRUGIA TC)," _
& " outer FICUS FI," _
& " outer PERSCLIN C1" _
& " where GH.NUMEROHC = " & strNumHistoria _
& " and GH.NUMICU_HOSP = " & strNumEpisodio _
& " and GH.NUMICUQUIR = " & strNumIntervencion _
& " and GH.NUMEROHC = GHP.NUMEROHC" _
& " and GH.NUMICU_HOSP = GHP.NUMICU_HOSP" _
& " and GH.NUMICUQUIR = GHP.NUMICUQUIR" _
& " and GHP.COD_TIPO_CIRUGIA = TC.COD_TIPO_CIRUGIA" _
& " and GH.NUMEROHC = FI.NUMEROHC" _
& " and GH.NUMICU_HOSP = FI.NUMICU" _
& " and GH.CIRUJANO = C1.CODPERS"
End Select

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

"Salvador Ramos" escribió en el
mensaje news:

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

> 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

> 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

> 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

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

Responder a este mensaje

#12 Manuel Conde

21/11/2003 - 10:13 | Informe spam

"SqlRanger" escribió en el mensaje
news:#
<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.
</SqlRanger>

Fíjate en eso ke has escrito, es contradictorio. Si haces una aplicación
independiente del SGBD no puedes usar procedimientos ke son dependientes del
SGBD. O haces una aplicación para un SGBD específico aprovechando todas sus
funcionalidades o la haces independiente.

<SqlRanger>
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>

Estoy de acuerdo en que tienes ke escribir SQL para cada BD, pero eso no
kiere decir ke en tu diseño no puedas escribir una aplicación multiBD. Lleva
más trabajo porke tienes ke contemplar las posibilidades, pero es factible.

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

Pues a lo mejor lo kieres porke tu aplicación debe ser vendida bajo Access,
ya ke el presupuesto para un programa en PYMES es pequeño y no se van a
gastar una pasta en una licencia de SQL Server u Oracle. Si tu aplicación es
buena, la puedes vender a una empresa con 2 empleados y a una con 50. Lo
único ke varía es la potencia de la BD para gestionar las operaciones con
muchos usuarios concurrentes.

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

Seguramente será como tú dices, pero de nuevo, en estos 6 años ke llevo de
automatismos de Microsoft me he llevado 6 años de decepciones. Me llevará
más tiempo (kizá 2 minutos más que el automatismo porke al final el código
siempre es parecido) hacer un Copy-Paste, pero así sé ke lo ke se hace es lo
ke yo he dicho ke se va a hacer.

<SqlRanger>
PD: la q es una letra tan digna como cualquier otra. no veo motivo para
despreciarla.
</SqlRanger>

Bueno, es simplemente una forma de "ganar" tiempo escribiendo, además de una
forma de identificarme cuando escribo. De todas formas, la k es también una
letra digna ke apenas se emplea en el diccionario español. :)

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

Responder a este mensaje

#13 Manuel Conde

24/11/2003 - 12:23 | Informe spam

<SqlRanger>
Quizá no me haya expresado bien. No es todo o nada, blanco o negro. Me
explico. La aplicación se construye en tres capas lógicas, una de acceso a
datos,
...
base de datos y tengo que escribir las vistas, y otros objetos en la base de
datos. ¿Mi aplicación saca todo el partido al sistema de base de datos? Sí.
porque está escrita para cada sistema en particular.
</SqlRanger>

Pufff, me acabas de dar una pequeña clase sobre las posibilidades del VS.NET

Estamos a niveles muy diferentes de conocimientos sobre NET. Veo que tú lo
dominas perfectamente, además de controlar de POO, mientras que yo de NET sé
la más básico, y esto es en cuánto se parece a VB6 y en "cómo se hace lo que
yo hacía en VB6". Siempre he tenido curiosidad por poder fabricar programas
con POO, pero siempre se me ha dado mejor hacerlo con programación
estructurada clásica. Mi especialidad es el cliente-servidor, que es a lo
que más tiempo he dedicado.

Todo eso que has contado parece muy interesante, sin embargo no dispongo de
tiempo hoy por hoy para empezar a trabajar así, dado que me llevaría cierto
tiempo de aprendizaje, del cuál tampoco dispongo. Así que yo, de momento,
sigo con mi programación estructurada, centralizando tantas funciones como
me es posible.

<SqlRanger>
No veo ninguna razón para necesitar Access. Tengo licencia para distribuir
Sql Server 2000 Desktop Engine (MSDE 2k) (instalable a partir de W98) al
tener una licencia de Visual Studio .NET 2003, con lo que a mi cliente no le
costaría un céntimo el sistema de base de datos
</SqlRanger>

¿Esa licencia también viene con Visual estudio 6.0? No recuerdo nada al
respecto. Lo digo porque hasta hace bien poco (unos 6 meses), es la que
teníamos.

<SqlRanger>
Es posible que en las anteriores versiones de los sitemas de desarrollo de
Microsoft, esos automatismos no funcionaran de forma aceptable y que fueran
...
</SqlRanger>

"Ahí le has dao". Ya sabes aquello de "cría fama...". La fama que Microsoft
se ha dado a sí misma es la de que sus "automatismos" son pésimos. Si ahora
han mejorado, me alegro mucho. Te puedo asegurar que el entorno de NET para
ASP ya me ha dado algún que otro quebradero de cabeza, que he tenido que
resolver a mi estilo: cambiando a mano lo que había hecho el entorno
automáticamente. No obstante lo tendré en cuenta para ciertas cosas.

Por cierto, no sabrás cómo demonios hacer para que el entorno deje de
sangrarme automáticamente el código en VB y se comporte como en VB6.
Configurándolo en las opciones no funciona correctamente, ya que hace cosas
raras. Lo he tenido que dejar en automático, porque las otras dos opciones
funcionan mal.

<SqlRanger>
Yo creo que al escribir al "estilo K" por llamarlo de alguna manera, no te
identifica, hay muchas personas que lo hacen. Sólo te identifica como una
más de las personas que escriben al "estilo K".

Ya sé que no me vas a hacer ningún caso, pero te agracedería que no
utilizaras la k de la manera que lo haces.

Por cierto yo no tengo nada en contra de la k, de hecho la uso (MSDE 2k, 128
Kbits/seg, Kg, KW-Hora) , lo que no me gusta es que se sustituya la "qu" por
la "k", me parece horrible y lo detesto.
</SqlRanger>

Bueno, en deferencia hacia ti, cuando te escriba msgs lo haré con qu en vez
de k. Sin embargo el "estilo K" normal no es el mismo ke el mío. Yo sólo
sustituyo la qu, mientras que lo normal en ese estilo es sustituir cualquier
cosa que suenen a K con una K (valga la redundancia), por ejemplo: kon,
kasa, cerka. Es un estilo más radical y ese sí que no me gusta a mi tampoco,
pero como cada uno es libre de escribir como quiera, pues nunca digo nada.

Eso sí, ten en cuenta que los lenguajes evolucionan, el castellano no será
menos, y son estas tonterías lo que hace que un lenguaje evolucione. El
castellano es muy complejo y tiene demasiadas cosas que suenan igual y se
escriben distinto. Por mi parte preferiría menos reglas gramaticales y más
sencillez, pero mientras no cambie (y no creo que sea durante mi vida, al
menos de forma clara), lo intentaré a mi manera. :)

Bueno, en cualquier caso, encantado de haber discutido este tema contigo,
una vez más me doy cuenta de lo mucho que me queda por aprender.

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

Responder a este mensaje

#14 SqlRanger

24/11/2003 - 14:24 | Informe spam

¿Esa licencia también viene con Visual estudio 6.0? No recuerdo nada al
respecto. Lo digo porque hasta hace bien poco (unos 6 meses), es la que
teníamos.

Con Visual Studio 6.0 tenías licencia para distribuir el MSDE 1.0 que
corresponde con SQL Server 7.0. Incluso el MSDE 1.0 se podía descargar de la
web de Microsoft desde la página de Visual Studio. No estoy seguro, puede
que eso se haya quitado.

El MSDE 2K se puede descargar de:

http://www.microsoft.com/downloads/...x?FamilyID dac778-60a6-4b11-
8aa8-bf12261a303a&DisplayLang=en

El MSDE 1.0 no lo he encontrado.

Saludos:

Jesús López
MVP Microsoft .NET
MCP SQL Server

Responder a este mensaje

#15 Manuel Conde

24/11/2003 - 15:04 | Informe spam

Hola de nuevo.

He ido a la dirección que me escribes abajo. Efectivamente, ese paquete ya
lo había yo instalado con el NET, pero según pone solo sirve para Win2000,
Win2003 y WinXP. Ya ni siquiera contempla NT, con lo cual me quedo sin BD
para Win98.

De todas fromas, gracias.

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

"SqlRanger" escribió en el mensaje
news:uzxh$

> ¿Esa licencia también viene con Visual estudio 6.0? No recuerdo nada al
> respecto. Lo digo porque hasta hace bien poco (unos 6 meses), es la que
> teníamos.

Con Visual Studio 6.0 tenías licencia para distribuir el MSDE 1.0 que
corresponde con SQL Server 7.0. Incluso el MSDE 1.0 se podía descargar de