アクセスでのデータ管理について（長文です。）

質問

アクセス初心者です。
これからデータの入力、管理、帳票をアクセスで構築しようと思っているのですが、アクセスはデータを入力した時点でデータが保存されてしまうので過去のデータが残りません。またデータの変更及び共有をうまくやりたいのですがよい方法がわかりません。
今回構築したいデータベースは、
１．過去の記録がすぐわかるようにしたい。（更新前のデータがわかるようにしたい。）
２．データの変更及び共有を簡略化したい。（Ａ社で変更したデータをＢ社のデータベースにいれこみたい。）

【データベースの概略イメージ】
　Ａ社　　　　　　Ｂ社
データベース１　データベース２（１と同じもの）
テーブル１　→　テーブル１
テーブル２　→　テーブル２
テーブル３　→　テーブル３
クエリ１　　　　クエリ１
クエリ２　　　　クエリ２
フォーム１　　　フォーム１
フォーム２　　　フォーム２
＊リレーションあり

＊Ａ社でテーブル１の内容を変更して、Ｂ社のテーブル１を新しいものに置き換えたい。
（本を読むとリレーションが崩れると書いてありました。）
＊Ｂ社で変更してＡ社に戻すこともある。

テーブル１
項目
ＩＤ　１００
住所　あああ
氏名　△△様
電話番号　111-1111

＊例えば、ＩＤ１００のデータの氏名を変更するとき、変更前がどうだったかわかるようにしたい。（１月時点では△△様、２月時点では□□様とか）

誰かアクセスの操作方法に詳しい方がおられましたら、よい方法又はアクセスに関する詳しい本とかサイト等教えて下さい。よろしくお願いいたします。

回答No.5

delldelldell · ベストアンサー

「アクセスはデータを入力した時点でデータが保存さ
れてしまうので過去のデータが残りません」

↑これはフォームのデータソースがテーブルになってるからで、テキストボックスは全て非連結にし、更新ボタン押下でテーブル更新するように作ればよいです。

テーブルと他のオブジェクトは切り離しましょう。
データソース１.mdb－ＤＢ１.mdb
データソース２.mdb－ＤＢ２.mdb
実体－入物の関係。

データソース１、２にはテーブルのみが入ってます。
ＤＢ１、２には残りのオブジェクトたちがが入ってます。

データソース.mdbをＡ社→Ｂ社とかＢ社→Ａ社とすればよいかと。
リレーションは崩れません。

もちろんＡＢ社とも過去のデータソース.mdbはきっちり保存しておく。
そして検索フォームを作っておけば、すぐ過去データが調査できるかと。

もしくは、データソース.mdbを管理する別mdbを作って、テーブルが更新された際、テーブルをインポートし、中でグループ化すればよいかと。

こちらも長文でわかりにくい。

補足

回答ありがとうございます。

＞更新ボタン押下でテーブル更新するように作ればよいです。
更新ボタン押下で更新？

＞もしくは、データソース.mdbを管理する別mdbを作って、テーブルが更新された際、テーブルをインポートし、中でグループ化すればよいかと。
マクロとかＶＢとか利用する？グループ化？

すみませんが、なにぶん初心者なものでいまいちわかりません。よろしくお願いします。

回答No.6

delldelldell

ANo.#5です。

この手のツールを作るにはマクロかＶＢＡの知識が必要です。

多分ですが、理解されるべきは
１．非連結フォームを作成し、入力したデータをテーブルにインサートする。
２．テーブルが更新されたらテーブルをまるごとインポートし、クエリでグループ化し、さらにテーブル作成クエリで最新テーブルを作る。
３．データとアプリを分ける。

中でも２を早急に理解されることでかなり実現の近道になるかと思います。
要するに更新履歴が残るという意味です。

回答No.4

noname#223623

前の回答でテーブルが決まってからと言ったのですが「テーブルの更新」についてちょっとだけ書きます。私事ですがちょっと事情がありまして(あとで書きます)。

まずは更新の話。
> ＊Ａ社でテーブル１の内容を変更して、Ｂ社のテーブル１を新しいものに置き換えたい。
> （本を読むとリレーションが崩れると書いてありました。）
というのはテーブルそのものを上書きしようとするからでしょう。こういう場合は差分をテーブルに追加(または更新になるんでしょうが)してあげた方がいいと思います。今のところテーブルをどのようにするかが不明確なので具体的な方法はまだ書けませんが(あと、書くと長くなりすぎるので今回はご勘弁)。とりあえずのヒントにしてください。

それで私の事情なんですが、明日からしばらくマシンのない生活を送ることになりました。急なことで申し訳ないのですが私が回答することはもうできません。ごめんなさい。でも私よりもよっぽどできる人がいっぱいいるので大丈夫です(きっと)。なんか途中で投げ出すようで心苦しいのですが御理解下さい(今日はもうちょっと見てますけど)。

この質問を読んでいる方々、「何を勝手なことを」と怒られそうですがSky-Hさんを助けてあげて下さいね。すみません。

回答No.3

noname#223623

全貌がわからないのでもう少し詳しく聞かせて下さい。

このシステムは稼働中、もしくはテーブル構造の変更はしないという前提ですか？
> ＩＤを外のテーブルとリンク（リレーション）させないといけない...
これは決定ですか？決定でなければ、テーブル1にレコードを識別する項目(例えばrec_idとか)を追加して、これをキーにしてリンクしてもいいと思うんですが。どちらにしても外のテーブルの項目が知りたいですね。

あと、マクロ、VBAとかを使うのはありですか？

更新の話はテーブルが決まってからにします。

回答No.2

noname#223623

> ２．データの変更及び共有を簡略化したい
質問を読みかえしてみると、A社の変更が直ちにB社の方に反映しなくてもいいのかな？例えば1日一回更新するとか。どっちですか？

あと、サイトの紹介をしてなかったので参考URLを書いときます。このURLは過去の質問です。とりあえず、ここに書いてあるサイトを覗いてみては。

参考URL：

http://okweb.jp/kotaeru.php3?q=1119191

補足

早速の回答ありがとうございます。
質問がわかりづらくてすみません。
１．過去のデータについて
登録日を追加して、ＩＤと登録日を組み合わせたキーを作成というのも確かに考えたのですが、ＩＤを外のテーブルとリンク（リレーション）させないといけないことを考えるとどうしたらいいのか迷ってしまいました。
２．データの変更・共有について
１つのＤＢをネットワークを介して共有するのが一番だと思うのですが、それは出来そうにない（技術的にではなく、ネット環境が整いそうにない。）ので、お互い同じＤＢをもっておいて、基本的にはＡ社でデータ管理（変更等）を行い、あとでＢ社のデータを更新するように考えています。項目によってはＢ社のほうで変更したいテーブルもあるので、データを更新するときにお互いが変更した箇所だけ更新したいと考えています。つまり更新するときにＤＢそのものを入れ替えるのではなく、テーブルだけとかフォームだけとか更新できないかということです。よろしくお願いします。

回答No.1

noname#223623

> １．過去の記録がすぐわかるようにしたい
既存のレコードはそのまま置いといて、新規レコードで登録する。登録日のフィールドを追加して、通常は登録日の一番新しいものを使う。履歴が見たかったらIDで抽出すれば見られる。IDは重複するのでキーとなるフィールドも追加する必要がある(もしくはIDと登録日を組合せてキーにする。できたかな？)。

> ２．データの変更及び共有を簡略化したい
わざわざDBを2つ作らないで、A社、B社ともに同じDBを使用する。おそらくネットワークを介してアクセスすることを考えているんでしょう。接続方法は環境がわからないので書けません(わかっても詳しくないんですけど。詳しい人が教えてくれるでしょう)。基本的にAccess(MDB)は複数ユーザで使うようには考えられていないので、できれば違うDBを使用した方がいいんじゃないでしょうか。ユーザ数が多くないならMSDEでも。