Thread: Problems with batch using jdbc on postgresql 7.4.2
Hi, somebody can help me?
I using a batch sentence to update some data in distinct tables, one of that tables have a foreing key, then when I execute the batch using jdbc on postgresql 7.4.2 abort the batch and send me the next message:
ERROR: SPI_connect failed
DEBUG: AbortCurrentTransaction
LOG: statement: rollback; begin;
the exactly sentence is a insert into table (,,,) values (,,,), the message was send just after execute the insert. If I removed the foreing key from the table , the batch worked correctly, but can´t drop the foreing key because I don´t want lost the integrity of data
I hope somebody have a solution.
Thanks and sorry by my grammatical style.
many
Manuel García H. wrote: > Hi, somebody can help me? > > I using a batch sentence to update some data in distinct tables, one of > that tables have a foreing key, then when I execute the batch using jdbc > on postgresql 7.4.2 abort the batch and send me the next message: > > ERROR: SPI_connect failed > DEBUG: AbortCurrentTransaction > LOG: statement: rollback; begin; > > the exactly sentence is a insert into table (,,,) values (,,,), the > message was send just after execute the insert. If I removed the foreing > key from the table , the batch worked correctly, but can´t drop the > foreing key because I don´t want lost the integrity of data On the face of it, this doesn't look like a JDBC problem: those messages are not generated by the JDBC driver, and the driver does not do anything special for INSERTs involving foreign keys. What happens if you run the same transaction via psql? -O
"=?iso-8859-1?Q?Manuel_Garc=EDa_H.?=" <mgarciah@ife.org.mx> writes: > I using a batch sentence to update some data in distinct tables, one of tha= > t tables have a foreing key, then when I execute the batch using jdbc on po= > stgresql 7.4.2 abort the batch and send me the next message: > =20 > ERROR: SPI_connect failed Could we see a complete example? This sounds like it could be a bug, but you have not provided nearly enough information to let anyone else reproduce it. regards, tom lane