>>Gracias por la respuesta...
>>
>>Obviamente lo IDEAL seria poder obtener el numero al final... el problema es que ese numero (en el diseño actual de la bd) es una clave externa para un monton de tablas... lo que vuelve imposible el obtener la clave al final...
>>
>>Y por si fuera poco, como es un numero de factura, y en la legislacion de Colombia ni por equivocacion se debe saltar el consecutivo, es imposible utilizar la estrategia que sugieres...aunque es buena para otros casos...
>>
>>Se te ocurre otra idea? Recuerda que uso Sql Server 2000...
>
>Dentro de VFP, para los números de documento, sólo los asigno en el momento de guardar, y uso una transacción. Si no se puede guardar (TableUpdate() falla), anulo la transacción. Pero no sé cómo serían las transacciones con SQL Server.

Con SQL las transacciones podrían ser, por ejemplo:

nHandle = SQLCONNECT("odbc_driverSQLServer")
*-- Setting las transacciones en forma manual
SQLSETPROP(nHandle, 'Transactions', 2)
BEGIN TRANSACTION

*-- Codigo
IF Esta_todo_OK

    END TRANSACTION

>
>>(A proposito, para los que aun no saben, el PRIMER PEOR ERROR que pueden hacer al diseñar una BD es usar como ID claves con significado de negocio como nit, cedulas, codigos, numeros de factura, etc... siempre debe ser un ID estilo autoincrement, o un GUID...)
>
>Personalmente, estoy de acuerdo - pero parece que muchos programadores tienden por claves que ve el usuario, y muchos otros, por los otros. Estoy escribiendo un artículo sobre las ventajas y desventajas de cada método.
>
>Hilmar.