Q、(1)(2)については、どのような設計をされていましたでしょうか?A、生データの編集とインポートを行うプログラムで対応。出力部門によって生データのどれとどれが必要なのかは大きく違ってきます。各担当部署は、生データ蓄積データベースから適当な時間を見計らって必要なデータを利用しやすい形に加工しつつインポート。加えて、独自に入力すべきデータの入力処理を行った後に、必要な演算と出力を行ってきたと記憶しています。生データ蓄積PCと各部門PCとは、サーバーで共有すべきデータについても吐き出していたんじゃーないかと・・・。>バッチのようなものを作り、それを深夜実行する。これは、MS-DOS時代のやり方。今の時代、どんなに大量のデータであっても数十秒で加工しつつインポートすることができると思いますよ。通報するこの回答へのお礼ご回答ありがとうございます。回答者様も、ご自分で全部お作りになられていたのですね。生産、請求処理まで作りたいと思います。その後、恐らく在庫管理システムを別DBでつくろうかなと。今後共、よろしくお願いします。)→テーブルと、フロントに分けるというふうに。分割・分散すれば、(その程度に応じて)それぞれのシステム間の相互参照、データ交換を必要に応じて必要なだけ実現するのか?という難題が生じます。それに、サーバーのみにデータベースを置くのでは必要とあらば幾つかの通常のWindowsマシンにもデータベースを配置することも視野に入れる必要があります。NT+Windows版データベースと3代を経ての分割・分散でしたから、割とスムーズに設計できました。非分散・分割型が良いかもしれません。私は、プロのプログラマではありませんので・・・。全体に「ふーん!」程度で読み流されたがいいですよ。(決して、適当に回答している訳ではありませんが・・・)この回答への補足ご回答ありがとうございます。)→テーブルと、フロントに分ける>>というふうに。>まあ、そういうことです。>が、分割・分散すれば、(その程度に応じて)それぞれのシステム間の相互参照、>データ交換を必要に応じて必要なだけ実現するのか?という難題が生じます。個々で、私が考えたのは次の2点です。1)データのやりとりの仕方2)複数の分割されたDB間で、互いのテーブル情報をどのような形で参照するか1)についてはa)バッチのようなものを作り、それを深夜実行する。b)アクセスで何か処理をした時に、他のDBに反映させる。2)についてはa)必要なDBの必要なテーブルのリンクテーブルを作り使用するb)PGで、他のDBのデータを参照する1)に関してバッチの実行とエラーが発生した時のメンテナンスの作業などを考えると、非常に大変な気がします。ITの担当が私だけですので。1人で全部作っていますから。(b)も、反映漏れが出てくる可能性を考慮すると、やはりするならバッチかなと思いますが。Serverに移行するのもありかと考えています。2)についてはaのリンクテーブルを作ると、そのデータ容量分、ファイルの量が増えそうな気がしますが実際には、増えるのでしょうか?試してみなくてはいけませんが。この(1)(2)については、f_a_007さんは、どのような設計をされていましたでしょうか。...いわゆる分散型データベースを模したということです。1、営業・顧客よりの受注データベース。3、CAD・CAMのフロントデータベース。4、在庫管理データベース。UNIXデータベース⇒Windowsデータベースへの転換時に、いわゆる分散型データベースを模したということです。当時は、「WindowsやAccessは遅くて使い物にならない」と酷評されていました。UNIXデータベースの後継システムは必要。分割・分散は苦肉の策ですた。大雑把に言えば、(1)生のデータを単純に蓄積するデータベース。(2)生データからそれぞれに必要な部分をインポートし加工・出力するデータベース。分割したとも言えます。この回答への補足ご回答ありがとうございます。)→テーブルと、フロントに分けるというふうにややこしいですが・・・よろしくお願いします。12:26Q1、この場合、アクセスはこわれたりすることはありうるのでしょうか?A1、こわれた経験はありません。こわれることあると思いますよ。私が一番に重要視したのは、次の2点です。1、不意の停電に備えてバックアップ電源を用意する。2、夏冬の長期休み明けの再起動は室温が安定してから。バックエンドのPCのDBMは一日一回はバックアップしてクラッシュに備えていました。Q2、ACCESSは、データの最大許容量の対応策。私の場合は、分割という対応を基本にしました。一番に開発したのは、コントロールパネルと酷似したメニューシステム。アプリの基本要素だと言明していたので・・・。Serverに移行するという手段があります。経験では、52倍速で動きます。Access2013では、あのADPのサポートが中止されました。ODBC接続に戻せば少し遅くなるかも知れませんね。ハードの進歩で帳消しかも・・・。PS、最新のWindowsPCよりも350MZのNT機がサクサク動く!SCシステムを構築する場合、やはり、重要なのはサーバー機の性能とOS。「最新のWindowsPCよりも350MZのNT機がサクサク動く!」ということもありえます。一応、サーバー機の性能とOSの検討の必要性も・・・。この回答への補足ご回答ありがとうございます。すみませんが、この「A2、分割。」と書かれているのは、フロントとバックエンドに分割すると言う意味でしょうか。データ容量が2GBの制限がある場合に、分割する方法とは、どのようなことなのでしょうか。サブ・メインフォームのリンク方法を教えてください。Access(アクセス)6Accessで、フォームからフォームへ値を引き継ぐやり方Access(アクセス)7Accessのフォーム上にレコード数とレコード番号の表示その他(データベース)8Accessセキュリティ設定でのバックエンドデータ保護Access(アクセス)9ACCESSのツールバーを非表示にしたいAccess(アクセス)10Accessを開くと「排他モードじゃないので変更しても保存できない」との旨の表示が出てしまう。別フォームへの再クエリ(更新)がしたい。サブ・メインフォームのリンク方法を教えてください。Access(アクセス)6Accessで、フォームからフォームへ値を引き継ぐやり方Access(アクセス)7Accessのフォーム上にレコード数とレコード番号の表示その他(データベース)8Accessセキュリティ設定でのバックエンドデータ保護Access(アクセス)9ACCESSのツールバーを非表示にしたいAccess(アクセス)10Accessを開くと「排他モードじゃないので変更しても保存できない」との旨の表示が出てしまう。別フォームへの再クエリ(更新)がしたい。Access」バーの非表示について。回答数ランキングです。職業心理カウンセラーこの専門家の回答をチェック他の専門家の回答をチェックこのQ&Aを見た人が検索しているワードバックエンドデータベースフロントエンドACCESS分割このQ&Aと関連する良く見られている質問QACCESSに同時アクセス(編集)をしたい教えてください。ACCESSのDBに複数のユーザが同時にアクセスして、データを追加・編集したいのですが、やはり、不可能でしょうか?Aベストアンサーマイクロソフトのアクセスに同時に複数のユーザが同時にアクセスしてデータベースを操作することは可能です。昔私が簡便に行なっていた方法は「テーブルのリンク」です。あるコンピュータにアクセスでdb1という名前のデータベースを作ってここにデータを格納しておきます。他方で別のコンピュータに、アクセスでdb2という名前のデータベースを作ります。このdb2というデータベースのメニューで「ファイル」->「外部データの取り込み」->「テーブルのリンク」というのがありますから、最初に作ったdb1をたどり、リンクしたいテーブルを選択します。することにより、db2にdb1のテーブルがリンクされ(リンクテーブルと呼ばれます。アイコンが通常のテーブルと違います。)、db1に格納されたデータをdb2で編集することができます。db2で、db1からのリンクテーブルを元にクエリーを作成することもできます。リンクテーブルに対してできないことはテーブル構造の変更くらいで他のことはだいたいできると思っていいかと思います。このような形をとれば、ローカルエリアネットワーク内の複数のコンピュータから同時に同じアクセスデータベースにアクセスすることは可能かと思います。このやり方にはおそらく問題もあるだろうと思うのですが、昔私がやっていた頃は、特段支障もなく業務を行なうことができました。問題は、これを読んだ他の誰かが指摘してくださるかと思います。同じレコードに複数ユーザが同じタイミングでアクセスするとややこしいことになります。これを回避するためには、db2にワークテーブルを備えておき、リンクテーブルからレコードを一度db2に格納し、編集を終了したのちにリンクテーブルのレコードを削除し、ワークテーブルで編集したレコードをリンクテーブルに追加する、などのルーティンをマクロやVBAで構築するのがよいかと思います。私はそのようにしていました。他に、ADOを使う方法などもあります。研究してみるといいですよ。(^-^)マイクロソフトのアクセスに同時に複数のユーザが同時にアクセスしてデータベースを操作することは可能です。昔私が簡便に行なっていた方法は「テーブルのリンク」です。あるコンピュータにアクセスでdb1という名前のデータベースを作ってここにデータを格納しておきます。他方で別のコンピュータに、アクセスでdb2という名前のデータベースを作ります。サブフォームでの選択行の取得こんにちは。Access初心者です。選択された行を取得する方法はありますか?サボフォームの下の方に現在選択されているレコード数が表示されてますが、その値でかまいません。調べているのですが、なかなか検討がつきません。Aベストアンサーフォーム名がフォーム1、サブフォームコントロールの名前がサブフォーム1だとすると、Forms!フォーム1!サブフォーム1.Form.CurrentRecordで取得できます。(「Forms」と「Form」がありますのでご注意下さい)また、フォーム1にコードを記述する場合であればMe!サブフォーム1.Form.CurrentRecordサブフォーム1へのコード記述であればMe.CurrentRecordという構文によっても、それぞれ取得が可能です。Access2003で開発したアプリケーションを用いて社内LAN上でデータベースを共有するため、セキュリティウィザードによって作成されるショートカットを社内ユーザに配布して運用しています。ところが、配布したショートカットのプロパティはユーザが覗くことができ、そこには実体ファイルの所在がフルパスで記述されている為、これをたどればユーザが実体ファイルに直接アクセスすることができてしまうことに、きづきました。セキュリティ設定しても、改ざん(意図はなくても誤操作を含め)や破壊のリスクがある為、なんとかしたいと考えています。回避する方法はないでしょうか?なお、アプリケーションファイルはテーブル以外のオブジェクトを含んだフロントエンドと、データベース本体(テーブル)のみを含むバックエンドに分割しており、上記のセキュリティウィザードはフロントエンドに適用して作成したものです。フロントおよびバックエンドのmdbファイル、およびセキュリティ設定のmdwファイルはいずれも、関係ユーザのみがアクセス可能な社内LAN上の特定フォルダに置いています。万一所在が知られても、セキュリティ設定されたフロントエンドファイルやセキュリティ設定ファイルは開けないので良いのですが、バックエンドファイル(データそのもの)が開かれて改ざんされてしまうことを危惧しています。ファイルが消されてしまう事故は気付くので良いのですが、データの改ざんは、気付かずに運用継続されてしまう為、安心して運用ができません。回避方法のご教示を、どなたかよろしくお願い致します。Access2003で開発したアプリケーションを用いて社内LAN上でデータベースを共有するため、セキュリティウィザードによって作成されるショートカットを社内ユーザに配布して運用しています。遅くなりました、No.1~3のDexMachinaです。(注)2.2で、空のデータベースにインポートするという方法すみません、職場で作成したデータベースでは、ワークグループ管理をまだ適用しておらず、管理用のツールだけ先行作成した状況で、その件は完全に忘れていました(汗)大変失礼しました。別の他者は開けてしまった。現状、開ける人と開けない人が出てきてしまいました。こちらで確認した限りでは、新規データベースへのインポートにより、セキュリティウィザードを適用した端末以外から開いた場合でも、データベースに対する『開く/実行』の設定が正しく反映される(=権限がない旨のメッセージが出て開けない)結果となりました。念のため、こちらで行った操作を以下に記述します。前の回答ではショートカットを使用した起動方法をご紹介しましたが、上記のテストは「既定のワークグループ情報ファイルを変更」する形で行いました。以前にセキュリティウィザードで作成したMDWファイルを開く※一般ユーザーにデータベースを開く権限を与えていないもの。6)「3)」のダイアログに戻ったら『OK』ボタンをクリック(ワークグループに参加したことを知らせるメッセージあり)※これで、既定のワークグループ情報ファイルが変更されます。作成した端末以外に3機で確認した限り、どの端末でも開く権限がない旨のメッセージが表示されることを確認(いずれもWinXP・Pro&Access2003)この手順を行えば、No.3の補足欄で引用されている英文の末尾で触れられている通り、Accessの既定のユーザーID「管理者(Admin)」に対する全ての権限の許可は解除されるはずなので、端末によって結果が異なることは、理屈的にはなくなる、と思われるのですが・・・(汗)こうなると、No.2の補足で説明のありました「セキュリティウィザードを適用したことがないにもかかわらず、バックエンドファイルへのウィザード適用でエラーとなった」ことが、ちょっと引っかかってきます。殆どあてずっぽうのようで申し訳ないのですが(汗)、インストールされているAccessのウィザードに何らかの不具合が発生している可能性を考慮して、Accessを一旦アンインストールしてみるのも手かもしれません。遅くなりました、No.1~3のDexMachinaです。(注)2.2で、空のデータベースにインポートするという方法すみません、職場で作成したデータベースでは、ワークグループ管理をまだ適用しておらず、管理用のツールだけ先行作成した状況で、その件は完全に忘れていました(汗)大変失礼しました。別の他者は開けてしまった。現状、開ける人と開けない人が出てきてしまいました。こちらで確認した限りでは、新規データベースへのインポートにより、セキュリティウィ...続きを読む他の回答も見るQAccessのRefresh・Requery・Repaintの違いRequeryはもう一度ソースレコード(テーブル)を読み込むようです。このとき、テーブルの先頭レコードに移動してしまいます。Refreshは最新のレコード(テーブル)を再表示するような気がします。レコードの移動は起こらない気がします。Repaintは、VBAでキャプションなどを変更したとき使っています。どんなときにどんなメソッドを使えばいいのでしょうか?詳しい方、よろしくお願いいたします。Aベストアンサーたびたびすみません。調べてたらこんなのがでてきました。http://www.nurs.or.jp/~ppoy/access/access/acF007.html参考URL:http://www.nurs.or.jp/~ppoy/access/access/acF007.html他の回答も見るQAccessのフォーム上にレコード数とレコード番号の表示Accessでクエリを元に表示するフォーム上で、テキストボックス等に関数を使って、レコード数とレコード番号を表示する方法がありましたら教えてください。フォームの書式設定で「移動ボタン」の表示をすれば目的の事は出来るのですが、表示の大きさが調整できない為、とても見難いのです。以上よろしくお願いします。Aベストアンサーレコード番号のコントロールソースを=[CurrentRecord]レコード数のコントロールソースを=Count("*")-[NewRecord]としてみてください。他の回答も見るQアクセエスのレコードの更新をVBAでするには?アクセスで、一覧表のフォームにボタンを取りつけています。レコードの内容を変更したら、ペンの形のマークが現れますね。これは変更中ということですが、そこでボタンを押しても変更は確定されないから、更新確定させたいのです。最初の行に入れてみたら、元の一覧表は最初のレコードに飛んでしまう。キーを押して更新確定させたような状態をVBAで実現する方法あるのでしょうか?よろしくお願いします。方が良かったですね文字通りレコードを保存します。Accessを共有した際にファイルが壊れるのを回避する方法ちょっとしたツールをAccessで開発したいのですが、Accessファイルを共有するとファイルが頻繁に壊れると伺いました。効果はありますでしょうか。これでは、あまり意味がないとか、他に注意したほうが良い点等ありましたら、アドバイスいただければと思います。ツールは、50名位が使用(同時アクセスは3名~4名程度)予定で、サーバ上にメインのmdbファイル(以下「サーバmdb」)を、各クライアントにもそれと連携するmdbファイル(以下「クライアントmdb」)を置くことを想定しています。データは全てサーバmdbで保持する。クライアントmdbには、入力用のフォームと、サーバmdbから取得したデータを一時的に保持するテンポラリのテーブルを持つ。クライアントmdbからサーバmdbにアクセスし、必要なデータをクライアントmdbにインポートする。(4)の読込み・更新作業中は、クライアントmdbからサーバmdbにはアクセスしない(外部ファイルで制御)以上です。要は、クライアントmdbが、直接サーバmdbを更新しないようにし、参照のみにするということです。したツールをAccessで開発したいのですが、Accessファイルを共有するとファイルが頻繁に壊れると伺いました。効果はありますでしょうか。これでは、あまり意味がないとか、他に注意したほうが良い点等ありましたら、アドバイスいただければと思います。ツールは、50名位が使用(同時アクセスは3名~4名程度)予定で、サーバ上にメインのmdbファイル(以下「サーバmdb」)を、各クライアントにもそれと連携するmdbファイル(以下「ク...続きを読むAベストアンサーNo.1です。「同時アクセス」という言葉は実にあやふやな言葉です。質問者さんやNo2さんのいう「同時アクセス」は同時に複数人がそのシステムを使用しているという程度の同時アクセスだと思います。ところが世の中は広くて通常同時アクセスは、同時にデータベースの更新をする人の数を言います。通常データベースの更新は0.1秒とかで終わりますのでその0.1秒を同時に複数人がいくような状況を言います。No2さんのシステムでは、「クエリ(実際にはDoCmd.RunSQL)で更新」が同時におこる状況を言います。これが、たまたまであれ同時におこるとやばいわけです。入力用の作業テーブルをクライアント側のプログラム用のMDB内に持たせました。」まぁそれでもいいですけど、.NETアーキテクチャはこんな感じですよね。私はこれはとっても嫌いです。本気で複数人がデータを入力したければ、1行ずつを瞬間瞬間でINSERTしていくべきだと私は考えてます。テーブルあるいはデータベースをロックする時間はセッションを越えてはありえないと思っています。理由は、入力用の作業テーブルを作るとその内容を他人によってすでに変更されてるかもしれないからです。いう事態についてマイクロソフトは、エラーとして対処せよと言ってますが、そんなことできるわけないですよね。