6 respuestas en este tema

[fredycc]

Hola delphinianos, quiero mostrar otro potencial de Lazarus, esta vez con relación a base de datos, en este caso para Firebird/Interbase y es que me ví en la necesidad un buen día de incorporar ciertas funciones poco usuales (CURP, RFC, MONTOS) con el fin de dejar de lado de firebird ciertas tareas.

Estas UDF's pueden ser implementadas en distribuciones de Firebird/Interbase sobre Windows o Linux es en este último punto donde opté por Lazarus por mi necesidad de no limitarme a una plataforma.

Tienen ciertas limitantes conocidas mis udf's pero voy a seguir mejorándolas.

https://sites.google...elopments/udf-s

Espero les agrade.

Saludos

[egostar]

Que interesante forma de abordar el asunto, muchas gracias amigo fredycc

Salud OS

[Marc]

Felicidades, está muy bien tu librería.

Aunque en lugar de desarrollarla como UDF, yo la haría directamente en PSQL, en un procedimiento almacenado. Es igual de fácil de utilizar en consultas, etc. ..., y te evita problemas en la distribución, posibles incompatibilidades en el futuro, etc. ...

Saludos.

[Marc]

Ejemplo de utilización de un procedimiento almacenado como una función :

Si tenemos la función Montos, que nos devuelve el texto de un importe, al igual que en una consulta normal (con una UDF) tendríamos :

select TOTAL, montos(TOTAL)
from FACTURA
where ID = :ID

Si nos definimos un procedimiento almacenado que devuelve esa cantidad, ahora podemos repetir esa misma consulta (aunque esta vez sin UDF's, solo con procedimientos almacenados) :

select TOTAL, (select MONTO from sp_montos(TOTAL))
from FACTURA
where ID = :ID

NOTA: No hay que olvidarse de poner un SUSPEND; al final del cuerpo del procedimiento almacenado, para que los valores de los parámetros de salida se devuelvan también como un Dataset.

Saludos.

[fredycc]

Interesante detalle Marc, no cabe duda que siempre se aprende algo nuevo, me recuerdas al ejemplo para generar xml apartir de PSQL muy interesante por cierto, de nuestro colega Fernando: http://fernandomedeiros.com.br/blog/ y me parece muy útil que se basa en dos sp's solamente, el único detalle que le veo; es que si alguién más accesara como sysdba podría modificar mis sp's; hay algún detalle para evitar ese pequeño inconveniente.

Saludos

[Marc]

Bueno, hay una solución a medias.

Puedes esconder el código de tu procedimiento almacenado :

http://www.firebirdfaq.org/faq32/

Con esto no podrán ver tu código y por tanto no podrán modificarlo. Claro que siguen teniendo acceso SYSDBA así que pueden borrar el procedimiento almacenado y reescribirlo, pero al menos no pueden usar tu código, tendrán que reescribirlo de cero.

Eso es parecido a lo que tendrías con las UDF's. Si tienen acceso SYSDBA pueden eliminar la declaración de la UDF, subir su propia librería y declarar de nuevo la UDF, para ejecutar su propio código.

Y es que realmente poca protección puedes tener contra alguien que tenga acceso SYSDBA.

NOTA: Cuidado con ir ocultando el código de los triggers y los procedimientos almacenados. Eso solo hay que hacerlo en las bases de datos para los clientes. Si también lo haces en tus bases de datos de desarrollo, serás incapaz de recuperar ese código si algún día lo quieres modificar.

Saludos.

[fredycc]

Muchas gracias Marc por la información  . Lo voy ha probear

En MS SQL es parecido hasta donde sé, pero me parece que en MS SQL server se podía cachar el sp cuando minitoreabamos las transacciones en el monitor de SQL Server, no se si pasaría lo mismo con firebird.

Y de este modo obtener el sp, y tener el código del mismo y modificarlo, ya no desde 0. Es esto posible?