1

代替テキスト http://img29.imageshack.us/img29/825/simplemodel.jpg

上記のように、これは RDBMS (この場合、私のお気に入り: MySQL) のテーブルの一種のサブクラスであるため、フィールド データなどを検証する tb_order_base のベース フォームを Visual Subclassing で処理します。

このようにして、コードの繰り返しやその他の厄介な問題から解放されます。まあ、これは真の OO アプローチのようです。しかし ...

サブクラス化されたフォーム、つまりマスター/詳細アプローチを使用した tb_order_service で大きな問題が発生しました。tb_order_base データセットを投稿すると、Delphi が最初に投稿して RDBMS から PK ID を取得し、ID が入力された TB_ORDER_PRODUCT を投稿するのではなく、反対に、詳細な tb_order_product データセットを最初に投稿してから、マスター tb_order_base を投稿すると、大きなキー制約エラーが発生します。

この驚くべき問題を回避する方法を知っている人はいますか?

以前に質問したことがありますが、マスター/ディテールの動作の詳細はほとんどありません

4

1 に答える 1

2

このような状況で私が行ったことの1つは、DBMS直接呼び出しの実行から脱却し、代わりにフォームにメモリデータセット（またはクライアントデータセット）を使用することでした。ユーザーが保存ボタンを押すと、編集内容を検証してエラーを返します。エラーがない場合は、データベーストランザクションを開始し、マスターレコードをコミットし（挿入されている場合はマスターレコードキーを読み取り）、子レコードをコミットする各テーブルを実行してから、トランザクションをコミットします（またはロールバックします）。子データの保存に問題があった場合）。

また、データベース対応コンポーネントの使用も避けています。これらは単純なユーティリティタイプのプログラムには最適ですが、それらを使用して複雑なシステムを作成し始めると、標準の編集とデータベースとの間でデータをプッシュ/プルする機能を使用して簡単に解決できる小さな落とし穴が見つかります。私が一般的に行う唯一の例外はグリッドの場合ですが、選択にはグリッドのみを使用します...実際の編集は非データ対応コンポーネントを使用して行われます。

于 2009-06-22T16:06:15.540 に答える