UDF y firebird 2.5

[guillotmarc]

Hola.

Ni idea sobre lo que te está fallando. Aunque para darte una alternativa, yo no utilizo UDF's, todas mis funciones las programo en procedimientos almacenados.

Por ejplo.

Código SQL [-]
SET TERM ^ ;

create procedure "asPrueba" (
    NUM numeric(15,2))
returns (
    RESULT numeric(15,2))
as
begin
  RESULT = NUM;
  suspend;
end
^

SET TERM ; ^

Ahora si quieres utilizar esta función en una consulta cualquiera, la puedes llamar como una subconsulta. Es decir:

Código SQL [-]
select  XXXX,
          (select RESULT from "asPrueba"(TABLA.CAMPO)) as IMPORTE
from TABLA

Gestionar tus funciones en procedimientos almacenados es más sencillo que hacerlo en librerías externas (es más sencillo hacer una instalación nueva, una restauración de un sistema, etc. ...). Y muy complejo tiene que ser el problema para que no lo puedas programar en T-SQL.

Saludos.

[ARPE]

Hola y gracias por la respuesta.
En lo posible uso procedimientos almacenados pero hay una serie de funciones en las que no me quedó otra (algunas de ellas por diversas circunstancias).
Estoy sobre un XP profesional SP3, ¿tiene algo que ver?, ¿hace falta alguna librería nueva para el fb2.5 (Microsoft.VC80.CRT.manifest, vccrt8_Win32.msi)?

[[duilioisola]]

Cuál es el error que te da?
- Error de permisos.
- Error de ejecución.
- No encuentra la UDF
- ...

[ARPE]

Hola, ¡qué fallo!, no le gusta a firebird da pocas pistas ¿verdad?

Desde una consulta me dice esto:
Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
Error writing data to the connection.



Desde la aplicación con IBO me dice esto:
Fallo al abrir "Tabla".
Objeto: tbTabla
SELECT ALL Tabla.*
FROM Tabla

ISC ERROR CODE:335544741

ISC ERROR MESSAGE:

connection lost to database

[ARPE]

¡¡¡ Al fin !!!
Por lo visto FB 2.5 se ha vuelto más limpio y no le gusta "stdcall", las udf deben ser declaradas con "cdecl".
Opté por stdcall por esto:
"On Windows, the operating system APIs are stdcall and safecall. (Note that stdcall is more efficient than cdecl)."

Saludos

[Casimiro Noteví]

Tengo entendido que con cdecl quien llama a la función es el encargado de "limpiar" la pila recogiendo los parámetros utilizados, en cambio, con stdcall el encargado de esta tarea es la propia función llamada.

Visto de esta forma, a mí me parece mejor cdecl.

[ARPE]

Por eso decía que es más limpio, o lo limpia él o desconecta el servidor (con dos c******).
Saludos.