システムwiki

コンボボックスの自動更新

Jocelyn 受付中 最終更新日:2022-05-17 16:50

1つのクライアントのすべての拡張子と電子ファイル情報を一覧表示する拡張子と電子ファイルフォームがあります.

フォームを機能させたいのですが、フォームの課税年度(コンボボックス)を変更すると、残りの情報は更新されますが、クライアントID、姓名は同じままです.

助けてください!

返信リスト(回答:17)

12 #
JohnW.V

tableの構造は何ですか?それらはどのように関連していますか?フォームのレコードソースは何ですか?何から作業しているのかをよく知らずに答えるのは難しいです!

応答12# ->にスキップ
11 #
Jocelyn

参加していただきありがとうございます! DBguyへの私の応答を見てください.レコードソースは、拡張子と電子ファイルtableです.自分のフィールドの大部分の写真を返信に含めました.

応答11# ->にスキップ
8 #
theDBgu

あなたは私の質問に答えていません.正規化ルールに精通していましたか?あなたが投稿したばかりの画像に基づいて、私の推測はノーでしょう.その場合は、それについて少し読んでから、質問がある場合、またはtable構造にどのように適用されるかを明確にする必要がある場合は、お知らせください.

17 #
theDBgu

やあ.申し訳ありませんが、私はあなたが何を求めているのか想像するのに苦労しています.リクエストを理解するのに役立つスクリーンショットを投稿していただけますか?ありがとう.

応答17# ->にスキップ
16 #
Jocelyn

これは、フォームがどのようになるかを示す大まかなドラフトです.table自体には50以上のフィールドがあり、元々はExcel上にあったため、情報を入力するために左右にどれだけスクロールしたかを想像できます.クライアントID、姓名は、作成した検索クライアントフォームを使用して入力されるため、[拡張機能と電子ファイルの表示]ボタンを選択すると、クライアントの情報が転送されます.

クライアントが2020年課税年度の延長を持っている場合、連邦、ハワイ、GE 1などのすべての情報を表示したいのですが、課税年度ドロップダウンを2021に変更した場合、フォームはクライアントの2021延長で自動的に更新されます.電子ファイル情報.それでも意味がない場合は申し訳ありません.他に必要な情報があれば教えてください.

応答16# ->にスキップ
15 #
theDBgu

やあ.追加の説明をありがとう.この情報をExcelからAccessに移行した場合、正規化ルールを知っていましたか?そうでない場合は、最初に簡単なレビューを行ってから、質問がある場合、またはこれらのルールのいずれにも違反していないと思われる場合は、戻ってくることをお勧めします.どういうわけか、tableの構造が不適切である可能性があるという印象があります.

応答15# ->にスキップ
13 #
Jocelyn

Excelからデータをインポートしませんでした.2021課税年度を新たに開始しているため、Accesstableに2つのレコードがあります.これらは同じクライアントですが、課税年度が異なり、両方のエントリの情報が異なります.これは、実際のデータを編集せずにフォームの機能をテストする私の方法でした.

応答13# ->にスキップ
14 #
theDBgu

正規化ルールに精通していると言っていますか?

応答14# ->にスキップ
10 #
Jocelyn

より簡単な方法でtableを作成する方法がわかりません.フォームに表示したすべてのフィールドは、データロギングに必要です.フィールドを少なくするために、tableを3つの別々のtableに分割する必要がありますか?フィールドとは何かを添付しました.

したがって、単一税年度の場合、クライアントのエントリは1つだけになります.クライアントに複数のエントリがある唯一の理由は、複数の課税年度が記録されている場合です.私が作成したフォームには、tableのすべてのフィールドがあります.年が変更された場合に、TaxYearコンボボックスで残りの情報を更新したいだけです.

このtableには1つの関係があり、すべてのクライアントtable(主キー:クライアントID、名、姓、エンティティ)に対して、クライアントIDには1対多の関係があります.

応答10# ->にスキップ
7 #
Scottge

効率的なデータベースの基盤は、適切なtable設計です.これらは、DBGuyが話す正規化ルールです.これらは、70年代から存在し、時の試練に耐えてきたリレーショナルデータベースの構造に関する一連のルールです.投稿したtableは正規化されていません.重要なルールの1つは、データを繰り返さないことです.したがって、元の質問に対する答えは、clientIDにバインドされたコンボボックスでクライアントを選択することだけです.

そのtableにクライアント名を含めることは冗長であり、その必要はありません.

すべての税フィールドは、次のように別のtableに配置する必要があります.

tblTaxAmts.

TaxAmtID(PK自動番号)

ParentID(外部キー)これは、表示したtableのIDに関連しています.

TaxDistrictID(FK)これは、連邦、ハワイ、GEなどの税務当局を示します.

TaxDue

TaxPaid

EstPaid

EstPdDate

PaymentTypeID(FK)

そして、他に必要なものは何でも

tableは、データが行と列の位置によって定義されることを示す正規化ルールに違反しています.データを識別するためにフィールド名を使用しています.そのため、連邦、州などの繰り返しフィールドがあります.正規化されたtableは、幅が広くなく、背が高くて薄いです.したがって、50フィールドのtableの代わりに、複数のレコードがあります.mainform/subfromコンボを使用して、必要なフォームを引き続き使用できます.

デザインに行き過ぎる前に助けを求めたのは良いことです.これで、設計エラーを修正して、そこから先に進むことができます.

応答7# ->にスキップ
5 #
Jocelyn

わかりました.このアイデアをマネージャーに提案する必要があります.もっと凝縮されるのが好きです!データを繰り返すべきではないことは理解していますが、このデータベースを使用する人々は、フォームやレポートではなくtableversionを表示することを好むことがあるため、困難です.そのため、私は姓名を保持しています.データ入力エラーを排除するために、クライアントIDと名前の自動入力を入力するか、検索フォームを使用して、データのログに使用しようとしているフォームに情報を転置することができます.クライアントID/名前を正規化しながら、人々が望むものを提供する方法はありますか?

応答5# ->にスキップ
1 #
theDBgu

やあ.幸運を!さらにサポートが必要な場合は、遠慮なく私にメールを送ってください.

応答5# ->にスキップ
3 #
Scottge

まず、ユーザーはtableに直接アクセスしないでください!アクセスすると、意図せずにApplicationを台無しにする可能性があります.ビューのようなtableを提供する場合は、すべてのデータを使用してクエリを作成し、データシートビューで提示できます.

メインフォーム/サブフォームの組み合わせを使用します.クライアントに関連するすべてのデータを表示するクライアント情報とサブフォームを含むメインフォームを作成できます.

これは、エンゲージメントレターリストの形式によって異なります.表のような形式の場合は、比較できるはずです.

ここでも、サブフォームを使用して特定の返品データを表し、表示したものとまったく同じまたは非常に類似したフォームを再現できます.特定のTaxDistrictIDをフィルタリングすることを提案したtableにクエリを作成します.

はい、ClientIDとTaxYearは、親table(表示したtable)のフィールドです.私が示したように、私が提案したtableの各レコードは、そのtableのレコードに関連付けられています.したがって、サブフォームはそのキーフィールドにリンクされます.その場合、メインフォームのレコードに一致するデータのみが表示されます.

これらはすべて、リレーショナルデータベースがどのように機能するかについてのSOPです.

応答3# ->にスキップ
4 #
Jocelyn

さて、皆さん、再起動して再試行するのに十分な情報があります.正規化について説明してくれたScottに感謝します.どこかに着いたら間違いなくもっと質問がありますが、今のところ...ありがとうございます!

応答4# ->にスキップ
2 #
Scottge

ご不明な点がございましたら、お気軽にお問い合わせください.

応答10# ->にスキップ
9 #
theDBgu

やあ.はい、table構造は少し正規化を使用できます.データベースの目的と、モデル化しようとしているビジネスプロセスについて説明してください.ありがとう.

応答9# ->にスキップ
6 #
Jocelyn

正規化のルールがわかりません.私はAccessの初心者です.申し訳ありませんが、それから始めるべきでしたが、機能的でユーザーフレンドリーなデータベースを作成しました.

データベースは、税金に関連するすべてのものに使用されます.これが私が持っているtableです:

  • すべてのクライアント:クライアントID、名、姓、会社名、エンティティタイプがあります.

  • エンゲージメントレター:個々のエンゲージメントレターを追跡します.どのように送信したか、いつ、誰が送信したか、いつ受信したか.

  • PDFlyerScan:クライアントのデータをいつScanしたかを追跡します

  • Scanされた納税申告書:納税申告書をScanした日時、ページ数、フォームなどを追跡します.

  • 税務フォーム:さまざまな種類のフォームのリスト.これはロギングには使用しません.これはコンボボックスのリストにすぎません.

  • 税務オーガナイザー:税務オーガナイザーを追跡します.どのように送信したか、いつ、誰が送信したか、いつ受信したか.

  • 税の設定:納税申告書を設定するとき

  • 課税年度:課税年度のリスト.これはロギングには使用しません.これはコンボボックスのリストにすぎません.

  • TR処理済み:納税申告書をいつ処理し、どのようにクライアントに送信したかを追跡します.

基本的に、上記の情報はすべて、物事が完了したときに文書化するためのものであり、記録があります.また、特定のクライアントに対して行われたことの概要を把握できるように、上記の表のほとんどを1つのフォームにまとめた「クライアントの概要」というフォームもあります.

現在、拡張機能と電子ファイルのtableを追加しようとしています.上の図のすべてのフィールドは、1つのクライアントに使用されます.TL#は、クライアントに発行する送付状の番号であるため、クライアントごとに異なります.期限は、クライアントが拡張/電子ファイリングに支払う必要のある金額であり、金額は、クライアントが実際に支払った金額です.クライアントを逃したかどうかを知る必要があるため、このtableが必要です.その年の納税申告書を処理しなかった場合は、拡張子/電子ファイルの金額を発行する必要があります.最終的には、TRが処理されていない、または延長金額が支払われていないクライアントを生成するレポートを作成します.

正規化ルールとは何か、そしてそれをこのtableに適用する方法を理解するのを手伝ってもらえますか?私はそれについて読んでいて、この情報を分離する方法を理解していません.tableを5つの異なるものに分割しますか:Federal ExtensionとE-File、Hawaii ExtensionとE-File、GE ExtensionとE-File、TA ExtensionとE-File、およびOther Extension and E-File?繰り返される情報は、ファイルの場所、スタッフ、通知者、ログ記録者など、フィールドリストの上半分にあります.これらはすべてスタッフのイニシャルです.または、いくつかの異なるオプションがあるため、ドロップダウンとして設定したIRSOfficeフィールドとStateフィールド.

最終目標:フォームにはすべてのフィールドが含まれるため、すべての拡張機能の概要を確認でき、金額や支払いの種類などを記録するためにも使用できます.クライアントからより多くの情報を入手した場合.その後、クライアントと課税年度でフィルタリングできます.

申し訳ありませんが、これはとても長いです.課税年度ごとに変更するのがそれほど難しいとは思っていませんでした.諦めて、代わりに前と次のボタンをフォームに配置する準備がほぼ整いました.