ACCESS 排他制御について考える・その２ [ACCESS]
この記事も試行錯誤して失敗した、その経緯を記述した物なので、参考になりません。
切にACCESSでの排他の方法をお探しの方は、他を当たってください。
さて、いろいろ排他について調べていて、もう一つ排他に使えそうな物を見つけました。
ACCESSの接続文字列の中に、
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=･･･;Mode=Share Deny Read|Share Deny Write;･･･
という部分があります。
このShare Denyは、排他に関する記述というのは知っていたので、改めて内容を調べてみました。
ACCESS 排他制御について考える [ACCESS]
最初に断っておきますが、もしもこれをご覧になっている方が、業務システムをACCESSのACCDB（MDB）のみで構築しようと考えていて、信頼度の高い排他制御の方法をお探しでしたら、この記事は役に立ちませんのでご了承ください。
ACCESSに関するBlogをやっていて何ですが、ACCESSだけで業務用のシステムが構築できるなんて思ってません。ACCESSのDB向けに用意されたUI環境は、小規模から中規模くらいまでのシステムを効率よく開発するのには有用だと思っています。しかし、信頼性の高いデータベース運用の要求には応えられないと思います。
OracleやSQLServerといったデータベースは、バックアップや履歴をきちんと保管しておけば、何かあったときに、何日の何時何分何秒を指定して、その時点の状態に戻すことができます。
トランザクション処理も、一応ACCESSでもできますが、処理可能な容量が小さいようで、おそらく実用になりません。
レポート グループ毎に改ページして、レポートフッターをグループフッターの直後に出力する [レポート]
グループフッターのプロパティで、「改ページ」を「カレントセクションの後」に設定することで、グループ毎にページが変わるようになります。しかし、この方法だとレポートフッターがある場合、最終ページにはレポートフッターだけになってしまいます。
このようなレポートで、上記の設定を行った場合、
最後のグループが印刷された後、改ページされて、
レポートフッターが印刷されます。
ACCESS2010 フィールドリストから項目をドロップすると、何か変な事に [ACCESS]
えーと、なにやらバグっぽい現象を見つけたので、載せておきます。
フォームのレコードソースにSQL文を設定した場合、フィールドリストから項目をドロップしてテキストボックスを設置した場合、初回のみ内容がおかしくなります。
こんなふうに、SQL文がテキストボックスのコントロールソースに設定されてます。
再現手順はこちら。
システム設計の話 その７・テーブル設計 全体 [システム設計の話]
前回までで、一通りシステムの内容をさらいましたので、それを考慮しながら、テーブル設計の作業に進みます。
実際のお仕事だと、1段階目の打ち合わせが終了という所です。最初にざっとお客さんの要望を聞いて、その後持ち帰って、提案内容をまとめる作業に入ります。
まだ提案の段階なので、お客さんに機能の説明と確認ができる資料があれば良いので、テーブル設計のような詳細部分は必要ないのですが、テーブルがシステムの要なので、早い段階から検討しておいた方が良いと思います。
まずは、どんなテーブルが必要になるかを、ざっくり考えていきます。
売上伝票管理なので、売上データ用の「売上データテーブル」が必要です。
このシステムは、1つの売上伝票には、複数の商品の明細があります。なので、テーブルを2つに分けて管理するようにします。
1つのテーブルには、売上伝票に関する情報を持たせます。日付や、顧客などの、1伝票に付き、1つだけ発生する情報です。
2つ目のテーブルには、明細部分の情報を持ちます。売り上げた商品が複数あれば、その分レコードを追加していく形になります。
と、言うことで、売上データには、「売上伝票データ」テーブルと、「売上明細データ」テーブルを設けます。
今回のシステムでは、発生するデータは売上データのみなので、データテーブルは以上です。
次に、マスタテーブルを考えます。
その４に出てきた、帳票の内容を満たすことができるように考えていきます。
まずは当然「顧客マスタ」。顧客名や、住所などの情報を持たせます。
社内の担当者も必要なので、「担当者マスタ」を設けます。
売り上げる商品の情報もマスタにすべきですので、「商品マスタ」に持たせます。
ざっと、上記の物が洗い出せました。
その他に、売上伝票番号を管理する方法や、自社の情報、消費税率の設定、テーブルの項目をコード化したときの対応する名称をもっておくコード名称、といった細かい用途のテーブルが必要と思われます。
それぞれ個別にマスタを設けても良いのですが、この段階ではとりあえずなんでも放り込める、「コードマスタ」というなんでもマスタを一つ想定しておきます。
以上、ざっとおさらいです。
○データテーブル
1.売上伝票データ
2.売上明細データ
○マスタテーブル
1.顧客マスタ
2.担当者マスタ
3.商品マスタ
4.コードマスタ
とりあえず、こんなテーブルが必要かなという大枠が決まりました。次は、個々のテーブルの項目内容を考えて行きます。
