現地情報は詳細にはわかりません。（外国です）
ただし、"（フルパス）is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides."というエラーなので、本当に迷子なんだと思います。
Microsoft Access で Access データベースを手動で分割する方法
上記記事を参考に、適当なAccessファイルを用意して、バックエンドデータベース「データベース1」、フロントエンドデータベース「データベース2」に分割しました。続けて、もう1つ余分にバックエンドデータベース「データベース3」を用意し、切り替える事ができるか試してみました。(場所は、デスクトップ。パスワードは、設定なし。)
Private Sub コマンド0_Click()
Dim dbs As DAO.Database
Dim tdf As DAO.TableDef
Set dbs = CurrentDb
For Each tdf In dbs.TableDefs
If tdf.Connect <> “” Then
tdf.Connect = “MS Access; PWD=; DATABASE=C:¥Users¥…¥Desktop¥データベース3.accdb”
tdf.RefreshLink
End if
Next tdf
dbs.Close
Set dbs = Nothing
Private Sub Form_Open(Cancel As Integer)
Dim dbs As DAO.Database
Dim tdf As DAO.TableDef
Set dbs = CurrentDb
For Each tdf In dbs.TableDefs
If tdf.Connect Like "*データーベース1.accdb*" Then
If tdf.Connect Like "*PWD=1234*" Then
Exit For
Else
tdf.Connect = _
"MS Access;PWD=1234;DATABASE=C:\test\データベース1.accdb"
tdf.RefreshLink
End If
End If
Next tdf
dbs.Close: Set dbs = Nothing
End Sub
リストを変更するという目的にはつかえませんね。hirotonさんも回答している通り、リストから値を選択したときに発生しますので。
コンボボックスのイベントなら、「フォーカス取得時」のイベントがいいでしょう。
テキストボックスAの更新後処理でもいいですが、例えば、レコード移動してテキストボックスの値が変わった場合には対応できません。
うーん、me.コンボボックスB.requeryでどうですか？
コンボボックスの場合、リストから値を選ぶためのクリックをしたときに発生するようです。（値がないとクリックしてもイベントは発生しません）
ありがとうございました。その方法がよさそうです。
ところで、コンボボックスのクリックイベントは、使えないイベントなのでしょうか？
テキストボックスAの更新後処理に再クエリを設定すると良いかもしれません。
今後継続して使用していく目的としてはとても便利で、思っていた以上のレポートです。
現にhirotonの回答は次々と問題が出てきて穴だらけですし
→ 私が条件を全て表示していなかったからです。感謝しかないです。
ご回答ありがとうございました。
アクセス以上にネットワーク関連の知識が足りず、事業所に迷惑をかけている状態なのですが、アクセス側はどうしようもないようですね。
ありがとうございました。
エラーが出なくなったようなので続きですが、
今後の方針について
単独で1ページを超えるような出力に対応する
データに依存する仕組みじゃ使いにくいですね。対策します
同一ページ印刷プロパティ「いいえ」に対応する
一応、対策案はあります。今の想定ではそれなりにコードが複雑になるので同一ページ印刷が「はい」なら対策コードは入れなくていいかなと思っています
詳細セクションの印刷時拡張の設定
今回の手法（『目次（索引）ページを自動作成』）では
詳細_formatからページ数を取得するのことがかなり難しいことがわかりました。で、本当に今更な確認ですが、詳細セクションで印刷時拡張の設定が無ければ出力ページ数自体が元データから作れるのでは？と、ふと思ってしまいました。（謎の先入観で印刷時拡張「はい」があるものと思っていたようです）今の手法も形になりそうなのでhirotonが別手法を挙げることはないですが、一応ここで確認事項としてあげておきます
実践あるのみですね。目的を立てて「できた！」までこぎつけてほんのちょっとレベルアップしたかもって思う感じです。
読み物としていろいろ見ておくと「自分のやろうとしてることくらいすでに誰かやっているんじゃないか？」とか「これめんどくさいな。もっと簡単な方法があるんじゃないか？」とかそういう考え方はできるようになるかもしれませんが、これが実力が付いたと言えるかというと微妙なところです。現にhirotonの回答は次々と問題が出てきて穴だらけですし
限定条件はあるもののその条件下なら今の回答でうまくいくと思っているんですが、うまくいかない部分があるということですか？それともこの条件だと目的のレポートにならないということですか？
hirotonさん、有難うございます。上記の様に設定したところ、漢字、カナ、数字の区別なく五十音順に並び替えることが出来ました。ただ、ページ跨ぎになっている薬剤のページはやはりずれていますが、私としては大満足です。大変な知識不足でお手数をお掛けして申し訳ありませんでした。こういったコードを沢山見ることが向上に繋がるでしょうか？
お世話になっております。やろうとしていることがAccess向きではないかもしれませんが・・。すみません。
添付画像（簡素化）のような テーブル構成・ 実施しようとしていることになります。
参考ＵＲＬをご教示いただき助かりました。時間を見つけて確認したいと思います。
なるほど、そういう方法もありますね。ありがとうございます。検討してみます。
エラー情報を翻訳すると
ということなので、パスが間違っているか、共有フォルダーの権限の問題で接続できてないか、、、が原因なんでしょう。
Accessの問題ではなさそうです。
Oh…, 本格的に迷子なんですね。
Aceessの問題なのか、リンクステーションの問題なのか、私には力及ばずでした。
とりあえずAccessのVBAなら、検索すればFileSystemObjectを使用したサンプルコードがいろいろ見つかりますが、たいてい今でも動作すると思います。
例えば、下記とか。
Excel VBA を学ぶなら moug モーグ | 即効テクニック | データベース自動バックアップ関数 (FSO)
Accessのバックアップを取る - オフィスタナベ
現状のテーブル構成はどうなってますか。
各テーブルのテーブル名、フィールド名、主キー設定を提示してください。
ご回答、およびご検証いただきありがとうございました。コードの内容はおいおい勉強します。
はい。データの分割で、一つのファイルからバックエンドを分割をしたもので、データ(複数テーブル)が一つのバックエンドファイルにすべて入っています。
> 伝言ゲームの罠に嵌まっていませんか？みんなで使っているうちに、あるテーブルのデータがおかしくなって、別のエラーが発生している話だったりしませんか？
現地情報は詳細にはわかりません。（外国です）
ただし、"（フルパス）is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides."というエラーなので、本当に迷子なんだと思います。
要件次第でしょう。ACCESSだけで実現しようとすると、ACCESSはバックアップ用のアプリケーションではないので、どのような動作をすればいいのかをすべて自分で考えて組み立てる必要があります
バックアップを目的としたアプリケーションを別途用意するのではダメなんでしょうか？
レポート上にテキストボックスを配置し、名前を「薬品名のフリガナ」、コントロールソースも「薬品名のフリガナ」とします。
印刷するデータではないので可視プロパティは「いいえ」にします。
五十音で並び替えたいということなので五十音のデータが必要です。薬品名から自動で五十音を作るのは現実的ではないので並び替え用に五十音のデータを用意します。>> 10の画像から使えそうなフィールド「薬品名のフリガナ」を用いていますが、見る限り五十音だけでないようなので必要であれば専用のフィールドを追加で用意してください
印刷しないデータなのでレコードセットから直接取れればいいんですが、レポートだとレコードセットを直接参照することができないのでレポート上にデータを読み込んであげる必要があります。そのため、テキストボックスを配置しコントロールを参照します
コントロールの名前プロパティとコントロールソースプロパティ（フィールド名）が同じ場合は意識する必要はないですが、別々にしている場合は注意してください
確認ですが、バックエンドにAccessファイルが３つ置いてあって、あるテーブルはデータベース1から、あるテーブルはデータベース2から、という状況では無いですよね？
上記コードを試して、再リンクで解決できるのかなぁと思いました。
時々、バックエンドが迷子になるという事でしたが、伝言ゲームの罠に嵌まっていませんか？みんなで使っているうちに、あるテーブルのデータがおかしくなって、別のエラーが発生している話だったりしませんか？
Microsoft Access で Access データベースを手動で分割する方法
上記記事を参考に、適当なAccessファイルを用意して、バックエンドデータベース「データベース1」、フロントエンドデータベース「データベース2」に分割しました。続けて、もう1つ余分にバックエンドデータベース「データベース3」を用意し、切り替える事ができるか試してみました。(場所は、デスクトップ。パスワードは、設定なし。)
このFor〜Nextでデータベース1とデータベース3の切り替えはできました。
最後のコードは、データベースを閉じてメモリを解放すると、なっているようです。
先週金曜日から何とかご指摘を克服しようと努力はしましたが、今の知識では難しくお知恵を頂こうと思っていました。
13の完コピに、1のSub ArrayListSort以下を合体させたところ”薬品名のフリガナフィールドが見つかりません”とのメッセージに変わりました（前進ですか？）。レポートに「薬品名のフリガナ」がないのは気になっていたのですが、この点は如何でしょうか？
Sub ArrayListSort(ary As Variant)
Dim aryList As Object
Dim s
'// .NET FrameworkのArrayListクラスを利用する
Set aryList = CreateObject("System.Collections.ArrayList")
For Each s In ary
Call aryList.Add(s)
Next
Call aryList.Sort
ary = aryList.ToArray
End Sub
適材適所で選択できるようになるといいでしょう。
フォームやレポートでグループ単位の集計を表示する場合は、複数の集計が必要になるのでDSumは重くなるので避けた方かいいでしょうか。
ただし、フォームでデータ編集もしたいときだと、集計クエリだと更新できないので、DSumで集計を表示する場合もあります。
フォームやレポート上にあるデータの全体の合計を１つのみ表示する場合はテキストボックスのコントロールソースにDSum関数を使って表示させてもいいでしょうか。
りんごさんへ
計算式の持ち時間が問題になりそうです。
出荷数の部分の式でIIfを使う発想はなかったので参考になります。
時間の計算の参考になりそうなサイトまで紹介していただきありがとうございます。
いろいろとありがとうございました。
引き続きアドバイス出来る方お願いします。
一か月ぐらいは定期的に覗きに来たいと思います。
詳しい解説ありがとうございます
やはりDsumを使わなくてすむなら使わないほうがいいんですね。マスタとかレコードが少ないテーブルで
なんらかの集計をするときにパッと使える関数といった使い方のほうがいいのかもしれませんね
テーブル→クエリ→フォーム→レポート
といった処理にする場合、
テーブルのレコードに対する集計条件（年度や取引先、商品などをテキストボックスに入力して指定する）を都度変えるのなら
テーブル→フォーム→クエリ→フォーム→レポート
ということになりますか？
ご回答ありがとうございます。基本的なやり方は間違えていないようです。
差し支えなければ、Hatena様の最後のコードについて説明いただけないでしょうか。
複数のテーブルをこのif~nextでリンクできるのでしょうか
下記サイトの回答コメントにあるのが、一般的な方法ではないでしょうか。
さらに、もっとも一般的な方法があれば、誰か補足をお願いします。
回答ありがとうございます。
実は事業所が離れており、私がネットワークはいることができていない中でエラーが出てしまったのです。
現地はランタイムで動いていて、前述のプログラムでリンクをくっつけなおしていたのですが、うまくいかないようで。
私がいなくても、永続的に事業所内のデータとリンクできるようにしなくてはならないのですが。
この質問は立て直します。ありがとうございました。
追記です。
メインフォームを新しく作り直したところ、消える現象はなくなりました！
プロパティの設定を新旧フォームで見比べてみたのですが、特に差異もなく…
原因を突き止めることができましたら、またご報告させていただきたいと思います。
>hatena様
ご回答とご指摘いただきありがとうございます！とても参考になりました！
Forループ内でカウンター変数を使用しない方が良いというのは知りませんでした…
例文をいくつか調べてみましたが、確かにカウンター変数を途中で変更されている方はおりませんでした。
ご法度というのは、For文にカウンター変数を変更する分岐を入れてしまうと、
煩雑になり可読性が落ちるからでしょうか？
また、コントロール名ではなく、フィールド名を指定するということですが、
こちらの理由をお伺いしてもよろしいでしょうか…？
個人的には、コードを見返した際に分かりやすく管理しやすいかな…
と思ってコントロール名を分かりやすい名前に変更し、指定していたのですが、
テーブルにデータを追加する場合などは、テーブルのフィールド名を指定しておかないと
後で問題になったりするのでしょうか？(見かける例文はコントロール名での指定が多い気がしたので…)
教えていただいたコードに変更しましたが、同じ症状が出てしまいます…
サブフォームをもう一度作り直してみましたが、結果は同じでした。
同じような症例がないか、もっと調べてみたいと思います。
(せっかくたくさんアドバイスいただいたのに解決できず申し訳ありません…)
適当にエラーが出るプロパティを設定してみたら同じエラーメッセージ出ませんでした。多分原因は
こっちのほうですね。
で必要な関数を消してしまったんでしょう。開く時（Report_Open）では
ArrayListSort()使ってないのでエラーメッセージが残念な感じですがよくあることなので・・・フロントエンドを開いて、リンク情報がどうおかしくなっているかを確認するのは？
ありがとうございました！
＞確認メッセージが出る出ないは、DoCmd.SetWarningsのコードがどこかにありませんか？
こちらを参考に、改めて確認したところ
自分の環境では確認メッセージを出さないように設定しており、
他の環境では設定してもらうか、マクロ、ＶＢＡでの制御が必要と知りました。
ＶＢＡで制御したところ、メッセージが出なくなりました。
大変助かりました。ありがとうございました。
同じ悩みの方のため、参考サイトのリンクを貼っておきます。
AccessVBAでクエリ実行時の確認メッセージを完全に非表示にする方法
ごめんなさい、Dsum動作比較のサイトを紹介しましたが、中身をよくわかっていませんでした。ちょうど使ってみて、使い勝手がいいじゃんと思ったんですけど、重くなりそうになったら要変更ですね。
下記、Hatenaさんの解説を読んで下さい、納得です。
りんごさんも回答されているようにテーブル→クエリ→フォーム→レポートがベストだと思います。
DSumは重くなります。
りんごさんが提示したリンク先
■T'sWare Access Labo #28 ～明細データテーブルの集計を考える～
には、
というような解説がありますが、これはテスト方法が間違っている。あるいはテスト結果の解釈が間違っていると思います。
テスト法は、DAOでレコードセットを開く、最終レコードへ移動する、ということだけをしています。
実際に使用する場合、集計結果を利用するはずです。集計結果を取得せずに最終レコード移動だけするという無意味な処理で速度を比較しても無意味だと思います。
具体的には下記のような処理にかかる時間を計測しています。
これでは上記で説明したように無意味なテストです。
下記のように各レコードにアクセスして集計結果を取得する処理を計測すべきでしょう。
これだとDSumが一番遅くなるはずです。レポートに出力する場合も、集計結果を出力することになるのでDSumが一番遅くなるはずです。
また、上記リンク先には下記のような解説もあります。
実際にクエリを開くと時間がかかるといっています。
レコードセットとして扱うと速いといってますが、OpenRecordset と MoveLast だけでは速いのは間違いではないですが、実際問題、OpenRecordset と MoveLast だけの処理というのはありえません。
T'sWareさんのサイトは有用な情報が多いのですが、たまにこのように外してい情報があるので注意が必要だと思います。
私の経験上、下記のような動作だと推測しています。
集計クエリでは、OpenRecordsetした時点で集計をしている。
サブクエリを利用した集計では、OpenRecordsetした時点では集計はしていない。レコード移動するときに集計する。
DSumでは、OpenRecordsetした時点では集計しない、レコード移動しただけも集計しない、集計結果にアクセスするときにはじめて集計する。
DSumでの「他のクエリーに比べて非常に画面表示に時間がかかる(１行ずつダラダラと表示されていく) 」という動作からもそう推測できます。表示するとき(集計結果にアクセスするとき)にはじめて集計されるということだと思います。
テーブル→クエリ→フォーム→レポートでいいと思う。
Dsum動作比較は、下記、サイトがありました。
ググっていたら、時間の計算に使えるかもしれないサイトがありました。
私の方からは、これくらいですね。頑張って👍
他の人は、旧バージョンを開いているとか？
とりあえず「●●●件のレコードが更新されます」を試しに実行して、テーブルの中身を確認しましょう。全件削除実行からの一連の流れなので、何か問題が起きれば、手動全件削除で元に戻せますよね。
前回のデータが残っているなら、全件削除のコードを比較。ループデータが残っているなら、For 〜Nextの中で、datasやrs(j)をdebug.printを比較。
確認メッセージが出る出ないは、DoCmd.SetWarningsのコードがどこかにありませんか？
確認した結果を教えてくれると、嬉しいな。
りんごさんへ
式の詳細ありがとうございす。
明日試してみます。
現在使ってるのが下の画像のようなものを使っております。
テーブル(外部データリンク)→クエリ→フォーム(サブフォームも)という流れでリアルタイムで更新できる仕組みを作ってます。
作業終了時間というフィールドを新たに追加したく今回質問させていただきました。
ただ作業生産性という少し専門的な分野の計算式が必要になってきますのでアクセスの質問掲示板を利用してもいいのか？という疑問は今もあります。
生産性と時間帯の人数(シフト)は基本的に固定で決まってますので、その部分は入力する予定です。
極端な話ですが一か月分入力することも可能です。
シフトのイレギュラーさえなければ一か月に一回のメンテでできればと考えております。
私のイメージとしてはクエリの部分で計算式を入れて作業終了時間を出せればと考えております。
そんな式が存在するのか？処理はできるのか？疑問は多々あります。
私の知識、技術不足のせいでうまく伝わっていないのかもしれませんので再度理想の形を説明させていただきました。
Excelで作るのが正解ではないでしょうか？
具体的にはわかりませんがExcelも必要であれば使うのは問題ありません。
更新すれば自動で作業終了時間がでる仕組みであれば他のこだわりは一切ありません。
いろいろと考えていただきありがとうございます。