Aucun opérateur ne correspond au nom donné et au (x) type (s) d'argument. Vous devrez peut-être ajouter des conversions de types explicites. - Netbeans, Postgresql 8.4 et Glassfish
Je suis en train de modifier un tableau dans Postgresql à l'aide de JPA dans Glassfish à l'aide de EclipseLink. Lorsque j'insère une entité, il fonctionne très bien. Mais, quand j'essaie de retirer ou de modifier de la même entité, il échoue avec l'erreur suivante. Une idée?
Causés par: Exception [EclipseLink-4002] (Eclipse Services de Persistance - 2.0.1.v20100213-r6600): org.eclipse.la persistance.des exceptions.DatabaseException Exception interne: org.postgresql.util.PSQLException: ERREUR: opérateur n'existe pas: entier = character varying Astuce: en l'Absence d'opérateur correspond au nom donné et le type d'argument(s). Vous pourriez avoir besoin d'ajouter de type explicite jette. Position: 38 Code D'Erreur: 0 au org.eclipse.la persistance.des exceptions.DatabaseException.sqlException(DatabaseException.java:333) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1422) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:799) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:867) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:587) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:530) au org.eclipse.la persistance.interne.les sessions.AbstractSession.executeCall(AbstractSession.java:914) au org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:205) au org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:191) au org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.deleteObject(DatasourceCallQueryMechanism.java:182) au org.eclipse.persistence.internal.queries.StatementQueryMechanism.deleteObject(StatementQueryMechanism.java:101) au org.eclipse.la persistance.les requêtes.DeleteObjectQuery.executeDatabaseQuery(DeleteObjectQuery.java:167) au org.eclipse.la persistance.les requêtes.DatabaseQuery.execute(DatabaseQuery.java:675) au org.eclipse.la persistance.les requêtes.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:589) au org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyquery(ObjectLevelModifyQuery.java:109) au org.eclipse.persistence.queries.DeleteObjectQuery.executeInUnitOfWorkObjectLevelModifyquery(DeleteObjectQuery.java:112) au org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:86) au org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2857) au org.eclipse.la persistance.interne.les sessions.AbstractSession.executeQuery(AbstractSession.java:1225) au org.eclipse.la persistance.interne.les sessions.AbstractSession.executeQuery(AbstractSession.java:1207) au org.eclipse.la persistance.interne.les sessions.AbstractSession.executeQuery(AbstractSession.java:1167) au org.eclipse.la persistance.interne.les sessions.CommitManager.deleteAllObjects(CommitManager.java:297) au org.eclipse.la persistance.interne.les sessions.CommitManager.deleteAllObjects(CommitManager.java:256) au org.eclipse.la persistance.interne.les sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1406) au org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:547) au org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1508) au org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3128) au org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:268) au org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:157) au org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68) au com.soleil.de l'entreprise.des transactions.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:412) ... Plus de 25 Causés par: org.postgresql.util.PSQLException: ERREUR: opérateur n'existe pas: entier = character varying Astuce: en l'Absence d'opérateur correspond au nom donné et le type d'argument(s). Vous pourriez avoir besoin d'ajouter de type explicite jette. Position: 38 au org.postgresql.de base.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) au org.postgresql.de base.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) au org.postgresql.de base.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) au org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) au org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367) au org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:321) au com.soleil.gjc.le spi.de la base.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:108) au org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:792) ... 53 plus Java Résultat: 1
source d'informationauteur Sam | 2010-09-17
Vous devez vous connecter pour publier un commentaire.
J'ai eu ce problème et résolu. Cela était dû à la clause where contient la Chaîne de valeur de valeur de type entier.
Ce la principale erreur:
Vous code est d'essayer de faire correspondre un entier et une chaîne de caractères, qui ne va pas au travail. Corriger votre code, obtenez la requête qui est impliqué pour voir si vous fixe. Voir aussi le PostgreSQL fichiers journaux.
Une solution de contournement (PAS UNE SOLUTION!) doit faire de la coulée. Voir cet article.
N'a pas l'air de vous obtenu une réponse, mais ce problème peut également se glissent si vous êtes de passage null ID dans votre JPA Prédicat.
Par exemple.
Si j'ai fait une requête sur les Chats de revenir une liste. Qui renvoie 3 résultats.
Liste catList;
J'ai ensuite itérer sur la Liste de chats et de stocker un foriegn clé de chat peut-être leashTypeId dans une autre liste.
Si l'un des Chats dans catList ont une valeur null leashTypeId il va lancer cette erreur lorsque vous essayez d'interroger votre base de données.
(Juste de me rendre compte que j'ai écris sur 5 ans fil, peut-être que quelqu'un va trouver cela utile)
Bro, j'ai eu le même problème. C'est que j'ai construit un générateur de requêtes, tout un complexe qui se, construire son prédicats de manière dynamique en attente sur quels paramètres ont été mis en cache et les requêtes. De toute façon, avant que je construit mon générateur de requête, j'ai eu un non orienté-objet, du code de procédure de construire la même chose (sauf, bien sûr, il ne met pas en cache les requêtes et les paramètres d'utilisation) qui a travaillé à la perfection. Maintenant, quand mon constructeur a essayé de faire la même chose, mon PostgreSQL jeté cette foutu erreur que vous avez reçu trop. J'ai examiné mon code SQL généré et n'a trouvé aucune erreur. Étrange en effet.
Ma recherche s'est rapidement avéré qu'il était un particulier de prédicat dans la clause where qui a provoqué cette erreur. Pourtant, ce prédicat a été construit par le code qui ressemblait, enfin presque, exactement que la façon dont le code de procédure ressemblait avant cette exception a commencé à apparaître de nulle part.
Mais j'ai vu une chose que j'avais fait différemment dans mon constructeur contrairement à ce que le code de procédure précédemment. C'était la ordre de prédicats, il a mis dans la clause where! J'ai donc commencé à déplacer ce prédicat autour de et bientôt découvert qu'en effet l'ordre des prédicats avait beaucoup à dire. Si j'avais ce prédicat tout seul, ma requête a fonctionné (mais a renvoyé un résultat erroné-match, bien sûr), si je l'ai mis avec juste l'un ou l'autre prédicat, il a travaillé parfois, n'est-ce pas le travail d'autres moments. En outre, imitant la commande précédente du code de procédure ne fonctionne pas non plus. Ce qui a fonctionné a été de mettre cette démoniaque prédicat au début de ma clause where, comme le premier prédicat ajoutée! Donc encore une fois si je n'ai pas fait moi-même clair, la commande de mon prédicats où la OÙ la méthode/de la clause de la création de cette exception.
Je suppose que cela peut être dû à beaucoup de choses.
Dans mon cas, c'était d'avoir "where id DANS l'état" dans ma requête et j'ai été la mise IDs séparés par un tiret comme une chaîne à l'aide de setString méthode sur PreparedStatement.
Ne sais pas si c'est la meilleure façon de le faire mais j'ai juste ajouté de l'espace réservé, dans ma déclaration, et l'a remplacé par des valeurs sur ma propre.
Si quelqu'un est d'avoir cette exception et est la construction de la requête à l'aide de la Scala multi-ligne de cordes:
Ressemble à il ya un problème avec certains JPA pilotes dans cette situation. Je ne suis pas sûr de ce qui est le personnage Scala utilise pour FIN de LIGNE, mais quand vous avez un paramètre à la fin de la ligne, la LIGNE de caractère de FIN semble être attaché à l'paramètre, et donc quand le pilote analyse de la requête, cette erreur vient. Un travail simple, est de laisser un espace vide à droite après le param à la fin:
Donc, assurez-vous de laisser un espace vide après param (et param2, si vous avez un saut de ligne).
Si vous utilisez Primefaces, vous devez insérer à l'intérieur de la de la .fichier xhtml, donc il convertit correctement à java entier. Par exemple: