SQL7008 Erreurs solution de Contournement?

Je suis en utilisant le JTOpen pilote JDBC pour une base de données DB2 Universal database. J'ai très peu d'expérience avec SQL au-delà de simples déclarations.

De cette question, je vois que l'erreur que je reçois (SQL7008) est levée lors de la tentative de "insérer/mettre à jour les lignes dans un non journalisé table lors d'une transaction" (paraphrase).

Selon le chef de projet, notre DB n'est pas journalisé et ne le sera pas de si tôt (ne me demandez pas pourquoi, je ne suis pas l'administrateur de la base). Cependant, je travaille sur un projet où la commit tout d'un coup (plutôt que de Validation automatique-ment chaque fois qu'une exécution est appelée) est presque nécessaire (pas totalement nécessaire, mais il permettrait de résoudre beaucoup de problèmes en bas de la route).

Est-il un moyen de contourner erorr SQL7008 sans l'activation de la Journalisation?

OriginalL'auteur BenCole | 2011-11-22

  1. 18

    Le seul moyen de le contourner sans l'activation de la journalisation est de désactiver d'isolation de transaction dans votre chaîne de connexion comme suit:

    jdbc:as400://systemname;naming=sql;errors=full;transaction isolation=none;date format=iso

    La liste complète des JDBC propriétés peuvent être trouvés dans la IBM boîte à outils pour Java JDBC propriétés de la documentation.

    Ne vous arrive de savoir si ce format de l'URL est pris en charge par AS400JDBCConnectionPoolDataSource de la JTOpen bibliothèque?
    href="http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzahh/jdbccon.htm" >AS400JDBCConnection classe: Il y a de nombreuses propriétés facultatives qui peuvent être spécifiées lorsque la connexion est créée. Propriétés peuvent être spécifiées soit dans le cadre de l'URL ou en java.util.Les propriétés de l'objet. Voir IBM boîte à outils pour Java JDBC propriétés pour une liste complète des propriétés prises en charge par le AS400JDBCDriver.
    C'est elle! Bien, genre de. J'ai dû mettre TransactionIsolation("none") dans l'objet source de données.
    Je vois que c'est un ancien mais voulez vraiment obtenir ma compréhension claire. Par paramètre aucun d'isolation de la transaction, elle aura tout défaut au niveau base de données. Cause je suis tombé sur un dead lock scénario de long en arrière. Le niveau d'isolation certainement aidé. Alors laissez-moi savoir combien fiable et positif cette suggestion !. Cependant James mentionné, c'est une solution de contournement.

    OriginalL'auteur jamesallman

  2. 2

    J'ai trouvé que l'utilisation de WITH NONE à la fin de la DB2 déclaration de résoudre le problème, seulement si vous utilisez INSERT.

    Quand j'ai essayer d'utiliser SET OPTION COMMIT=*NONE sur une instruction Delete, il semble ignorer le où, et il supprime tout, la même chose se passe lorsque j'essaie d'utiliser WITH NC ou WITH NONE

    Pour résoudre ce problème, effectuez l'une des opérations suivantes:

    Activer la journalisation pour la table de base de données: Windows: Ajouter un Paramètre CLI 'TxnIsolation' avec la valeur '32' à l'intérieur
    vos paramètres ODBC sous "Outils d'Administration". Cette option peut être
    se trouve dans: "Source de Données" - > "Paramètres Avancés" -> "Ajouter" ->
    "TxnIsolation" comme un bouton radio "Pas de Commettre".

    AIX /Unix: Exécuter les opérations suivantes DB2 commande sur votre base de données: 'db2
    mise à jour de la cli cfg pour la section à l'aide de TXNIsolation 32'. Vérifier
    ces paramètres avec la commande suivante: 'db2 obtenir cli cfg'

    Suppléant SQL solution de contournement: (pas d'OS): Ajouter "AUCUN" à la fin
    de votre SQL de mise à JOUR de la commande.

    Plus d'infos...

    Veuillez citer la partie la plus pertinente de la liaison, dans le cas où l'objectif du site est inaccessible ou va définitivement hors ligne. Voir Comment puis-je écrire une bonne réponse.

    OriginalL'auteur dontknowathing

  3. 1

    Il y a une option qui peut être ajouté à votre chaîne de connexion qui désactive le contrôle des engagements.

    Probablement CommitMode=0 serait de travailler.

    Le CommitMode option est pour une chaîne de connexion ODBC. JDBC propriétés ne sont pas les mêmes.
    Malheureusement, il semble que la fonctionnalité Java (que je connais) est Connection.setTransactionIsolation(int level). Malheureusement, la valeur pour CommitMode=0 est Connection.TRANSACTION_NONE, qui est retenu avec la note: Note that Connection.TRANSACTION_NONE cannot be used because it specifies that transactions are not supported.)
    Désolé, je pensais que les chaînes de connexion étaient les mêmes.

    OriginalL'auteur Mike Wills

  4. 0

    La liste officielle des SQL7008 est ici (faire CTRL-F pour SQL7008). Il semble que vous pouvez obtenir plus d'informations sur le code de la raison. Si vous obtenez un code de raison 3, il semble comme il n'y a pas d'autre option en plus de l'activation de la journalisation.

    Si vous avez quelque chose d'autre que le code de raison 3, alors je suppose que vous avez plus d'options.

    Espère que ça aide.

    Où puis-je trouver le code de la raison dans la SQLException être jetés? Je suis SQLState = 55019 et le Code d'Erreur = -7008.
    Si vous êtes en java à la recherche, à l'exception SQLException est-il rien, dans aucun de ses autres champs, comme vendeur code ?
    Malheureusement, il semble que ce soit la seule information que je me suis donné.

    OriginalL'auteur Michael Sharek

  5. 0

    Si l'on travaille sur CL commandes. Cette commande permet de résoudre le problème:

    RUNSQLSTM SRCFILE(LIBNAME/SRCFILE) SRCMBR(MBRFILE) COMMIT(*NONE) NAMING(*SQL)
    C'est pour le ppl, qui invoque des scripts garé dans la machine source.

    OriginalL'auteur AkD