Creo que nos estamos desviando mucho del tema, quizás lo que expongo ahora es demasiado para el tema que nos ocupa.

La filosofía:
- Primero comprobamos que el generador está creado en la BBDD, de lo contrario, lo creamos (habría que inicializarlo a un valor... pero no lo incluyo en el código).
- Ya que existe, y tiene un valor, lo incrementamos y recogemos su número.

Código Delphi [-]
const ExisteGen = 'SELECT RDB$GENERATOR_NAME FROM RDB$GENERATORS WHERE  RDB$GENERATOR_NAME = %s and RDB$SYSTEM_FLAG IS NULL' ;

const CreaGen = ' CREATE GENERATOR %s';

const IncrementaGen = 'SELECT GEN_ID(%s , 1) FROM RDB$GENERATORS WHERE  RDB$GENERATOR_NAME = %s AND  and RDB$SYSTEM_FLAG IS NULL';

begin
NombreGen:= 'Facturas_'+ inttostr(2007); // Nombre del Generador incluyendo el año

qry.sql.text := format( existeGen, [QuotedStr(NombreGen)]);
qry.Open;
if qry.IsEmpty then
begin  
// vaya por dios, el generador no existe en la BBDD,
// si intentamos consultar su valor nos daría una bonita excepción
   qry.Close;
   qry.sql.text := Format(CreaGen, [NombreGen]); // pos creamos el generador
   qry.ExecSql;
   // aquí podríamos establecer su valor a cero, (sería lo lógico)
end;

qry.sql.text := Format(IncrementaGen, [NombreGen, QuotedStr(NombreGen)]);
qry.Open;
Result := qry.Fields[0].AsInteger; // el valor del generador, incrementado en 1

He tenido un problemilla con Firebird 1.5, y es que en un Store Procedure no se puede hacer algo asï:

Código SQL [-]
create generator :NameGen

Donde NameGen es el parámetro de tipo string que se pasa al Store Procedure. Pues bueno, salvamos el escollo desde delphi que no tiene restricciones.

PD: El código está escrito de memoria, aunque los sqls han sido probado desde el SQL Editor de IB Expert Personal.

Consecuencias de usar este método:
- El número de factura solo se pediría al guardar definitivamente la factura.
- Estando en red, podría dar fallos al crear los generadores, igual se podrían crear 50 generadores desde el principio, y así obviamos el tener que comprobar que existen y que tienen asignados un valor.

Saludos

Pues de antemano te comento que todos los sitemas empresariales que he estado utilizando en los últimos años, no le permiten al usuario borrar ningún registro. Esto es para llevar un mayor control de las acciones que se realizan.

El estatus de los registros puede cambiar (activo, cancelado, obsoleto, cerrado, facturado, etc) pero jamás se eliminan registros.

Así que yo te podría decir que, los sistemas que permiten al usuario borrar registros, tienen un gran hueco de seguridad y control de su información.

Esto es cuando hablamos de sistemas que contienen información legal o vital para la empresa.

Perfecto Lepe:
A priori ese sistema me parece sofisticado e ingenioso, sin embargo tengo por costumbre no "hurgar" en las tablas del sistema, dado que en mis inicios de interbase, hice irrecuperable una base de datos tratando de ocultar las fuentes de la misma, y desde entonces son prohibidas para mi, no obstante viendo lo visto, sería cuestión primero reconsiderarlo y segundo quitarme el sombrero.

:)

Me parece muy adecuado pero tajante....

Seamos un poco serios con aquello de la información legal y vital.
Recuerdo que hace unos años, mas o menos en los inicios del Club de Delphi, pululaba y pulula una empresa ""de cierto prestigio", la cual cuenta con una importante cartera de clientes, entre las que además del desarrollo de aplicaciones, impartía formación a programadores y se desarrolló un proyecto de gestión empresarial / contabilidad, que pretendía abarcar todos los ramos empresariales.
Bueno pues mira por donde, resulta que ese proyecto disponía de una doble contabilidad, la "legal" y la "otra" y mira por donde, resultó que la mayoría de las empresas que se interesaron por aquel proyecto, destacaban como principal virtud del proyecto, justamente esa faceta que te he comentado.
Estoy seguro que algunos de los usuarios de esta web, les suena de lo que estoy hablando.
Dicho esto; saca tus propias conclusiones.
Saludos