FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
¿Como leer el registro recien incluido?
Buenas, necesito saber como leer el registro que acabo de de agregar a la tabla (uso un query con in INSERT INTO).
El problema es que el campo clave es de tipo AutoInc y por eso no sé que valor tiene hasta después de agregarlo y como la aplicación puede ser usada en redes es posible que se agregen varios y por tanto no sea el último registro. Lo que realmente quisiera saber es si un INSERT INTO devuelve algun valor que apunte al registro recien incluido.
__________________
Sitrico |
#2
|
||||
|
||||
Hola,
un Insert into no va a devolverte el codigo de registro, para esto te haría falta tener una tabla o Query. Creo que lo que puedes hacer si necesitas conocer el código de lo que acabas de insertar sería hacer el insert via Query.Insert conra la caché y confirmar via post (momento a partir del cual ya podrías conocer el código si no trabajas con ApplyUpdates) en lugar de lanzar el INSERT directo contra la BD. Hay algun motivo que te impida hacerlo?? Saludos! |
#3
|
||||
|
||||
Cita:
quizas lo mas compatible sea preguntar, inmediatamente despues de la inserción por el max(CampoAutoincremento) que cumpla que sus campos son los que acabas de insertar. ej: Código:
insert into mitabla (campo1,campo2,campo3) values ('hola','que tal estas',12/12/2004) select max(codigo) from mitabla where campo1='hola' and campo2 = 'que tal estas' and campo3 = 12/12/2004 eso si, con este método hay que tener en cuenta que hay que eliminar los campos cuyos posibles triggers modifiquen los valores insertados. en el ejmplo anterior si tubieramos un trigger que cambiase el campo 1 a mayusculas al insertar obtendriamos... un bonito valor null como resultado de la consulta.
__________________
todo el mundo debe creer en algo... yo creo que voy a tomarme otra copa. |
#4
|
||||
|
||||
En cuanto a mi primer mensaje,
Cita:
Estaba escribiendo esta respuenta mientras llegó la solución de Ruina: Cita:
Gracias.
__________________
Sitrico Última edición por sitrico fecha: 29-07-2004 a las 18:29:04. |
#5
|
||||
|
||||
Hola,
pues imaginate que estás añadiendo un nuevo Cliente en tu Tabla. Pondrías un Query con una sentencia tipo
Abres el Query mediante Open y ahora quieres agregar un registro:
Espero que te sirva. Saludos! EDIT: En teoría este método te serviría en multiusuario ya que quien se encarga de asociar tu registro con el autonumérico son los componentes de acceso y no el programador... Última edición por __marcsc fecha: 29-07-2004 a las 18:45:27. |
#6
|
||||
|
||||
Vaya! no sabia que un tQuery podía trabajar como un tTable, supongo que esta funcionalidad la incorpora el BDE. Como no quiero depender tanto del BDE me quedo con la sujerencia de Ruina.
Gracias a ambos
__________________
Sitrico |
#7
|
||||
|
||||
solo un par de apuntes:
para MSSQL la variable que mencionaba antes es @@identity. un query puede comportarse como una tabla siempre que tenga marcada la propiedad RequestLive a true y en ese caso ¡mejor usar un ttable! Puedes "espiar" los mecanismos del BDE con el SQLMonitor, quizas pueda darte una idea de como reproducir un determinado comportamiento en una base de datos determinada. Otro método de inserción/actualización es encerrarla en procedimientos almacenados, claro que si tienes que lidiar con X bases de datos tendrias que currante X*tablas procedimientos almacenados distintos (ahi si que no se parecen na de na)
__________________
todo el mundo debe creer en algo... yo creo que voy a tomarme otra copa. |
|
|
|