...ahora necesito trabajar los insert, update y delete...tengo los procedimientos creados los probe en el analizador del SQL server...ahora mi duda es como los ejecuto desde ASP...??.... 
09/03/2005, 09:24
| |||
| |||
 como se llama un procedimiento almacenado inser, update o delete desde ASP Hola, estoy trabajando las consultas a mi base de datos con procedimientos almacenados...no soy muy experta aun... ...ahora necesito trabajar los insert, update y delete...tengo los procedimientos creados los probe en el analizador del SQL server...ahora mi duda es como los ejecuto desde ASP...??.... |
|
09/03/2005, 11:43
| ||||
| ||||
|
__________________ "El hombre que ha empezado a vivir seriamente por dentro, empieza a vivir más sencillamente por fuera." -- Ernest Hemingway |
|
09/03/2005, 13:29
| |||
| |||
| mmm..quizas no me explique....o no entiendo bien  ...los procedimientos que estaba ocupando simplemente me llenaban un recordset con los valores que necesitaba pero ahora necesito inserta, actualizar o borrar valores...y no se bien como ocupar los procedimeintos...los codigo para ASP que vi utilizan objRS.addNew y objRS.Update...y no se bien como insertar el procedimiento que me actualiza con esa informacion....es eso....espero se entienda.... |
|
09/03/2005, 13:53
| ||||
| ||||
| Lo mismo que U_G, busca en las respuestas anteriores. Nota: En un procedimiento almacenado, puedes hacer hacer simples select, inserts, delete's o lo que quieras usando T.-SQL (en el caso de SQLServer), la invocación es basicamente la misma, solo cambia si lo usas mediante un ADODB.command o asignas el resultado de su ejecución a un RecordSet. |
|
09/03/2005, 14:01
| ||||
| ||||
| supongo es una expresion de desagrado por parte de Muzztein a que U_G te dió la recomendación de buscar en las respuestas anteriores e incluso una la liga y pese a ello, replicaste con un comentario quizá claro de que no has hecho pruebas por tu parte. No te molestes, pero el 85% (o más) de lo que se pregunta, ya ha sido contestado antes. Sin afan de ofender, claro. |
|
09/03/2005, 14:23
| ||||
| ||||
| No problema. Mira, quizá pagan justos por pecadores y esta vez te tocó. Lo siento. Esto no es por tí, lo aclaro, pero la verdad es que si bien los foros estan para ayudar, no es su idea principal el hacer el trabajo de los demás o evitarles buscar en google. En tu caso varás, una vez que busques, que hay dos formas principales de llamar a los SP, una mediante el recordset y otra por medio del Command: Cuando requieres que el SP regrese un cursor:
Código:
Cuando el SP ejecutará un INSERT, UPDATE o algo que no regresará un cursor pero puede (o no) regresar parámetros de salida:set adoRs = Server.CreateObject("adodb.recordset")
sQuery="Execute sEstados <lista de parametros>"
set adoRs=adoConn.Execute(sQuery)
Código:
Como ves, es fácil, solo hay que probar. En esta segundo opción se hace uso de las constantes definidas en el archivo adovbs.inc que puedes conseguir en en internet.set cmd=server.CreateObject("ADODB.command")
Set cmd.ActiveConnection = adoConn
cmd.CommandText = "uActualizaDep"
cmd.CommandType=adCmdStoredProc
cmd.Parameters.Append (cmd.CreateParameter("Id_Dep", adInteger, adParamInput, 4, vIdDep))
cmd.Parameters.Append (cmd.CreateParameter("Titular", adVarChar, adParamInput, 50, vTitular))
cmd.Parameters.Append (cmd.CreateParameter("Dir_Admvo", adVarChar, adParamInput, 50, vDirector))
cmd.Parameters.Append (cmd.CreateParameter("BanOk", adVarChar, adParamOutput, 2))
cmd.Execute
cmd = null
Saludos  |
|
09/03/2005, 21:51
| |||
| |||
| Pues yo estoy más verde que todo eso, y pregunto: ¿para qué sirven los procedimientos almacenados? :D ¿No puedo usar órdenes desde la propia aplicación ASP y ya está? (claro que puedo, pero qué ventajas traen dichos procedimientos. Me imagino que las mismas que las funciones: cuando algo se vaya a repetir mucho, simplemente llamarlo cada vez que lo vayas a usar). Saludos |
|
10/03/2005, 09:05
| ||||
| ||||
| No tanto.  Los procedimientos almacenas traen la principal e indiscutible ventaja de que separan la capa de base de datos de la de presentación y reglas del negocio. Además quitan trabajo al servidor web y lo enfoca en el servidor de bases de datos; puedes hacer uso de todo lo que te permita el lenguaje del servidor como enviar correos desde el SQLserver, por ejemplo; los ejemplos que encuentras en la red sobre sqlinjection esta basado, si te fijas, sobre códigos con las intrucciones en el ASP, lo que es más inseguro, dado que si utilizas SP's y Triggers y solo das permisos de ejecución al usuario de la sesión, te olvidas de ese problema. En fin, son mucho más útiles que solo para encapsular código. |
|
10/03/2005, 11:09
| ||||
| ||||
| Si, coincido, aunque realmente, si vas a trabajar en el mismo servidor(aplicacion-base de datos), el performance de tu aplicacion no aumentara drasticamente, en realidad, seria mas una cuestion de mayor seguridad com lo apunta el master Myak, pero tiene tambien sus desventajas, si trabajas con sentencias dinamicas, los filtros que implementas crecen exponencialmente, y al rato tienes un codigo enorme(mucho mas que haciendolo del lado de la aplicacion en ASP), lo cual es un problema mayor para el mantenimiento de la aplicacion. Como siempre mis $0.02 Salu2,
__________________ "El hombre que ha empezado a vivir seriamente por dentro, empieza a vivir más sencillamente por fuera." -- Ernest Hemingway |
|
10/03/2005, 11:42
| ||||
| ||||
| Nunca mi estimado Myak, solo es que precisamente estaba investigando un poco sobre este tema, y precisamente, ahora me contradigo yo mismo...segun este articulo NO usen stored procedures http://weblogs.asp.net/fbouma/archiv.../18/38178.aspx Salu2,
__________________ "El hombre que ha empezado a vivir seriamente por dentro, empieza a vivir más sencillamente por fuera." -- Ernest Hemingway |
|
10/03/2005, 12:32
| ||||
| ||||
| patrañas! los procedimientos almacenados son LA manera correcta de trabajar. Junto con todo lo que dice Myakire, y en contrario a lo que dice u goldman. Los PA SI hacen una mejora en el performance de las consultas. Ya que cuando uno manda a ejecutar un complicda consulta "a lo mero macho" contra el servidor SQL, este levanta un interprete, el cual , valga la redundancia, interpreta el codigo y ejecuta sus ordenes. Por el contrario , un PA queda compilado dentro del servidor sql, ejecutando la consulta, obviamente, mas rapido. |
|
10/03/2005, 12:37
| ||||
| ||||
| Muzz, date un tiempo para leer el articulo, no lo invente yo, que tambien pensaba que estaban compilados, bueno, no lo estan se compilan en tiempo de ejecucion: Cita: Salu2, Performance Everyone who thinks stored procedures are pre-compiled, say "Aye!". Whoa, what a noise! For all of you who said "Aye!" a few seconds ago: open SqlServer's Books Online (v7 or v2000, doesn't matter), search for "cache execution plan". You'll find fine articles like "Execution Plan Caching and Reuse" and "SQL Stored Procedures". Let me just quote some lines from the "SQL Stored Procedures" article: SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans. I didn't make that up, people. It's there, for a long time (since SqlServer 7.0). However, what does Rob Howard say? I quote: There are also internal performance benefits to SQL Server for using stored procedures vs. ad-hoc SQL script. When stored procedures are used SQL Server can cache or pre-compile the ‘execution plan’ that it uses to execute the SQL vs. having to recalculate the execution plan on each request.
__________________ "El hombre que ha empezado a vivir seriamente por dentro, empieza a vivir más sencillamente por fuera." -- Ernest Hemingway |
|
10/03/2005, 12:46
| ||||
| ||||
| Bueno, interesante el artículo. Aunque me hizo recordar los artículos de Sun y de Microsoft sobre su respectiva versión de "Pet Shop" hecha en java y C# respectivamente; es decir, son tendenciosos en sus respectivos puntos de vista. Por ejemplo, en cuanto a la seguridad, el artículo habla de sustituir los SP por seguridad basada en roles, o consultas parametrizadas por ADO.NET; esto deja fuera a los scriptlets que no usan el framework de .net y no considera a las aplicaciones Web que necesitan que el usaurio tenga rol de administrador, ya que puede editar o borrar registros. Al menos menciona las vistas, por lo menos. Tambien señala que el utilizar códigos como s = "SELECT * FROM Foo WHERE Bar = " + barValue; no es la forma correcta, sino programando un componente que genere el SQL al vuelo, bueno, cierto, así sería mucho más fácil el mantener la aplicaicón, PERO, ¿cómo vas a ejecutar ese componente con una tarea programada o como vas a enviar correos basados en cursores (los cursores son otro aspecto que también estan en entredicho)? Cuestión de seguir investigando. Saludos |
|
10/03/2005, 12:54
| ||||
| ||||
| ¡ups! No habia visto el "pleito" entre estos dos amigos. Supongo que al igual que la famosa "Pet Shop" (que por cierto Microsoft la hizo despues que sun y la hizo basada en la primera y solo para debatirle a java) ambos tienen un poco de razón. La verdad ya sabía que los SP son compilados en ejecución (como los JSP -solo la primera vez-), pero lo cierto es que desconozco a fondo el funcionamiento de los mismos en cuanto a rendimiento. Pero me es muy lógico pensar que pese a ello, deben de tener un rendimiento mayor que ejecutar una consulta desde el servidor Web (por que normalmente, el servidor web NO ES o por lo menos NO DEBE ser el mismo que el servidor de BD). Habrá que seguir investigando para poder hablar 100% con la verdad (si es que eso es posible), por lo que nos limitaremos a hablar con la experiencia. Y esta me dice que tanto una forma como la otra tienen pros y contras. Saludos |
|
10/03/2005, 12:58
| ||||
| ||||
| Asi es, por eso precisamente comence con decir que me parece cierto, si no son compilados y viven en el mismo servidor(aplicacion-base de datos), el preformance no seria mucho mejor, pero por otro lado, me parece que la seguridad si, pese a que dice que se puede implementar a base de roles, que tambien es un tanto cierto, aunque tener separados estos dos aspectos, siempre ofrece un plus a la seguridad, como dices, seguiremos en la investigacion Salu! que manana es viernes!
__________________ "El hombre que ha empezado a vivir seriamente por dentro, empieza a vivir más sencillamente por fuera." -- Ernest Hemingway |
