1

わかりました。以前に発生した問題に関連する質問があります。修正方法はわかっていますが、エラーを再現しようとすると問題が発生します。

他のレコードに基づいてレコードを作成する一連の手順があります。レコードは、 を介してプライマリ レコードにリンクされlink_idます。this を取得するプロシージャではlink_id、クエリは次のとおりです。

select @p_link_id = id --of the parent
from  table
where thingy_id = (blah)

これで、アクティビティのテーブルに複数の行が表示されます。一部キャンセル可能です。私が持っているコードは、選択ステートメントでキャンセルされた行を除外しないため、以前にキャンセルされた行がある場合、それらの ID が選択に表示されます。キャンセルされた行を除外すると、常に 1 つの「開いている」レコードが選択されます。(追記where status != 'C')

これにより、この問題が解決されます。ただし、開発環境で問題を再現できる必要があります。

データのヒープ全体を入力したり、開いたり、キャンセルしたりするプロセスを経て、この選択ステートメントが無効な ID を返すようにしました。ただし、選択を実行するたびに、ID は順番に (シーケンスが生成されます) 表示されますが、このエラーが発生した場合、選択ステートメントは最初の値と思われるものを変数に返しました。

例えば。

ID   Status
1    Cancelled
2    Cancelled
3    Cancelled
4    Open

上記を踏まえて、必要な ID を選択すると、「4」が取得されます。エラーの結果は 1 です。ただし、キャンセルされたレコードを 10 個入力しても、最後のレコードが選択されます。

オラクルでは、変数を選択して複数のレコードが返されると、エラーが発生することを知っています(私は思います)。Sybase は明らかに、エラーなしで変数に複数の値を割り当てることができます。

テーブルからデータが選択される方法に関係があると考えています。ソート順のないIDが昇順で返されないか、変数への選択が最初のものを保存するdboptionがありますまたは最後に照会された値。

編集: ストアド プロシージャの変更をロールバックすることで、このエラーを再現できるようです。ただし、procs はこの link_id 列の近くには行きません。データベース アーキテクチャを変更すると、インデックスなどが破損する可能性はありますか?

4

1 に答える 1

2

複数の行が返される場合、保存される値は、 thisに従って、リストの最後の値になります。

を介して取得の順序を指定していない場合ORDER BY、返される順序はデータベース エンジンの都合になります。データベースインスタンスによって異なる場合があります。データベースのブロック構造内でデータが配置されているため、作成された順序になるか、「ランダム」に見えることさえあります。

物語の教訓：

  1. singleton が常に単一SELECTの行を返すようにする
  2. #1 ができない場合は、 を使用しORDER BYて、気になるものが最後に来るようにします。
于 2009-07-21T02:39:45.670 に答える