Cobol Foro

Cobol Foro (https://www.cobolforo.es/index.php)
-   Bases de datos (https://www.cobolforo.es/forumdisplay.php?f=27)
-   -   [MySQL] Sentencias PREPARE y EXECUTE (https://www.cobolforo.es/showthread.php?t=344)

Josber 3 de marzo de 2016 20:06
Sentencias PREPARE y EXECUTE
 
¿Alguien ha utilizado alguna vez las sentencias PREPARE, EXECUTE y EXECUTE INMEDIATE en PWC?

Estoy intentando usarlas y me da error de sentencia mal construida, (error 37000)

Un saludo y gracias.-

Kuk 11 de marzo de 2016 09:11
Josber, he echado un vistazo, y la verdad es que no me he enterado muy bien de qué va exactamente. En teoría, el PREPARE crea una especie de instancia de una query y por ello reduce el costo en caso de múltiples llamadas con la misma query (pero diferentes valores).

Vamos al grano. He leído que estas posibilidades pertenecen a la versión MySQL 5.7 que según Wikipedia es la última versión estable (22 de octubre de 2015; hace 4 meses). Lo cual quiere decir que para programar con SQL embebido sería necesario hacer un upgrade del precompilador/preprocesador de SQL.

No sé para qué lo necesitas, pero a lo mejor podrías utilizar cursores?

Josber 12 de marzo de 2016 10:16
A ver Kuk, como dijo Jack el destripador, "vamos por partes" ...

- Utilizo la última versión de MySql, por lo que eso no es problema.

- Necesito la sentencia PREPARE por lo que tú comentas, es para una misma consulta repetitiva con distintos valores, pero además ha de ser esta sentencia porque la tengo que montar con un STRING, por lo que no me vale una consulta estandar.

- Por lo menos yo, la sentencia DECLARE, la utilizo siempre junto con la sentencia CURSOR, he intentado usarla como un PREPARE, pero no me ha funcionado y, como supongo que sabrás, un CURSOR va asociado a una lectura secuencial con FETCH, por lo que tampoco me vale. Puedo hacer el bucle con el FETCH y a la primera lectura salirme del bucle, pero aparte de ser más lento, no dá el resultado esperado.

Sigo investigando.

Gracias y un saludo.-

Kuk 12 de marzo de 2016 15:46
Cita:
Citación del post de Josber (Mensaje 1680)
Utilizo la última versión de MySql, por lo que eso no es problema.
El problema es que el precompilador SQL de PowerCOBOL no sabe interpretar estas sentencias, es a lo que me refería.

Además, con el CURSOR justamente se hace lo que quieres. Si necesitas hacer la misma consulta varias veces, por ejemplo extraer varios clientes, se hace un cursor y en el WHERE se le pone la condición para que extraiga los que tu necesitas y los vas obteniendo uno a uno en el FETCH.

Josber 12 de marzo de 2016 22:48
Cita:
Citación del post de Kuk (Mensaje 1684)
Además, con el CURSOR justamente se hace lo que quieres. Si necesitas hacer la misma consulta varias veces, por ejemplo extraer varios clientes, se hace un cursor y en el WHERE se le pone la condición para que extraiga los que tu necesitas y los vas obteniendo uno a uno en el FETCH.
No lo necesito así kuk, de una consulta con un WHERE, que es lo que hago. si son varios registros, me da lo mismo que sean 2 que 5000, sólo necesito el primero, por eso no lo quería hacer con un FETCH.

Un saludo.-

Kuk 12 de marzo de 2016 23:50
Cita:
Citación del post de Josber (Mensaje 1686)
sólo necesito el primero
No entiendo a qué te refieres... Cual es la diferencia entre ejecutar la misma query varias veces con distinto identificador (que es lo que pretendes con PREPARE) y hacer un cursor?... :confused:

Josber 13 de marzo de 2016 12:01
Cuando declaras un CURSOR, es como hacer un START en un fichero COBOL y la sentencia FETCH es como un READ fichero NEXT RECORD ..., es decir una lectura secuencial, cargas en memoria en una tabla virtual toda la consulta

Código COBOL:
  1.       MOVE POW-NUMERIC OF CAMPO1 TO WB1.
  2.       MOVE POW-NUMERIC OF CAMPO2 TO WB2.
  3.       EXEC SQL
  4.               DECLARE cursor_CON CURSOR FOR
  5.                            SELECT * FROM CLIENTES
  6.                            WHERE CLICOD BETWEEN :WB1 AND :WB2
  7.                            ORDER BY CLINOM ASC
  8.       END-EXEC.
  9.  
  10.        EXEC SQL
  11.                OPEN cursor_CON
  12.        END-EXEC.
  13.  
  14.        PERFORM CARGAR THRU FIN-CARGAR UNTIL SQLSTATUS = "02000".
  15.  
  16.        EXEC SQL
  17.                CLOSE cursor_CON
  18.        END-EXEC.
  19.  
  20.        EXIT PROGRAM.
  21.  
  22. CARGAR.
  23.        EXEC SQL
  24.                FETCH cursor_CON
  25.                          INTO :CLICOD,
  26.                                  :CLINOM,
  27.                                        .
  28.                                        .
  29.                                        .
  30.        END-EXEC.

Cuado usas la sentencia PREPARE, es como una lectura normal de un registro en COBOL, (READ fichero KEY IS ... INVALID KEY ...), si la consulta no varía, te vale con un simple SELECT, pero si varía, tienes que montar la instrucción de busqueda con un STRING, y utilizar un PREPARE, poque no hay otra manera de hacerlo, no puedes hacer un SELCT + el STRING de búsqueda, que es lo que yo necesito.

Código COBOL:
  1.       MOVE POW-NUMERIC OF CAMPO1 TO WB1.
  2.       STRING "SELECT * FROM CLIENTES WHERE CLICOD = "
  3.                  WB1
  4.                 " LIMIT 1 INTO :CLICOD, :CLINOM , etc ..." DELIMITED BY SIZE INTO SQLCON
  5.       END-STRING.
  6.  
  7.       EXEC SQL
  8.               PREPARE consulta FROM :SQLCON
  9.       END-EXEC.
  10.  
  11.       EXEC SQL
  12.                EXECUTE consulta
  13.       END-EXEC
  14.  
  15.       EXEC SQL
  16.               COMMIT
  17.       END-EXEC.

Pero me da la sensación que la sentencia PREPARE y EXECUTE, el compilador no las acepta y es una ****da, porque se utilizan bastante en SQL.

Un saludo

Kuk 13 de marzo de 2016 15:24
Josber, gracias por el ejemplo, no conocía el PREPARE y el EXECUTE.

No es que te esté vacilando pero... Sigo sin entenderlo. :D Según tu código lo que varía es WB1, es eso? Es decir, necesitas ejecutar varias veces la misma consulta pero con WB1 distintos. ¿Es eso?

En cuanto al CURSOR: no es un start, es un SELECT + ORDER BY por decirlo de alguna forma. el FETCH no es una lectura secuencial sino lectura uno a uno de lo que el SELECT ha traído. Todo depende efectivamente del WHERE. Puedes hacer:

Código SQL:
  1. SELECT * FROM CLIENTES
  2.  WHERE CLICOD BETWEEN :WB1 AND :WB2
  3.  
  4. -- o también
  5. SELECT * FROM CLIENTES
  6.  WHERE CLICOD BETWEEN IN (...)
  7.  
  8. -- o también
  9. SELECT * FROM CLIENTES
  10.  WHERE CLICOD BETWEEN = ... OR ...

Si lo que varía es el SELECT * pues tampoco veo mayor problema...

Con todo esto quiero decir que no me estoy enterando en qué es imprescindible el PREPARE. Vale que se puede montar la query en dinámico pero normalmente se puede evitar.

Josber 13 de marzo de 2016 17:58
No te preocupes, no pienso mal, el ejemplo que he puesto es una pequeña parte, necesito el PREPARE, para consulta dinámica como tu dices, porque dependiendo de otras variables, el STRING puede llevar más campos de consulta, por ejemplo zonas, importes y así hasta 18 campos que pueden estar o no estar.

Un saludo.-

David 4 de mayo de 2021 17:26
Hola Josber

He leído con interés este post que has publicado

Cita:
Citación del post de Josber (Mensaje 1688)
Cuando declaras un CURSOR, es como hacer un START en un fichero COBOL y la sentencia FETCH es como un READ fichero NEXT RECORD ..., es decir una lectura secuencial, cargas en memoria en una tabla virtual toda la consulta

Código COBOL:
  1.       MOVE POW-NUMERIC OF CAMPO1 TO WB1.
  2.       MOVE POW-NUMERIC OF CAMPO2 TO WB2.
  3.       EXEC SQL
  4.               DECLARE cursor_CON CURSOR FOR
  5.                            SELECT * FROM CLIENTES
  6.                            WHERE CLICOD BETWEEN :WB1 AND :WB2
  7.                            ORDER BY CLINOM ASC
  8.       END-EXEC.
  9.  
  10.        EXEC SQL
  11.                OPEN cursor_CON
  12.        END-EXEC.
  13.  
  14.        PERFORM CARGAR THRU FIN-CARGAR UNTIL SQLSTATUS = "02000".
  15.  
  16.        EXEC SQL
  17.                CLOSE cursor_CON
  18.        END-EXEC.
  19.  
  20.        EXIT PROGRAM.
  21.  
  22. CARGAR.
  23.        EXEC SQL
  24.                FETCH cursor_CON
  25.                          INTO :CLICOD,
  26.                                  :CLINOM,
  27.                                        .
  28.                                        .
  29.                                        .
  30.        END-EXEC.

Cuado usas la sentencia PREPARE, es como una lectura normal de un registro en COBOL, (READ fichero KEY IS ... INVALID KEY ...), si la consulta no varía, te vale con un simple SELECT, pero si varía, tienes que montar la instrucción de busqueda con un STRING, y utilizar un PREPARE, poque no hay otra manera de hacerlo, no puedes hacer un SELCT + el STRING de búsqueda, que es lo que yo necesito.

Código COBOL:
  1.       MOVE POW-NUMERIC OF CAMPO1 TO WB1.
  2.       STRING "SELECT * FROM CLIENTES WHERE CLICOD = "
  3.                  WB1
  4.                 " LIMIT 1 INTO :CLICOD, :CLINOM , etc ..." DELIMITED BY SIZE INTO SQLCON
  5.       END-STRING.
  6.  
  7.       EXEC SQL
  8.               PREPARE consulta FROM :SQLCON
  9.       END-EXEC.
  10.  
  11.       EXEC SQL
  12.                EXECUTE consulta
  13.       END-EXEC
  14.  
  15.       EXEC SQL
  16.               COMMIT
  17.       END-EXEC.

Pero me da la sensación que la sentencia PREPARE y EXECUTE, el compilador no las acepta y es una ****da, porque se utilizan bastante en SQL.

Un saludo

El cual aporta el trato de un tema muy interesante.
En mi caso he pensado en utilizar el PREPARE para construir el CURSOR, sigo investigando, pero me preguntaba si después de varios años, uds. han logrado algo más del información


Saludos


La franja horaria es GMT +2. Ahora son las 13:07.

Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.