mmm, entiendo, aunque sería muy agradable tener esa caracteristica, tampoco es algo crucial, pues con un sencillo join se podria hacer lo mismo y en un caso muy complejo, pues con una consulta anidada que haga llamado a un "Stored Procedure" o una UDF si es que es necesaria (Según sea el caso).

En cuanto a lo del tipo de campo a partir de uno de una tabla y el link que te pasé, ¿Si era a lo que te referias?

Con Firebird
 

Código SQL [-]
create procedure get_nombre_cliente (nocliente dominio_cliente)
returns (nombrecliente dominio_nombre_cliente)
as
begin
  select nombrecliente
  from clientes
  into :nombrecliente;
  suspend;
end

en delphi

Código Delphi [-]
select nopedido,codigocliente,get_nombre_cliente(codigocliente), from pedidos_header

Lo que sucede Kipow es que en Firebird no puedes tratar un procedimiento almacenado como si fuera una función... que es en "otras palabras" lo que dice ASAPLTDA, tu no puedes hacer:

Código SQL [-]
select nopedido,codigocliente,get_nombre_cliente(codigocliente), from pedidos_header

Pues tendrias que hacerlo asi, para lograr el "efecto":

Código SQL [-]
select nopedido,codigocliente, (select nombrecliente from get_nombre_cliente(codigocliente)) NOMBRE_CLIENTE, from 
pedidos_header

Por lo que para este sencillo caso, sería lo mismo o aún mejor hacer...

Código SQL [-]
select h.nopedido, h.codigocliente, c.nombrecliente NOMBRE_CLIENTE, 
from pedidos_header h, clientes c
where c.codigocliente=h.codigocliente

Perdon mi error jeje, no lo probe antes.

Cualquiera puede confundirse, pues el asunto es bastante parecido. ;)

Join de Tablas
 

Por favor disculpen la parrafos en mayuscula

Por lo que para este sencillo caso, sería lo mismo o aún mejor hacer...

Código SQL [-]
select h.nopedido, h.codigocliente, c.nombrecliente NOMBRE_CLIENTE, 
from pedidos_header h, clientes c
where c.codigocliente=h.codigocliente

[/quote]

Es cierto que el join de tablas es bueno, pero en algunos casos tienen un limite por ejemplo en la busqueda de valores dependientes de otras tablas o tablas con muchas relaciones externas por ejemplo un maestro de clientes facilmente podria tener 5 a 10 relaciones (Ojo Se que se puede crear con una vista y luego reutilizar la vista)
por Ejemplo asumamos que con el prefijo del telefono puedo encontrar el estado(State) del cliente

Código SQL [-]
CREATE TABLE CLIENTES
 CLIENTE CLIENTE ,
 PREFIJO_TELEFONO,
 CONTINENTE CONTINENTE
 PAIS PAIS
 CIUDAD CIUDAD

CREATE TABLE PAISES
PAIS PAIS
PAIS_NOMBRE

Código SQL [-]
 CREATE TABLE CIUDADES
 CIUDAD CIUDAD
 CIUDAD_NOMBRE

CREATE TABLE EMPLEADOS
EMPLEADO EMPLEADO
PAIS PAIS
CIUDAD CIUDAD


SELECT CLIENTE, PAIS_NOMBRE, CIUDAD_NOMBRE FROM CLIENTES C
LEFT OUTER JOIN PAISES P ON C.PAIS= P.PAIS
LEFT OUTER JOIN CIUDAD X ON X.CIUDAD= C.CIUDAD

y asi podemos complicar un join bastante, pero si hacemos funciones que en el manual dice que son de resultado tabla(VARIAS CAMPOS) PODEMOS HACER LAGO PARECIDO A ESTO OJO SIN PROBAR HE LEIDO EL MANUAL SOLAMENTE

Código SQL [-]
CREATE FUNCTION UBIC GEOGRAFICA(P_PAIS, P_CIUDAD)
RETURNA TABLA
SELECT PAISNOMBRE FROM PAISES INTO O_PAIS_NOMBRE;
SELECT PAISNOMBRE FROM PAISES INTO O_CIUDAD_NOMBRE;
RETURN PAISNOMBRE, CIUDAD_NOMBRE

LA INTRUCCION ANTERIOR QUEDARIA COMO ESTO

Código SQL [-]
 SELECT CLIENTE, UBIC GEOGRAFICA(PAIS,CIUDAD) FROM CLIENTES C

usando la funcion para el maestro de empleados quedaria

Código SQL [-]
 SELECT EMPLEADO, UBIC GEOGRAFICA(PAIS,CIUDAD) FROM EMPLEADOS C

y aqui iniciamos a tener el un mayor poder y ademas reutilizando la mismas funcion, esto msi lo he probado en DB2 del sistema as400 y funciona

Si todo esto es correcto abre nuevas alternativas a la programacion via SQL, esto posiblmente lo tendra firebird en la version 3 pero falta al menos 1 año para poder usarlo

ASAPLTDA Pues te comento que el manejo de funciones en Firebird no es nada nuevo, simplemente que el manejo de las mismas no es al que estamos acostumbrados en SQL Server, como nos mostró Jhonny en al caso de un procedimiento almacenado.