Buscar si se produjo una excepción SQLException debido a un duplicado

Question

Tengo un programa Java que es independiente de la base de datos y necesito saber, al insertar, si se produjo una excepción SQLException debido a una clave duplicada.

Si estuviera usando un único controlador de base de datos simplemente usaría el Código de Error, pero como puedo usar motores muy diferentes, el Código de Error no es el mismo.

¿Alguien ha hecho esto antes? ¿Algunas ideas?

Muchos TIA!

Editar: Tengo un archivo de configuración donde almaceno la clase controlador (es decir: org.apache.derby.jdbc.ClientDriver) y alguna otra información necesaria (es decir: nombre de usuario, contraseña, URL ...). La conexión siempre pasa como una "java.SQL.Connection", así que realmente no me importa qué controladores se estén utilizando.

Answer 1

Con JDBC básico, realmente no hay una manera de hacer lo que dice en una base de datos cruzada. Como mencionó getErrorCode podría utilizarse, pero se requieren códigos de error específicos del proveedor.

Las únicas tres maneras que veo de evitar esto es:

1. utilizar algún tipo de marco que hace todo el traductor de código de error a excepciones significativas (Hibernate probablemente hacer esto, alguien ha mencionado que Spring lo hace)
2. Compruebe la duplicación manualmente (con una selección) antes de hacer su inserción. (Esto no sería 100%, ya que es técnicamente posible que alguien haya hecho una inserción después de su consulta).
3. Después de obtener cualquier excepción sql en la inserción, intente realizar una consulta para esa identificación. Si realmente puede encontrar la coincidencia, puede estar bastante seguro de que el error que recibió se debió a una clave principal duplicada. (Aunque es posible que haya problemas múltiples, y ese no fue realmente el que se lanzó).

Mi recomendación sería escribir su código para evitar el problema tanto como sea posible, y luego (si es absolutamente necesario), use # 3.

Answer 2

Creo que una manera simple y confiable es verificar si la clave existe antes de hacer la inserción. Como correctamente ha señalado, cada base de datos tiene su propia forma de informar el error.

Answer 3

Bueno, si no puede confiar en la excepción para decirle por qué se lanzó, puede probar siguiendo la excepción con un "select count (*) from table where key = @keyfailedtoinsert;"

Desafortunadamente, no se garantiza que la excepción le proporcione el nombre de la tabla y el nombre de la clave. En algunos casos, el código java llamado llamado controlador JDBC puede que nunca los haya tenido, por ejemplo, si el inserto sucedió con un procedimiento almacenado o como un desencadenante.

Ha vuelto a tener que confiar en el proveedor de cada controlador JDBC.

Answer 4

Puede "entrenar" el programa al inicio (o config) insertando una clave duplicada conocida y registrando el código de error generado.

Answer 5

¿Echo de menos algo? Si está utilizando JDBC, debe obtener una excepción de clave duplicada, independientemente de la base de datos que se utilice.

¿O le preguntó cómo determinaría un dupkey ANTES de probar el inserto?

Answer 6

Supongo que no está utilizando JDBC o esto sería una búsqueda de error muy simple.

¿Tiene un conjunto diferente de clases para acceder a las diferentes bases de datos? Si es así, podría atrapar la excepción en las clases específicas de la base de datos y arrojar su propio tipo de excepción que se comparte entre todos los tipos de bases de datos.

Answer 7

Creo que la solución ideal sería hacer que la capa de datos arroje una excepción específica en este caso, tal vez una subclase de SQLException para DuplicateKeyException o algo similar.

Si desea poder tratar diferentes excepciones de manera diferente, debe lanzar diferentes tipos de excepción (o subtipos) para comenzar.

Creo que esta es un área donde el Spring Framework hace que las cosas realmente correcta: proporcionan a very rich hierarchy of "database exceptions" todos los cuales se extienden DataAccessException, con sub-árboles de tipos para "excepciones recuperables", "excepciones transitorias", "excepciones de integridad de datos" , etc. Esto deja al código del cliente libre para capturar cualquiera (o ninguno) de los tipos de excepción que puede manejar o preocuparse: excepciones que indican un error que puede no ser repetible si re-ejecuta la transacción, un error fatal -recortable error, o simplemente puede atrapar el tipo de raíz.

Answer 8

Esto es exactamente para lo que es SQLException.getSQLState(). Según Google, "23000" indica una violación de restricción única en al menos MySQL, PostgreSQL y Oracle.