31 respuestas en este tema

[eduarcol]

Delphius, mira lo que hizo Fenareth, a la clausula Select le agrego el valor de la clave que desea colocar y asi si le va.

[Delphius]

Eso estoy viendo amigo.

Si dice que anda pues... debe ser que si... Aunque yo ahora tengo una duda existencial. De la consulta que pone Gaby yo leo que hace un WHERE filtrando aquellos que tengan cierto valor clave... pero si el campo CVE_IMPOO es igual a la clave primaria, y se intenta guardar con la misma... ¿entonces no deberí­a haber un conflicto?

Por ejemplo, si la consulta select en la parte where resulta ser que "clave" es 5, y se obtienen los registro cuyo campo CVE_IMPOO es 5... cualquier operación insert con el mismo valor clave deberí­a provocar un error. Es decir:

INSERT INTO TABLA 5, .... no deberí­a funcionar puesto que ¡ya existe un campo con la clave 5!

A lo que puedo llegar yo es que, o bien el campo CVE_IMPOO no es la clave primaria, o yo estoy leyendo mal.

Saludos,

[eduarcol]

estas leyendo mal 

Fijate que la clave principal se la asigna "manualmente", fijate en la concatenacion que se realiza al comenzar select, alli esta la clave de la clave 

[Delphius]

Veo que concatena manualmente la clave amigo.... pero veo que más adelante usa la misma para filtrar.

A lo que voy es que, suponiendo que clave es 5.... la consulta de Fena se traduce a:

sql

INSERT INTO SAAIO_AVITRAS
SELECT 5, ???, FEC_AVIS, TIP_OPER, TIP_TRAS, TIP_PROGO, NUM_PROGO, CVE_PLANO, CVE_IMPOD,TIP_PROGD, NUM_PROGD,CVE_PLAND, CVE_REPR, FIR_ELEC, NUM_FEA,NUM_REFE
FROM SAAIO_AVITRAS 
WHERE CVE_IMPOO = 5 AND FOL_AVIS = ???

Siendo ??? los valores que se suministraron.

Ese select quedará en, por ejemplo en un conjunto de datos... digamos, como para representarlo de alguna forma:
{5, ???, ???, ....}

Internamente el INSERT INTO, se termina traduciendo en algo como:

sql

INSERT INTO SAAIO_AVITRAS (...) VALUES (5, ???, ???, ....)

Y si ese 5 ya existe.... ¿entonces?

Sigo estando dormido seguramente... porque algo se me escapa.

Saludos,

[Fenareth]

Delph !, te cuento un poco más...

Mi tabla tiene una llave combinada que consta de la Clave y el Folio. Al hacer la copia la Clave no debe de cambiar, pero me aseguro de que el Folio si lo haga (es otro proceso que hago antes de construir la sentencia SQL) por lo que el nuevo registro tiene la misma Clave que el anterior pero un Folio distinto...

Es por eso que no tengo problemas con duplicidad de llaves 

Saludox !

[Delphius]

Por eso mismo yo decí­a... algo se me escapa . Ya me parecí­a raro que permitiese insertar un duplicado.

Saludos,

[luk2009]

Tengo un problema algo similar a este  que tenia fenareth, pero por mas que leo este hilo no encuentro como hacerlo

mi tabla es:

callnumber
csid
nombre
telefono
relacion
tipo

la llave primaria es compartida por los campos callnumber y csid

valores por ejemplo:



[table]
[tr]
[td]callnumber      csid        nombre        telefono              relacion    tipo
A                      0107      luciano        809-555-5555    amigo        celular
B                      0107      fenareth      809-544-5555    amiga        celular
[/td]
[/tr]
[/table]


si quiero copiar estos registros al CSID 0860 

como puedo hacerlo

[Marc]

Efectivamente eduardo. Dice que se se debe pasar una clave distinta. Pues, modifico la consulta para que el valor a insertar en la clave sea otro... e igualmente salta el error.

A eso voy.

Por ejemplo esto:

select ID, NOMBRE, FECHA, CANTIDAD, MONEDA, FECHA1, INTPEQUE, HORA
from tabla1
where NOMBRE = 'Marcelo'

Me dá un solo resultado, como es de esperar:

delphi

ID	NOMBRE	FECHA	CANTIDAD	MONEDA	FECHA1	INTPEQUE	HORA
951	Marcelo	10/09/2009	25	365	10/10/2009	10	05:44:38 p.m.

Digamos ahora que quiero insertarlo nuevamente, con otra clave:

sql

INSERT INTO TABLA1 (ID, NOMBRE, FECHA, CANTIDAD, MONEDA, FECHA1, INTPEQUE, HORA)
SELECT ID + 100, NOMBRE, FECHA, CANTIDAD, MONEDA, FECHA1, INTPEQUE, HORA
FROM tabla1
WHERE NOMBRE = 'Marcelo'

IBExpert deja de responder ... vuelvo a abrirlo, y a revisar los valores. No se insertó.

¿Entonces?

Se que no estoy totalmente concentrado... no logro ver el maldito error. Me hace falta despejarme... y cargar combustible.

En teorí­a según el estandar SQL, una instrucción SQL
INSERT INTO TABLA
SELECT (...)
FROM TABLA
WHERE ....

Deberí­a funcionar. Algo mal debo estar haciendo y no lo veo . No he probado con la variante "Values ()". Tal vez por allí­ venga la mano.

Saludos,

Sí, esto funciona (lo utilizo muy a menudo). Comprueba que confirmas correctamente la transacción, etc. ...

Personalmente lo hago en este estilo (genero un nuevo ID sobre la marcha para el nuevo registro) :

sql

INSERT INTO TABLA1 (ID, NOMBRE, FECHA, CANTIDAD, MONEDA, FECHA1, INTPEQUE, HORA)
SELECT gen_id(TABLA1_GEN, 1), NOMBRE, FECHA, CANTIDAD, MONEDA, FECHA1, INTPEQUE, HORA
FROM tabla1
WHERE ID = :ID_A_COPIAR

Saludos.

[Marc]

Hola Luciano.

Tengo un problema algo similar a este  que tenia fenareth, pero por mas que leo este hilo no encuentro como hacerlo

mi tabla es:

callnumber
csid
nombre
telefono
relacion
tipo

la llave primaria es compartida por los campos callnumber y csid

valores por ejemplo:



[table]
[tr]
[td]callnumber      csid        nombre        telefono              relacion    tipo
A                      0107      luciano        809-555-5555    amigo        celular
B                      0107      fenareth      809-544-5555    amiga        celular
[/td]
[/tr]
[/table]


si quiero copiar estos registros al CSID 0860 

como puedo hacerlo

Esto debería ser así :

insert into TABLA1 (callnumber, csid, nombre, telefono, relacion, tipo)

select callnumber, :CSID_DESTINO, nombre, telefono, relacion, tipo

from TABLA1

where csid = :CSID_ORIGEN        

Saludos.

[luk2009]

Muchisimas Gracias Marc, funciono Perfecto.    Eres increible, siempre das en el clavo.   

[Sergio]

Creo que es un problema de concepto: Si al crear un registro le has de dar tu el nuevo id y preocuparte de que sea único, mal vas!

En mis tablas, uso un trigger before insert, si el id me llega a cero, lo cambio por uno tomado de un contador autoincremental de la propia base de datos.

Con ese trigger puesto, tu copias todos los campos del record excepto el id, ese lo dará el trigger, y te ahorras todo ese dolor de cabeza, solo te preocuparías de que el contador esté inicialmente puesto al max(id)+1 de tu actual tabla y listo.

[Wilson]

Creo que es un problema de concepto: Si al crear un registro le has de dar tu el nuevo id y preocuparte de que sea único, mal vas!

En mis tablas, uso un trigger before insert, si el id me llega a cero, lo cambio por uno tomado de un contador autoincremental de la propia base de datos.

Con ese trigger puesto, tu copias todos los campos del record excepto el id, ese lo dará el trigger, y te ahorras todo ese dolor de cabeza, solo te preocuparías de que el contador esté inicialmente puesto al max(id)+1 de tu actual tabla y listo.

Coincido plenamente con Sergio, además de lo expuesto y quizá fuera de tópico,  tengo como norma, jamás colocar una clave compuesta como clave primaria, siempre he de poner un entero como clave primaria, dado el caso de necesitar qué 2 o más campos sean únicos entonces los declaro como "UNIQUE". (Claro está que todos los diseños son respetables y que existen a veces necesidades muy específicas).

Un cordial saludo.