ラベル Access の投稿を表示しています。 すべての投稿を表示
ラベル Access の投稿を表示しています。 すべての投稿を表示

2012/09/12

【Access】VBA無しでどこまでできるの?最終回

 前回(その4)の続きです。

 最近、長くなりがちなのでさくさくやっちゃうぞーってことでレポート作成です。クエリはその3の時にほとんど出来てるんでちょこっと抽出条件をフォームを参照するように修正してやればOKです。月別の抽出条件「Between [抽出開始] And [抽出終了]」の部分はメニューフォームに入力された年と月を条件にするため、DateSerial関数を用いて抽出開始と抽出終了を割り出します。式は「Between DateSerial([Forms]![MenuForm]![txtReportYear],[Forms]![MenuForm]![txtReportMonth],1) And DateSerial([Forms]![MenuForm]![txtReportYear],[Forms]![MenuForm]![txtReportMonth]+1,1)-1」となります。「txtReportYear」と「txtReportMonth」はメニューフォームに設置した年入力テキストと月入力テキストの名前です。

 さて、ウィザードで一発じゃぁって感じで行こうと思ってましたが実際やってみると何かごちゃっとしてて気にくわなかったので手作業でシンプルに作ります。


日別レポート(商品ベース)

デザインビュー

2012091201

印刷プレビュー

2012091202


日別レポート(メーカーベース)

デザインビュー

2012091203

印刷プレビュー

2012091204


月別レポート(商品ベース)

デザインビュー

2012091205

印刷プレビュー

2012091206


月別レポート(メーカーベース)

デザインビュー

2012091207

印刷プレビュー

2012091208


 特に手をかけてないんで一気に出しちゃいました。メーカーベースの方は若干寂しい気もしますがまぁ良しとしましょう。どうでも良いことですがレポートの罫線ズレが気になる人は手で上位置、左位置を入力したらちょっとはましになりますよ。

 もうマクロもやっちゃいますか。

 まずはおなじみ(?)AutoExecです。マクロ名に「AutoExec」とつけると起動時に自動実行されます。これにメニューフォームの起動を設定します。あとは各フォームの起動、各レポートの起動、在庫計算のクエリの実行を作成すればOKです。「マクロは簡単なやつしか駄目!」ってお約束なのでどれもオブジェクト名と表示形式を指定しただけにしています(なので画像等は載せません)。あとは作成したマクロをメニューフォームの各ボタンに割り当てるだけです。

割り当て中の図

2012091209


 これでついに完成です。…終わり方があっさりしすぎですか?

 結局5回も費やして初心者に優しくない初心者講座みたいになってしまったような…。まぁ、VBAは何とか使わずに乗り切りました。在庫計算とか若干ひどい気もしますが、まぁこんなもんでいいでょ?◯◯くん。



All About スタイルストア

2012/09/11

【Access】VBA無しでどこまでできるの?その4

 その3の続きです。
 今回もちゃちゃっとやっちゃいますよ。まずは必要になるフォームを考えてみます。当然メインとなるは売上台帳ですね。これをつけるために作ってるんですから。あとは各種マスター編集用のフォーム。それからと…。
 「ああっ。」
 って本当に声が出ちゃいました。自分、完璧に「在庫データ」なんてのを作ったことを忘れておりました。…これどうしよ。ま、まぁこれは後で何とかしよう。
 若干動揺しましたが、とりあえず売上台帳から作ります。色々ギミックを仕込んで…といきたいところですが、とりあえずはシンプルに作ることにします。というか実際色々とシミュレーションしてみたんですが、VBA使えないとやっぱり苦しいところが多々あったのでぶっちゃけ諦めました。
 ここでひとつお詫びが…、前回フォームにはクエリはいらんって言ってましたが、どうやら2つくらい必要になりそうです。1つが売上台帳用のクエリ、もう1つが在庫データ更新用のクエリです。いやぁー、無計画って怖いですねー(無責任)。
売上台帳用クエリ(物理名:SalesForm)
2012091104
在庫データ更新用クエリ(物理名:UpdateStocks)
2012091105
 在庫データ更新用クエリが難解に見えるかもしれませんが、要するにパラメータ「日付」で抽出された「Salesテーブル」と一致する「GoodsId」を持った行の「Qty」を「Salesテーブル」の「Qty」で引いてみなさいってことです。何か余計に難解な文章になってしまいましたね。売上台帳用の方は「入力日」というパラメータを用いることで入力する日を限定してしまおうって魂胆です。入力時に以前のデータがづらづら表示されても邪魔なので。
 ではやっとフォームです。
売上台帳(物理名:SalesForm)
デザインビュー
2012091102
フォームビュー
2012091103
 ちょっとシンプルすぎないか不安になりますが…。データソースはもちろんさっき作ったクエリです。見ての通り「SalesIDフィールド」と「SaleDateフィールド」は非表示に、「GoodsIdフィールド」はコンボボックス化して商品名を表示するようにしています。コンボボックスはよくある手法なのでいちいち解説しません。ヒントは列数2、列幅0,◯cm(◯は任意)。「SaleDateフィールド」の既定値は次に作るフォームから引っ張ります。
 次は売上台帳の入力日を確定する作業を入れたいのでそれを行うフォームを作ります。実際の作業順序からするとこいつがAccessを起動した時に表示するトップフォームになりそうなのでいっそのこと色々乗っけてメニューフォームにしちゃいましょう。
メニュー(物理名:MenuForm)
デザインビュー
2012091106
フォームビュー
2012091107
 おぉ、メニューフォームを作ると何だかそれっぽく見えてくるものですね。何かこれだけで満足しちゃいそうですが、クエリ等のパラメータをこのフォームに設定し直します。一応、下記に一例。
クエリ修正一例
2012091108
 このように抽出条件を[Forms]![対象フォーム]![対象コントロール]とすることでフォームのコントロールを参照することが可能です。これで売上台帳はメニューフォームで指定された日付で表示される予定です。
 フォームを2つ作っただけですが、なんだか雑多になってきたので今回はこの辺でやめておきます。あと、マスター編集のフォームは面倒くさいので省略します(ウィザードで一発で済むので)。
 次回はレポートと出来ればボタンを動かすためのマクロを作ります。


HP Directplus オンラインストア

2012/09/08

【Access】VBA無しでどこまでできるの?その3

 その2の続きです。
 順調にテーブルができたので次はクエリに移りますが、やっぱり初心者はクエリって難しく感じるみたいです。リレーション自体を掴めてないせいもあるかもしれませんが何をどうくっつけて、どう条件をつければいいのか分からないって人が多いようです。そんな人にはまず完成後の表をExcelか何かで書いてみることをお奨めします。もちろんフィールド名から書式まで理想とする完成形を作ってみて下さい。あとはそれを逆算的にクエリが作成できるよう分解していきましょう。このときクエリを無理に一纏めとかにしないよう自分のレベルに合わせて細分化します。

例
Dをグループ化したクエリ(完成形) ← BとCを結合したクエリ(D) ← Aに抽出条件を設定したクエリ(C) ← テーブル(A)
                                 ← テーブル(B)

 例のようにすると一つ一つのクエリの難易度が下がるので多少はやりやすくなると思います。自分は今でも定義に悩んだ時はよくやったりするのでクエリが分かんないって人はやってみてください。
 では本題に戻って今回使用するクエリを考えてみます。今回、フォームは直接テーブルを操作するケースが多くなりそうなのでクエリを利用することはほぼなさそうです。せいぜいコンボボックスのソースにってとこですがこれはコンボボックス内で定義します。なのでクエリを利用するのはレポートのみになりそうです。作成予定のレポートは前提条件(VBA無しでどこまでできるの?その1)からすると日別売上レポート(商品ベース)、月別売上レポート(商品ベース)、日別売上レポート(メーカーベース)、月別売上レポート(メーカーベース)ってとこでしょうか?それでは各レポートに使用するクエリを考えてみましょう。
 さて各レポートに使用するクエリと言いましたが、結局のところ全部が売上に関するレポートなので大本になるのは売上データになりそうです。売上データを日別、月別に抽出し、それに商品なりメーカーなりを結びつけるなりグループ化するなりすればいいじゃないか?って感じです。
 では早速、日別、月別に売上データを抽出するクエリを考えます。これよく考えると1つで済ませることできなくはないんですが、今回はまじめに2つ作ります。

日別売上データ(物理名:DaySales)
2012090801

月別売上データ(物理名:MonthSales)
2012090802

 う~ん、ちょっと幼稚するぎるかなぁって気もしないでもないですが…。一応解説しておくとWHERE句に入力している[]に囲まれてるのがパラメータになります。このパラメータは最終的にはフォームから引っ張るようにする予定なので今回は仮のパラメータです。
 さて、面倒くさくなったわけではありませんがあとはさくっと完成させちゃいましょう。

日別売上データ(商品ベース)(物理名:DayGoodsSales)
2012090803

月別売上データ(商品ベース)(物理名:MonthGoodsSales)
2012090804

日別売上データ(メーカーベース)(物理名:DayMakersSales)
2012090805

月別売上データ(メーカーベース)(物理名:MonthMakersSales)
2012090806

 こんな感じでどうでしょう。商品ベースで組む際にメーカーのフィールドも結合しちゃうことでメーカーベースの時に商品ベースをグループ化するだけで済むようにしています。
 こうやってやってみるとちょっと前提条件が緩すぎて簡単になりすぎちゃって初心者講座なの?どうなの?って感じになってる気がしないでもないですが、とにかく次回はフォームを作ってみます。


trystrams

2012/09/07

【Access】VBA無しでどこまでできるの?その2

 タイトル縮めちゃったけど前回の続きです。
 さて、前提条件が揃ったのでさっそく実践にとりかかるとしましょう。とりあえず移行手順を考えてみましょう。

1.台帳を正規化しながらテーブルを設計します。
2.フォームやレポートに必要と思われるクエリを作成します。
3.入力及び閲覧用フォームを作成します。
4.指定された集計レポートを作成します。
5.フォームやレポートを開くマクロを作成します。

 こんなとこでしょうか。まぁ問題が発生したらその度に対応してきましょう。 
 では今回は「台帳を正規化しながらテーブルを設計」にチャレンジしましょう。正規化が苦手な人、分かんない人はとりあえず1つのデータの固まり(今回は台帳)の中に日付や数値以外で重複する項目を探し、見つかったらそいつは正規化候補だと思って列挙してみてください。それから列挙したものを同一のグループにできないか考えてみましょう(例えば商品名と単価とか)。そうやってグループ分けしてできたものがテーブルになります。…我ながらなんて安直な説明でしょうか、でも個人的には最初はそんなもんでOKだと思います。こーゆーのはやってくうちになんとやらです。

商品マスター(物理名:Goods)
論理名 物理名 型 主キー 外部キー
商品ID GoodsId オートナンバー ◯
商品名 GoodsName テキスト
単価 Price 通貨
商品カテゴリーID GoodsCategoriesId 数値 ◯
メーカーID MakersId 数値 ◯

商品カテゴリーマスター(物理名:GoodsCategories)
論理名 物理名 型 主キー 外部キー
商品カテゴリ-ID GoodsCategoriesId オートナンバー ◯
カテゴリー名 CategoryName テキスト

メーカーマスター(物理名:Makers)
論理名 物理名 型 主キー 外部キー
メーカーID MakersId オートナンバー ◯
メーカー名 MakerName テキスト
電話番号 Tell テキスト
FAX番号 Fax テキスト

売上データ(物理名:Sales)
論理名 物理名 型 主キー 外部キー
売上ID SalesId オートナンバー ◯
売上日 SaleDate 日付/時刻
商品ID GoodsId 数値 ◯
数量 Qty 数値

在庫データ(物理名:Stocks)
論理名 物理名 型 主キー 外部キー
在庫ID StocksId オートナンバー ◯
商品ID GoodsId 数値 ◯
数量 Qty 数値

 いきりなりまじめな設計するなって言われそうですがこんな感じでどうでしょう?。せっかくなんで商品カテゴリーも作っちゃいました。これで商品カテゴリーマスターと商品マスター、商品マスターと売上データ、商品マスターと在庫データ、メーカーマスターと商品マスターがそれぞれ1対多になるのでリレーションシップも設定しちゃいます(マスターとデータ(トラン)の違いやリレーションシップはさすがに基礎過ぎるので省略します)。売上データや在庫データの仕組みとか、もっとしっかり考えてもいいんだけどやりすぎちゃうと趣旨が変わっちゃうのでこのへんにしときます。
 あと、日付/時刻型について「VBAを使う場合、エラーの温床となる可能性があるのでテキスト型にした方が良い」とよく言われてますが個人で開発する分には日付/時刻型で大丈夫なんじゃないの?ってのが自分の感想です。まぁ今回はVBA使わないので遠慮なく日付/時刻型です。

リレーションシップの図
2012090701

 では、今日はここまで。


デル株式会社

2012/09/06

【Access】ExcelからAccessへ移行…VBA無しでどこまでできるの?

 別の会社に勤める知人が「上司がExcelをAccessに移行したいって、というかしてくれって言うんだけど…。自分今までAccessとかかまったことないし、プログラムとか絶対無理なんだけど…。そういうのって簡単にできるの?」って聞いてくるので「業者に頼め。」と冷たく言っちゃったんですが、さすがに可哀想なのでちょっと真剣に考えてみます。
 まず考えるべきなのは本当にデータベース化する必要があるかどうかです。自分的には1シートに20列×1000行くらいのデータなら別にExcelのままでもいいんじゃないって感じてます。それくらいならVlookupとか使えば入力の手間もそんなにかからないだろうし、統計・集計はピボットなり何なり使えば簡単にできますしね。逆にそれ以上ならAccessに限らずデータベースにしちゃった方がいいかもしれません。個人的に横長のExcelシートは嫌いだし。まぁ今回は余所様の会社の話で自分が説得するわけにもいかないのでAccessにすること前提で考えます。
 …ぶっちゃけサンプル作るのが若干面倒ですが頑張って作ります。まずはさすがに知人の案件をまんま載せるわけにいかないし、そんなに突っ込んで聞いたわけではないので自力でそれっぽい前提条件を考えるとしましょう。

前提条件
あるPC苦手なお婆さんが経営する駄菓子屋では入荷・売上を管理するのに手書きの台帳を使っている。台帳は売上入力用、取引先一覧の2つに分かれている。
売上入力用
日付 商品 単価 数量 売上 在庫
9月1日 あめちゃんA 10 25 250 125
あめちゃんB 10 18 180 132
チロルチョコA 20 31 620 119
チロルチョコB 20 26 520 124
合計 100 1570  
9月2日 あめちゃんA 10 30 300 95
あめちゃんB 10 15 150 117
あめちゃんC 100 1 100 149
チロルチョコA 20 22 440 97
チロルチョコB 20 20 400 104
合計 88 1390  
9月3日 あめちゃんA 10 40 400 55
あめちゃんB 10 35 350 82
チロルチョコA 20 29 580 68
チロルチョコB 20 10 200 94
合計 114 1530  
9月4日 あめちゃんA 10 15 150 135
あめちゃんB 10 20 200 135
チロルチョコA 20 29 580 139
チロルチョコB 20 20 400 124
合計 84 1330  

メーカー一覧
メーカー 電話 FAX
(株)Yamada xxx-xxxx-xxxx xxx-xxxx-xxxx
有限会社Sato xxx-xxxx-xxxx xxx-xxxx-xxxx
Tanaka菓子 xxx-xxxx-xxxx xxx-xxxx-xxxx



要望
手書き台帳をAccessへ移行したい。テーブルは極力正規化する。移行後は極力入力作業を減らし、簡単に日別、月別の商品毎、メーカー毎の集計を出力出来るようにする。
制約
テーブルの正規化に際し、不足している列等あれば追加してもよい。直接VBAを書くのは全面的に禁止。マクロについては簡易なもの(フォーム、レポートを開く等)は可とする。テーブル、クエリ、フォーム、レポート全てにおいてデザイナを用いて作成可能な範囲で作成すること。


 Excelじゃねーのかよって突っ込みたい気持ちも分かりますが、極端な例として手書きってことにしちゃいました。別に状況的にExcelも手書きも変わらないだろってことで…。
 それである日孫が東京から帰ってきて言うわけですよ。「俺、ばあちゃんの駄菓子屋継ぐよ!!」って、で継いでみてこの手書き台帳を見て驚愕するわけですよ。今までこれでどうやってやってきてたんだって。こうなったら自力で学生時代にちょこっと習ったAccessで作ってやるってわけです。あ、あとメーカーってしちゃったから直接仕入れってことで…。

 さて、前提条件考えただけで疲れてきたので今回はこの辺で…。次回から実践に移っていきます。

B's 動画レコーダー 2

2012/09/05

【Access】パラメータクエリにフォームのコントロール割り当てた時の問題点【VBA】

 今日も今日とて悩める後輩君。例によって頭を抱えていたので聞いてみた。
 以下、内容。
とある同一のクエリを使用し、フォーム(単票)とサブフォーム(データシート)を作成した。フォームとサブフォームの関係は親子ではなく対等であり、サブフォームをフォームのナビゲーションとして利用する。要はサブフォーム側のレコードを移動するとフォーム側のレコードも同じレコードに移動するというものである。
若干状況が分かりにくいのでここで一端サンプルとイメージを提示しときます。

テーブル
Books
Id
BookName
Price
Sales
Id
BookId
SaleDate
Num


クエリ
SaleList
Id
SaleDate
BookName
Num
Sale
(Num*Price)

フォーム
2012090501
ソース
'サブフォームのレコード移動時イベント
Private Sub Form_Current()
 
    '親フォームのレコードを自身のレコードのインデックスに移動する
    DoCmd.GoToRecord acDataForm, "SalesForm", acGoTo, Me.CurrentRecord
 
End Sub

 こんな感じです。こんな風にしたらって言ったのは自分ですが、面倒なことをさせてしまったもんです。…さて、後輩君もここまでは何も問題なく作成しておりました。

 問題はここからです。以下、再び内容。
フォームに使用したクエリに外部のフォームで確定した条件で抽出する必要が発生した。クエリをパラメータクエリに変更し、対象となるフォームのコントロールを参照するよう変更する。
これだけだと何が問題なのって感じですよね?とりあえずその通りにサンプルを追加・変更してレコード移動してみます。

フォーム(パラメータ設定用)
2012090502

クエリ
SaleList
Id
SaleDate
(Where: SaleDate = Forms![ParamForm]![SaleDateText])
BookName
Num
Sale
(Num*Price)

実行時
2012090503
 あれ?サブフォームのレコード移動するとこけるようになっちゃいましたってなわけです。う~ん、細かく見てみましたがぶっちゃけはっきりとした原因は分かりませんでした。流れ的にはサブフォーム側の移動が実行され、フォーム側の移動が実行されるんですが、ここで終了せず何でかサブフォームの先頭レコードにフォーカスが移っちゃって再度同じイベントが発生して…って感じです。自分の推測としては移動後にパラメータクエリのフォーム参照が再評価に走ってフォームのフォーカスが飛んじゃってるんじゃないかなって感じです。すごく不確かですが。こりゃ後輩君も悩むよねって話です。
 とりあえず後輩君にはこのやり方自体諦めて違う手段を考えようって言いました。後輩君には教えなかったんですが自分的な代替え案としてはパラメータクエリを諦めて、外部フォームを参照するのをクエリではなくフォームにしてフィルタで対応したらってとこですね。一応サンプル載せときます。当然、後輩君はこのブログを知りません。

ソース(メインフォーム側)
'メインフォームのオープン時イベント
'Loadで書くとフィルタの挙動がおかしくなったのでこちらにしました
Private Sub Form_Open(Cancel As Integer)
 
    '外部フォーム(ParamForm)の設定値を取得
    Dim param As String
    param = Forms!ParamForm!SaleDateText
    
    '自身のフィルタ設定
    Me.Filter = "SaleDate = #" & param & "#"
    Me.FilterOn = True
    
    'サブフォームのフィルタ設定
    Me.SubForm.Form.Filter = "SaleDate = #" & param & "#"
    Me.FilterOn = True
    
End Sub


HP Directplus オンラインストア

2012/08/29

【Access】複数のテーブルを1つのフォームで更新する方法を考える【VBA】

 後輩君が何やら頭を抱えて悩んでいたので聞いてみた。

「現在とある業務で使用してるAccessのテーブル「A」と「B」と「C」は正規化の観点からするとひとつのテーブルに集約することができるが、フィールド数が多くなることと、業務の流れとして「A」が確定してから「B」と「C」を入力するということであえて分割してある。現在、それぞれのテーブルを更新・削除を行う場合、個別のフォームを用いているが、作業量が増えてきた関係で煩わしくなってきた。更新・削除を1つのフォームから行うことはできないだろうか?」

 …というのが悩みの種のようです。ちなみに後輩君のレベルは簡単なクエリとそれに基づいたフォームが作れるくらいです。確かにちょっと悩んじゃうかもしれません。個人的には追加部分を工夫するとして正規化しちゃえばいいじゃんってとこですが、まぁ、そうできないケースも今後発生するかもしれないのでとりあえずこのまま挑戦させてみようかなぁってことで、このブログでは後輩君をほっておいて自分的な考察やらコードをあげちゃいます。聞くだけ聞いてなんなんですが後輩君には自分で考えてもらいます。

 とりあえずサンプルデータです。「A」「B」「C」のテーブルは「A」を基点としてそれぞれ1対1で連結しています(フィールド数が少ないことは気にしない)。

A B C
Id AName Id AId BName Id AId CName
1 太郎 1 1 犬 1 1 オス
2 花子 2 2 猫 2 2 メス


 次に根本的な考え方ですが、フォームとテーブル(クエリ)の連結は最初からあきらめちゃいます。どうやら後輩君が1番引っかかってる部分のようですが、1つのフォームに複数のテーブルを連結することはできません(たぶん)。サブフォームを2つ使えばって考えもありますがその場合、更新のタイミングの問題も出てくると思います(例えばBを更新する際、AとCの更新は?みたいな)。イメージ的には下図のようになります。

フォームに表示する流れ
image

更新・削除をする流れ
image

 VBA上でSQL文を使用して「A」「B」「C」各テーブルと「A」「B」「C」を結合した独自型をつなげ、その独自型とフォームを連動させます。独自型を使うのははっきり言って趣味です。飛ばして直でフォームにいっちゃっても問題ないと思います。それでは流れに基づいてメソッドを作ってみます。

Option Compare Database
Option Explicit
 
'独自型
Public Type MyData
    Id As Integer  'このIdはAのId
    AName As String
    BName As String
    CName As String
End Type
 
'生成メソッド
Public Function GetMyData(targetId As Long) As MyData
 
On Error GoTo ErrProcess
 
    Dim cn As ADODB.Connection
    Set cn = CurrentProject.Connection
    
    Dim selectSql As String
    selectSql = "SELECT A.Id, A.AName, B.BName, C.CName " _
        & "FROM (A INNER JOIN B ON A.Id = B.AId) " _
        & "INNER JOIN C ON A.ID = C.AId WHERE A.Id = " & targetId
    
    Dim rs As ADODB.Recordset
    Set rs = New ADODB.Recordset
    rs.Open selectSql, cn, adOpenKeyset, adLockReadOnly
    
    Dim result As MyData
    
    '0件はエラー、2件以上については今回は考えません
    If (rs.RecordCount = 0) Then
        MsgBox "レコードを取得できませんでした。", vbExclamation, "エラー"
    Else
        result.Id = rs!Id
        result.AName = rs!AName
        result.BName = rs!BName
        result.CName = rs!CName
    End If
    
    rs.Close: Set rs = Nothing
    cn.Close: Set cn = Nothing
    
    GetMyData = result
    
Exit Function
 
ErrProcess:
 
    rs.Close: Set rs = Nothing
    cn.Close: Set cn = Nothing
    
    MsgBox Err.Description, vbCritical, "エラー"
    
End Function
 
'更新メソッド
Public Sub UpdateMyData(updateData As MyData)
 
On Error GoTo ErrProcess
 
    Dim cn As ADODB.Connection
    Set cn = CurrentProject.Connection
    
    Dim updateSqlA As String
    updateSqlA = "UPDATE A SET AName = '" & updateData.AName & "' " _ 
        & "WHERE Id = " & updateData.Id
 
    Dim updateSqlB As String
    updateSqlB = "UPDATE B SET BName = '" & updateData.BName & "' " _ 
        & "WHERE AId = " & updateData.Id
    
    Dim updateSqlC As String
    updateSqlC = "UPDATE C SET CName = '" & updateData.CName & "' " _ 
        & "WHERE AId = " & updateData.Id
    
    cn.Execute (updateSqlA)
    cn.Execute (updateSqlB)
    cn.Execute (updateSqlC)
    
    cn.Close: Set cn = Nothing
    
Exit Sub
 
ErrProcess:
 
    cn.Close: Set cn = Nothing
    
    MsgBox Err.Description, vbCritical, "エラー"
    
End Sub
 
'削除メソッド
Public Sub DeleteMyData(deleteData As MyData)
 
On Error GoTo ErrProcess
 
    Dim cn As ADODB.Connection
    Set cn = CurrentProject.Connection
    
    Dim deleteSqlA As String
    deleteSqlA = "DELETE FROM A WHERE Id = " & deleteData.Id
    
    '連鎖削除設定してたら以下のBとCのDELETE文は不要
    Dim deleteSqlB As String
    deleteSqlB = "DELETE FROM B WHERE AId = " & deleteData.Id
    
    Dim deleteSqlC As String
    deleteSqlC = "DELETE FROM C WHERE AId = " & deleteData.Id
    
    cn.Execute (deleteSqlA)
    cn.Execute (deleteSqlB)
    cn.Execute (deleteSqlC)
    
    cn.Close: Set cn = Nothing
 
Exit Sub
 
ErrProcess:
 
    cn.Close: Set cn = Nothing
 
    MsgBox Err.Description, vbCritical, "エラー"
    
End Sub


 やってることはシンプルにしたつもりです。あとはリスト型のフォームと入力用のフォームを用意して各メソッドを呼び出してやれば完成です。さすがにフォームは省略させて下さい。


 以上が自分なりの後輩君の悩みへの解決方法です。いやぁ、後輩君はどんな方法で解決するか楽しみですね~。簡単にギブアップしないことを祈ってます。
pagetop