問題タブ [ora-00001]

spring および hibernate 3.0 で開発され、apache tomcat 6 にデプロイされた Web アプリケーションがあります。

このエラーは、本番環境でのみ再現可能です。同じDBを指すローカル環境で同じコードが動作しています。ロガーステートメントを追加しようとしたところ、シーケンスジェネレーターが毎回同じ値、つまり「0」を生成していることがわかりました。あなたの助けを待っています。

-- Sun2

返信ありがとうございます。はい、例外は明らかに制約に違反していると言っています。CARS.XAK1CAR_ATTRIBUTE は結合キーであり、一意である必要があります。すべてのデータを (ロガーによって) 検証しましたが、この制約に違反する可能性のあるデータは見つかりませんでした。さらに、この制約に違反している場合、同じ DB を指すローカル環境では機能しません。これはサーバー固有のものですか？問題の解決に役立つ場合は、挿入しようとしているテーブル DDL やデータなどの詳細を提供できます。――サントッシュ

データベーステーブルの1つに書き込む必要があるファイル(実際には、このファイルにはタブ区切りの値があります)があります。このファイルには、重複するエントリも含まれる場合があります。ファイル内のレコードを 5000 のセットで処理しているため、最初にファイル内のこれらの最初の 5000 レコードを解析します。それらに重複エントリが含まれている場合は、単に重複を無視し、それらの中の一意のレコードをデータベースに書き込み、次の 5000 を再度処理します。 EOF に達するまで同様の方法で記録します。これらの 5000 レコードの書き込み中に、5000 レコードのセット間に重複がある可能性があります。重複が発生した場合 (データベースは DomainObjectExistsException をスローします)、例外をキャッチしてレコードを更新します。次のような更新操作を実行しています。

ここで、femtoFactoryData は Java オブジェクト (POJO) であり、ファイル内のタブ区切りの値から構築されたデータベース テーブルに書き込む必要があります。テーブルの主キーは、Femto の ID と状態 (一時的/永続的) に他なりません。

しかし、この更新操作を実行すると、次のようになります。

私のプログラムからのスタックトレースは次のとおりです。

一意のキーと主キーを含むテーブルを検討してください。テーブルには既にデータが含まれています。テーブルに行を追加すると、重複した値が主キーまたは一意のキーに追加されたため、エラー (ORA - 0001) が発生しました。 .ここで、エラーが主キーまたは一意キーへの重複値の追加によるものかどうかを特定できません。誰かがこれを特定する方法を提案できますか?

重複キーエラーerr.getMessage()が返された場合org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch

スタックトレースには、次のエラーもあります。 java.sql.BatchUpdateException: ORA-00001: unique constraint (ACM.SCH_UK) violated

この ORA-00001 メッセージをテキストではなく文字列として取得するにはどうすればよいorg.hibernate.exception.ConstraintViolationExceptionですか?

EVENT_IDフィールドが問題です。でもとにかく挿入したいです。しかし、その名前の制約を削除しようとすると、そのような制約はないと表示されます。さらに、そのような制約はUSER_CONSTRAINTSテーブルに表示されません。私は何をすべきか？

エンティティ フレームワーク (ベータ) 用の Oracle プロバイダーを使用していますが、問題に直面しています。

テーブルには Id 列があり、StoreGeneratedPattern で Identity に設定されています。EF は、シーケンスの作成などの「基礎となる作業」を自動的に行い、テーブルに追加するレコードごとに新しい ID を取得すると考えました。しかし、コードを実行して新しいレコードを追加すると、次のようになります。

例外がまだスローされます。

{"ORA-00001: 一意の制約 (ADMINMGR.CONSTRAINT_COMMENT) に違反しています"}

(CONSTRAINT_COMMENT は、コメント ID が一意でなければならないという制約です。

これを解決するにはどうすればよいですか？

どうもありがとうございました！

目標の合計を維持し、既存の値と新しい値の差を返す Oracle データベースで更新/挿入を実行する PL/SQL 関数があります。
これが私がこれまでに持っているコードです:

これは、単体テストでは期待どおりに機能し、複数のスレッドが失敗することはありません。
ただし、ライブ システムにロードすると、次のようなスタック トレースで失敗することがわかりました。

行番号 (コンテキスト外では無意味なので削除しました) は、最初の更新がデータがないために失敗し、挿入が一意性のために失敗し、2 番目の更新がデータなしで失敗していることを確認します。これは不可能なはずです。

私が他のスレッドで読んだことから、MERGEステートメントもアトミックではなく、同様の問題が発生する可能性があります。

これを防ぐ方法を知っている人はいますか?

背景: http://jeffkemponoracle.com/2011/03/11/handling-unique-constraint-violations-by-hibernate

私たちのテーブルは次のとおりです。

BOND_PAYMENT_ID には主キー制約があり、(BOND_NUMBER, PAYMENT_ID) には一意の制約があります。

アプリケーションは Hibernate を使用し、ユーザーは特定の債券にリンクされたすべての支払いを表示できます。また、新しいリンクを作成したり、既存のリンクを削除したりできます。ページに必要な変更をすべて加えたら、[保存] をクリックすると、Hibernate が魔法のようにデータベースで必要な SQL を実行します。どうやら、Hibernate はどのレコードを削除する必要があるか、どのレコードを挿入する必要があるかを判断し、残りはそのままにしておきます。残念ながら、最初に INSERT を実行し、次に DELETE を実行します。

ユーザーが支払いへのリンクを削除し、気が変わって同じ支払いへのリンクを再挿入した場合、Hibernate は喜んでリンクを挿入してから削除しようとします。これらの挿入/削除は別個の SQL ステートメントとして実行されるため、Oracle は最初の挿入時にすぐに制約を検証し、ORA-00001 一意の制約違反を発行します。

私たちが知っているのは次の 2 つのオプションだけです。

1. 制約を延期可能にする
2. 一意の制約を削除します

オプション 2 はあまり好ましくありません。これは、制約によって、一貫性のないデータが保存される可能性がある厄介なアプリケーションのバグから優れた保護が提供されるためです。オプション1を使用しました。

欠点は、この制約をポリシングするために作成されたインデックスが一意ではないインデックスになったため、クエリの効率が多少低下する可能性があることです。これは、この特定のケースではそれほど大きな不利益ではないと判断しました。もう 1 つの欠点 (Gary のアドバイス) は、特定の Oracle バグに悩まされる可能性があることです。ただし、アプリケーションの動作方法により、(少なくとも、ほとんど) 免疫があると思います。

他に考慮すべきオプションはありますか？

PL/SQL で 2 つのテーブルから 2 つの列をマージしようとすると、非常に困難です。私はこれに午前 9 時から取り組んでいましたが、あきらめました。助けてください。

目的

新しいテーブルを作成したいと思います（一時と呼びます）。これにより、2 つの異なるテーブルの他の 2 つの列からの情報がマージされます。

コード ここまで

これまでのところ、このコードでは一意の制約に違反するだけです。

私が間違っていることを見つけることができますか？（どんな助けも大歓迎です）

JDBCを使用したJavaサーブレットを介して、入力されたデータを非常に単純なOracleデータベーステーブルに格納する単純なフォームを作成しています。そのテーブルは、電子メールアドレスを主キーとして使用しています。ユーザーが同じ電子メールアドレスでフォームを複数回送信すると、execute関数は失敗し、SQLExceptionをスローします。例外の文字列は次のとおりです。

このシナリオでは、この例外をキャッチし、同じ電子メールアドレスでフォームを複数回送信できないことをユーザーに通知することで対処したいと思います。によってスローされる可能性のある他のSQLExceptionとは別に、異なる方法でORA-00001を処理する適切な方法は何executeですか？文字列比較は明らかにここで機能する可能性がありますが、それは不十分な解決策のようです。