Access (VBA)

Access VBAに関するフォーラムです。
  • 掲示板への投稿には会員登録(無料)が必要です。会員登録がまだの方はこちら
  • 掲示板ご利用上のお願い」に反するご記入はご遠慮ください。
  • Q&A掲示板の使い方はこちらをご覧ください
トピックに返信
質問

 
(Windows 10 Pro : Access 2016)
リストボックスの更新を通知したい件
投稿日時: 21/07/28 17:41:36
投稿者: アロハ

いつもお世話になります。
 
複数人でリストボックスAを配置したフォームAを操作しています。
リストボックスAはテーブルA(SQL Server内のテーブル)を参照しています。
 
AさんとBさんはフォームAを連携して使用しています。
例)Aさん入力後、続きをBさんが入力する。
 
この場合、Bさんの状況は下記の通りになります。
⓵フォームA又はAccess自体を閉じてしまっている。
AフォームAを開きっぱなしにしている。
 
⓵の場合、フォームAを開きなおすことで最新の情報をリストボックスAに取得できます。
Aの場合、最新の情報を取得するには何らかのアクションが必要になります。
 
Aの場合の対策として、フォーム内に「更新」ボタンを設置したとします。(リストボックスAをリクエリ)
しかしこの方法だと、そもそも「更新」ボタンを押し忘れる可能性がでてきます。(押したつもり)
又は、フォームAを立ち上げなおす方法もありますが、Bさんには非常に負担になります。
 
方法として考えてみたのが、Aさんの入力後Windowsの通知トーストをBさんに通知して、通知トースト内の確認するアクションにてリストボックスAをリクエリする。
 
まとめると、Windowsの通知トーストをAccess VBAで作成したいです。
通知トーストをAccessで飛ばす仕組みはさすがに作ったことがないので
通知トースト VBA 等で検索してみましたが、なかなかヒントになるような
ものがでてきません。
 
何卒ご指導ご鞭撻のほどよろしくお願い申し上げます。

回答
投稿日時: 21/07/28 21:52:41
投稿者: eden

Aさんが未処理でもBさんが処理を開始することがあるのですか。
なければ、更新を忘れても未処理なら待つだけです。
Aさんが未処理でもBさんは処理を開始するのなら、
Bさんが開始してから登録までの間にAさんが登録する可能性もありますよね。
当然その対処もしますよね。
登録の瞬間に通知がくるとガックリきます。

投稿日時: 21/07/29 08:28:06
投稿者: アロハ

eden さんの引用:

Aさんが未処理でもBさんは処理を開始するのなら、
Bさんが開始してから登録までの間にAさんが登録する可能性もありますよね。
当然その対処もしますよね。
登録の瞬間に通知がくるとガックリきます。

 
ご意見ありがとうございます。
コンビニのレジでも客の処理中に次の客が並ぶことは普通にあります。
申し訳ありませんが、一般的にそれが仕事ですよね?

回答
投稿日時: 21/07/29 17:33:41
投稿者: sk

引用:
リストボックスAはテーブルA(SQL Server内のテーブル)を参照しています。

引用:
AフォームAを開きっぱなしにしている。

引用:
Aの場合、最新の情報を取得するには何らかのアクションが必要になります。

[フォームA]の Timer イベントの発生時に(一定時間置きに)
[リストボックスA]の Requery メソッドを実行なされば
よろしいのではないでしょうか。

投稿日時: 21/07/29 21:44:39
投稿者: アロハ

sk さんの引用:
引用:
リストボックスAはテーブルA(SQL Server内のテーブル)を参照しています。

引用:
AフォームAを開きっぱなしにしている。

引用:
Aの場合、最新の情報を取得するには何らかのアクションが必要になります。

[フォームA]の Timer イベントの発生時に(一定時間置きに)
[リストボックスA]の Requery メソッドを実行なされば
よろしいのではないでしょうか。

 
sk様
 
いつもコメントありがとうございます。
ご提案いただいたTimerイベントも考案して提案していました。
しかしユーザーからは、その画面をずっと見てるわけではなく別の業務でエクセルやら何やらで画面を使用しているから、もし画面が更新されていても気づかないと却下になりました。
(ユーザーの9割がシングルモニター環境)
Windowsの通知トーストのキーワードをここで取り上げたのは、ユーザーからそれならいいよと納得いただいた経緯があります。それで早く進めたいのでいろいろ調べた結果、ヒントとなるサンプルコードが見つからなかった為、質問した次第です。
 
何卒ご指導の程、よろしくお願いします。

回答
投稿日時: 21/07/30 09:29:41
投稿者: ハヤシライス

こんにちは
 
ご参考まで:
https://ascii.jp/elem/000/004/059/4059715/

回答
投稿日時: 21/07/30 09:53:43
投稿者: eden

How to show Windows 10 notification toast from VBA
https://stackoverflow.com/questions/67492763/how-to-show-windows-10-notification-toast-from-vba
 
少し修正して、Access2016で通知できるのを確認しました。

回答
投稿日時: 21/07/30 09:55:05
投稿者: eden

あ、修正しないと動かないのではなくて、アイコンを変えたりとかそういうことです。

回答
投稿日時: 21/07/30 10:22:31
投稿者: Suzu

引用:
ご提案いただいたTimerイベントも考案して提案していました。
しかしユーザーからは、その画面をずっと見てるわけではなく別の業務でエクセルやら何やらで画面を使用しているから、もし画面が更新されていても気づかないと却下になりました。
(ユーザーの9割がシングルモニター環境)
Windowsの通知トーストのキーワードをここで取り上げたのは、ユーザーからそれならいいよと納得いただいた経緯があります。

 
そもそも、リストボックスのレコードソースとして使用しているソースに対し
更新可能な仕様としているのでしょうか?
レコードロック無し?
 
 
 
Aさんの更新が、1件だけなら良いかもしれませんが、
データベースですから、当然の様に、複数件の更新が行われます。
 
それが全て通知される事になりませんが?
そんな大量の通知は、スルーしがちになりませんか?
 
もう一度、仕様を考え直した方が良いと思います。

回答
投稿日時: 21/07/30 10:35:37
投稿者: Suzu

アロハ さんの引用:
eden さんの引用:

Aさんが未処理でもBさんは処理を開始するのなら、
Bさんが開始してから登録までの間にAさんが登録する可能性もありますよね。
当然その対処もしますよね。
登録の瞬間に通知がくるとガックリきます。

 
ご意見ありがとうございます。
コンビニのレジでも客の処理中に次の客が並ぶことは普通にあります。
申し訳ありませんが、一般的にそれが仕事ですよね?

 
コンビニ のレジ だとして、
『誰かのレジ処理中に、他の客の レジ処理を 同じレジにて行う』 と言うなら、比喩となると思いますが
 
並んでいるのは、「客」であり、 「店員」及び レジ側は一人に対し処理を行います。
 
比較対象となりえていないと思います。
 
 
更新頻度 にもよると思いますが、
  起動しっぱなしで、更新されているのを自動で更新したら 気づかないからNG ?
 
  フォームを開きなおすのは、ユーザーの負担?
  自動で更新したら、気づかない のですから、フォームを開きなおさせても気づかないのでは?
 
 
要因と対策について、着目点が違う様に 見えてしまいます。
整理しなおした方が良いと思います。

投稿日時: 21/07/30 10:49:06
投稿者: アロハ

Suzu さんの引用:
引用:
ご提案いただいたTimerイベントも考案して提案していました。
しかしユーザーからは、その画面をずっと見てるわけではなく別の業務でエクセルやら何やらで画面を使用しているから、もし画面が更新されていても気づかないと却下になりました。
(ユーザーの9割がシングルモニター環境)
Windowsの通知トーストのキーワードをここで取り上げたのは、ユーザーからそれならいいよと納得いただいた経緯があります。

 
そもそも、リストボックスのレコードソースとして使用しているソースに対し
更新可能な仕様としているのでしょうか?
レコードロック無し?
 
 
 
Aさんの更新が、1件だけなら良いかもしれませんが、
データベースですから、当然の様に、複数件の更新が行われます。
 
それが全て通知される事になりませんが?
そんな大量の通知は、スルーしがちになりませんか?
 
もう一度、仕様を考え直した方が良いと思います。

 
Suzu様
 
コメントありがとうございます。
1件の更新で相手に通知するか複数件まとめて通知するは
相手にとってどちらか都合がいいかはユーザーが考える
ことであって、1件1件通知したら大量の通知になること
ぐらいユーザーはわかります。使い方次第ということです。
それが仕様です。

投稿日時: 21/07/30 11:09:20
投稿者: アロハ

Suzu さんの引用:
アロハ さんの引用:
eden さんの引用:

Aさんが未処理でもBさんは処理を開始するのなら、
Bさんが開始してから登録までの間にAさんが登録する可能性もありますよね。
当然その対処もしますよね。
登録の瞬間に通知がくるとガックリきます。

 
ご意見ありがとうございます。
コンビニのレジでも客の処理中に次の客が並ぶことは普通にあります。
申し訳ありませんが、一般的にそれが仕事ですよね?

 
コンビニ のレジ だとして、
『誰かのレジ処理中に、他の客の レジ処理を 同じレジにて行う』 と言うなら、比喩となると思いますが
 
並んでいるのは、「客」であり、 「店員」及び レジ側は一人に対し処理を行います。
 
比較対象となりえていないと思います。
 
 
更新頻度 にもよると思いますが、
  起動しっぱなしで、更新されているのを自動で更新したら 気づかないからNG ?
 
  フォームを開きなおすのは、ユーザーの負担?
  自動で更新したら、気づかない のですから、フォームを開きなおさせても気づかないのでは?
 
 
要因と対策について、着目点が違う様に 見えてしまいます。
整理しなおした方が良いと思います。

 
ご意見ありがとうございます。
 
Aさんが客、Bさんレジです。
レジの処理中に新しく客が並んだ。
Bさんの処理中に新しくAさんがデータを通知した。
何が違うのでしょうか。

投稿日時: 21/07/30 11:14:28
投稿者: アロハ

Suzu さんの引用:
アロハ さんの引用:
eden さんの引用:

Aさんが未処理でもBさんは処理を開始するのなら、
Bさんが開始してから登録までの間にAさんが登録する可能性もありますよね。
当然その対処もしますよね。
登録の瞬間に通知がくるとガックリきます。

 
ご意見ありがとうございます。
コンビニのレジでも客の処理中に次の客が並ぶことは普通にあります。
申し訳ありませんが、一般的にそれが仕事ですよね?

 
コンビニ のレジ だとして、
『誰かのレジ処理中に、他の客の レジ処理を 同じレジにて行う』 と言うなら、比喩となると思いますが
 
並んでいるのは、「客」であり、 「店員」及び レジ側は一人に対し処理を行います。
 
比較対象となりえていないと思います。
 
 
更新頻度 にもよると思いますが、
  起動しっぱなしで、更新されているのを自動で更新したら 気づかないからNG ?
 
  フォームを開きなおすのは、ユーザーの負担?
  自動で更新したら、気づかない のですから、フォームを開きなおさせても気づかないのでは?
 
 
要因と対策について、着目点が違う様に 見えてしまいます。
整理しなおした方が良いと思います。

 
ご意見ありがとうございます。
 
今回の着眼点はどう気づかせるかです。
 
>>フォームを開きなおさせても気づかないのでは?
 
なので、1つの通知をもってユーザーには受け取ったアクションを
確認させるタイミングで更新するのがベストと判断しております。

回答
投稿日時: 21/07/30 15:55:54
投稿者: sk

引用:
ご提案いただいたTimerイベントも考案して提案していました。
しかしユーザーからは、その画面をずっと見てるわけではなく
別の業務でエクセルやら何やらで画面を使用しているから、
もし画面が更新されていても気づかないと却下になりました。

まあどの道 Timer イベントでやるしかないのでは、
というのが今のところの印象。
 
引用:
Windowsの通知トーストのキーワードをここで取り上げたのは、
ユーザーからそれならいいよと納得いただいた経緯があります。

トースト通知を表示させる方法自体は、既に ハヤシライス さんや
eden さんが回答されているように、PowerShell を経由させれば
一応は可能です。
 
・他のユーザーが操作している端末上において、同じく
 [フォームA]が開かれているか否かをどうやって判別するのか。
 (そもそも判別する必要があるのか)
 
・自身、または他のユーザーが[テーブルA]に対してレコードの更新を
 行なったことを、いつ、誰が、どうやって検知し、それを
 いつ、誰(どのような条件に当てはまるユーザー)に対して、
 どうやって送信するのか。
 (そもそも送信する必要があるのか)
 
・上記のそれぞれの処理をどのイベントで実行するのか。
 
あとは上記の問題をどう解決するか(しないか)でしょう。

投稿日時: 21/07/30 23:06:39
投稿者: アロハ

sk さんの引用:
引用:
ご提案いただいたTimerイベントも考案して提案していました。
しかしユーザーからは、その画面をずっと見てるわけではなく
別の業務でエクセルやら何やらで画面を使用しているから、
もし画面が更新されていても気づかないと却下になりました。

まあどの道 Timer イベントでやるしかないのでは、
というのが今のところの印象。
 
引用:
Windowsの通知トーストのキーワードをここで取り上げたのは、
ユーザーからそれならいいよと納得いただいた経緯があります。

トースト通知を表示させる方法自体は、既に ハヤシライス さんや
eden さんが回答されているように、PowerShell を経由させれば
一応は可能です。
 
・他のユーザーが操作している端末上において、同じく
 [フォームA]が開かれているか否かをどうやって判別するのか。
 (そもそも判別する必要があるのか)
 
・自身、または他のユーザーが[テーブルA]に対してレコードの更新を
 行なったことを、いつ、誰が、どうやって検知し、それを
 いつ、誰(どのような条件に当てはまるユーザー)に対して、
 どうやって送信するのか。
 (そもそも送信する必要があるのか)
 
・上記のそれぞれの処理をどのイベントで実行するのか。
 
あとは上記の問題をどう解決するか(しないか)でしょう。

 
sk様
 
コメントありがとうございます。
 
説明不足でした。申し訳ありません。データ入力の流れを「例)」としてまでしか説明してありませんでした。
テーブルAを入力する流れとして、⓵BさんやCさん(複数人)→AAさん→BBさんやCさん(複数人)です。
テーブルAのカラムには入力者管理としてコンピュータ名があります。(BさんやCさん(複数人)が使用しているそれぞれのコンピュータ名)
別のテーブルでコンピュータ名を主キーにした、使用者を管理しています。(人の名前を紐づけるため)
⓵で入力したレコードには必ずコンピュータ名がついてきます。
なので、Aの操作でデータを受け取ったAさんはコンピュータ名に紐づいた人の塊ごとに処理することでBの操作で、ターゲットとなるレコードをBさんやCさん(複数人)に返せます。
AのAさんの画面は複数のデータが混在するので、コンピュータ名に紐づいた人の名前でソートがかかって表示するようにしています。
 
あと、⓵Bでは自分の入力したデータでフィルタをかけてますので他の人のデータをみることはありません。
余談ですが、全部見る切り替えラジオボタンは実装しています。
もちろん仕様として自分のコンピュータ名が入ったレコードしか更新はできません。
 
あと画面の仕様として、Aを入力後Aさんの画面からはデータは消えていきます。
⓵を入力したBさんやCさん(複数人)の画面にはデータが残っていて、Aが完了したらBを行うことで画面から消えていきます。
↑聞きたかったのはそれぞれ入力後のシーンなのでいろんな説明を省略してしまいました。
 
話は戻って通知トーストで、「OK]か何かのアクションで、該当のAccessが開いているか、フォームが開いているか、など確認して、開いていた場合はリクエリのイベントを仕込めれば完璧かなと。
 
説明不足で申し訳ありませんでした。
 
よろしくお願いします。

投稿日時: 21/07/30 23:49:39
投稿者: アロハ

すいません。少し訂正があります。
 

引用:
画面の仕様として、Aを入力後Aさんの画面からはデータは消えていきます。
⓵を入力したBさんやCさん(複数人)の画面にはデータが残っていて、Aが完了したらBを行うことで画面から消えていきます。

 
⓵を入力後BさんやCさん(複数人)は「通知ボタン」をクリックして、Aさんに通知します。
通知を受け取ったAさんはAを入力後通知したいレコードを選択して「通知ボタン」をクリック後画面からデータが消えていきます。
最後に通知を受け取ったBさんやCさん(複数人)は、残りを入力することで画面からデータが消えていきます。
 
よろしくお願いします。

回答
投稿日時: 21/08/02 10:57:19
投稿者: Suzu

当初の ご希望の方法は 得られたと思いますが、
その上で、
 

引用:
通知トーストで、「OK]か何かのアクションで、該当のAccessが開いているか、フォームが開いているか、など確認して、開いていた場合はリクエリのイベントを仕込めれば完璧かなと。

 
これを求められているのでしょうか?
 
当方には、できるかどうか は判りかねます。
 
 
アロハさんに、ご説明を頂いておりますが 考え方が違うのか理解できない部分も多い状態です。
 
 ・ 再クエリで良いと思っていますし、
   更新通知を行うにしても メッセージをレコードとして保存し、
   フォーム上で表示させる等で対応できると思っています。
 
   Access内で済むのであれば Access内で収める方が良いと思っています
 
   仕様変更で使えなくなる可能性やメンテナンスが複雑になりがちです。
   そのメンテナンスをも検討し、要望に応えないのもアリと思っています。
 
 
 ・ コンビニの レジの 例 ピンと来ていません。
   客;A 、レジ打ち:B、 レジ 自体が システム
   Bにとっても、レジにとっても、処理する情報は、Aに対しての 数値のみ。
   Aの後ろに並んでいる 別の客 の事は 考えなくて良い と思っています。
 
 
求めておられる通知トーストの戻りに、Accessの動作を仕込む事が可能かの回答が判らないですし
それを調べても自分でが使わないので、、調べる意欲がおこりません。
 
ですので、ここまでとさせて頂きます。がんばってください。

投稿日時: 21/08/03 00:44:18
投稿者: アロハ

Suzu様
 
コメントありがとうございます。
 

引用:
 ・ 再クエリで良いと思っていますし、
   更新通知を行うにしても メッセージをレコードとして保存し、
   フォーム上で表示させる等で対応できると思っています。
  
   Access内で済むのであれば Access内で収める方が良いと思っています
  
   仕様変更で使えなくなる可能性やメンテナンスが複雑になりがちです。
   そのメンテナンスをも検討し、要望に応えないのもアリと思っています。

 
今回は気づかせるのが課題です。Accessを閉じてしまって気づかないまま入力漏れが発生したことに対する重要な対策です。
ご指摘通り、Access内で済ませるべき話なのでAccessを起動しておくこと自体が対策ですが、閉じることができる以上真の対策にはなっていません。
私自身も通知トーストとかわかっていないので、助けを求めて質問しています。PowerShellを経由するなど、複雑になるのは仕方ないかと思っております。ちなみに要望に応えないのもアリとか、同等の代替え案を持った上でならわかりますが、このご時世なのでなかなか言えません。
 
引用:
 ・ コンビニの レジの 例 ピンと来ていません。
   客;A 、レジ打ち:B、 レジ 自体が システム
   Bにとっても、レジにとっても、処理する情報は、Aに対しての 数値のみ。
   Aの後ろに並んでいる 別の客 の事は 考えなくて良い と思っています。

 
すいません。これも説明不足でした。
「処理する情報は、Aに対しての 数値のみ」で考えた場合、ただ処理するだけなのでレジもなにもありません。
なぜレジと例えたかですが、レジ打ち:Bは、客:A毎に処理します。
なのでレジ打ち:Bの処理中は、客毎の処理なので客:Aの後ろにいる客は事実上「待ち」が発生する為です。
 
引用:
求めておられる通知トーストの戻りに、Accessの動作を仕込む事が可能かの回答が判らないですし
それを調べても自分でが使わないので、、調べる意欲がおこりません。
  
ですので、ここまでとさせて頂きます。がんばってください。

 
励ましのお言葉ありがとうございました。頑張ります!

投稿日時: 21/08/03 00:53:56
投稿者: アロハ

eden様
 
コメントありがとうございます。
 

引用:
あ、修正しないと動かないのではなくて、アイコンを変えたりとかそういうことです。

 
アイコンは変えていませんが、手を加えて動きは確認しました。
 
Public Function Notify(ByVal title As String, ByVal msg As String, _
                    Optional ByVal notification_icon As String = "Info", _
                    Optional ByVal app As String = "msaccess", _
                    Optional ByVal duration As Integer = 10)
                     
'Parameters:
' title (str):Notification title
' msg (str):Notification message
' notification_icon (str):Notification icon. Available options are: Info, Error and Warning
' app (str):Process name of app you want to be display in the system tray icon
' duration (int):Duration of notification in seconds
 
Const PSpath As String = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
 
Dim WsShell As Object: Set WsShell = CreateObject("WScript.Shell")
Dim strCommand As String
 
If notification_icon <> "Info" And notification_icon <> "Error" And notification_icon <> "Warning" Then
    notification_icon = "Info"
End If
 
strCommand = """" & PSpath & """ -Command " & Chr(34) & "& { "
strCommand = strCommand & "Add-Type -AssemblyName 'System.Windows.Forms'"
strCommand = strCommand & "; $notification = New-Object System.Windows.Forms.NotifyIcon"
strCommand = strCommand & "; $path = (Get-Process -id (get-process " & app & ").id).Path"
strCommand = strCommand & "; $notification.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon($path)"
strCommand = strCommand & "; $notification.BalloonTipIcon = [System.Windows.Forms.ToolTipIcon]::" & notification_icon & ""
strCommand = strCommand & "; $notification.BalloonTipText = '" & msg & "'"
strCommand = strCommand & "; $notification.BalloonTipTitle = '" & title & "'"
strCommand = strCommand & "; $notification.Visible = $true"
strCommand = strCommand & "; $notification.ShowBalloonTip(" & duration & ")"
strCommand = strCommand & " }" & Chr(34)
 
WsShell.Run strCommand, 0, False
 
End Function
 
Public Sub Notify_Examples()
 
Notify "Insert Title Here", "Insert Your Message Here"
'Notify "Insert Title Here", "Insert Your Message Here", "Warning"
'Notify "Insert Title Here", "Insert Your Message Here", "Error", "outlook"
 
End Sub
 
質問ですが、通知したい相手はどこで指定するかわかりますでしょうか。

回答
投稿日時: 21/08/04 09:31:03
投稿者: eden

月が変わりなかなか試せないです。
 
私もBで更新チェックして、通知等をするでいいと思いますが。
Aからプッシュしたいのであれば、PowerShell をリモート実行します。
通知先を指定するというより、PowerShellの実行先を指定する感じです。
そのコードのコマンド部分をリモート実行に変更して、
さらに初期状態ではリモート実行はできないので、両方のPCを設定して
AからBに対してPowerShellをリモート実行できるようにします。
 
AからはBでPowerShellが実行できるようになり、
セキュリティ的に落ちるように思うので、よく理解してから試してください。

投稿日時: 21/08/06 17:48:16
投稿者: アロハ

eden様
 
コメントありがとうございます。
 

引用:
私もBで更新チェックして、通知等をするでいいと思いますが。
Aからプッシュしたいのであれば、PowerShell をリモート実行します。
通知先を指定するというより、PowerShellの実行先を指定する感じです。
そのコードのコマンド部分をリモート実行に変更して、
さらに初期状態ではリモート実行はできないので、両方のPCを設定して
AからBに対してPowerShellをリモート実行できるようにします。

 
いろいろ調べておりますが、リモート実行とかでてきません。
試すもなにもそんなことは本当にできるのでしょうか。
思想や考え方の説明もありがたいのですが、具体的な内容(コード)で説明してもらえないでしょうか。
(サンプルコードの参照先など)
 
引用:
AからはBでPowerShellが実行できるようになり、
セキュリティ的に落ちるように思うので、よく理解してから試してください。

 
試すもなにも理解もしていないものを試しようがありません。
 
 
よろしくお願いします。

回答
投稿日時: 21/08/10 11:55:59
投稿者: sk

引用:
テーブルAを入力する流れとして、⓵BさんやCさん(複数人)
→AAさん→BBさんやCさん(複数人)です。

引用:
テーブルAのカラムには入力者管理としてコンピュータ名があります。
(BさんやCさん(複数人)が使用しているそれぞれのコンピュータ名)
別のテーブルでコンピュータ名を主キーにした、使用者を管理しています。

・「 A さん」と「 A さん以外のユーザー」はユーザーとしての種類
 (受け持っている仕事や権限、使用するフォームや実行可能な操作、
 入力するデータの性質や内容等)が大きく異なる。
 
・両者の入力操作は半対話的に実行され、「 A さん」は基本的に
 「 A さん以外のユーザー」からの何らかのリクエスト
 ([テーブルA]に挿入された新規レコードがそのログに当たる)に
 応答するオペレーターのような役目を担っている。
 
といったことなのであれば、まずそれぞれの業務内容なり
ビジネスロジックなりを具体的に明記されることをお奨めします。
 
引用:
いろいろ調べておりますが、リモート実行とかでてきません。
試すもなにもそんなことは本当にできるのでしょうか。

既に eden さんが回答されている通り、PowerShell で
リモートセッションを作成してリモートコマンドを実行する条件は、
実行するユーザーがそのコンピューターの管理者権限に持っている
(例えば Administrators グループのメンバーである)ことです。
 
・「 A さん以外のユーザー」が、「 A さん」の使用している
 コンピューター上で PowerShell のコマンドをリモート実行するには、
 そのコンピューターの管理者権限を全てのユーザーに与えなければならない。
 
・「 A さん」が、「 A さん以外のユーザー」が使用している
 それぞれのコンピューター上で PowerShell のコマンドを
 リモート実行するには、それら全てのコンピューターの
 管理者権限を「 A さん」に与えなければならない。
 
引用:
思想や考え方の説明もありがたいのですが、
具体的な内容(コード)で説明してもらえないでしょうか。
(サンプルコードの参照先など)

なので、まず上記の条件を満たせるかどうかを検討して下さい。
その問題が解決できない限り、リモートコマンドを実行しても
失敗するだけです。
 
もっとも、私自身は「そんなことは現実的ではない」と思いますし、
仮に解決できたとしても、eden さんが指摘されているように
セキュリティ上のリスクが格段に上がることは間違いありません。
 
引用:
話は戻って通知トーストで、「OK]か何かのアクションで、
該当のAccessが開いているかフォームが開いているか、など確認して、
開いていた場合はリクエリのイベントを仕込めれば完璧かなと。

同様に、ネットワーク上の他のコンピューター上で実行されている
プロセスを、匿名ユーザーが一方的に知り得る手段はありません。
(あるとすれば、それは違法な技術でしょう)
 
それぞれのコンピューター上で Access が実行されているか、
Access アプリケーション上でどのファイルが開かれているか、
どのフォームが開かれているかを知ることなど、何らかの
中継サーバーとローカルアプリ(今回なら Access のフォーム)間で
常時通信を行なうような仕組みを導入しない限りは無理でしょう。

投稿日時: 21/08/10 23:10:56
投稿者: アロハ

sk様
 
コメントありがとうございます。
これまでいただいたご意見を踏まえて、現実的ではないと判断し代替え案を考えてみました。
 
前のコメントでSuzu様よりいただいた内容で

引用:
Access内で済むのであれば Access内で収める方が良いと思っています

この内容が全てなので、何とかできないかと考えてみました。
 
入力者はもちろんのこと、受信者も一度は目的のAccessを起動していると前提で話を進めます。
最初の入力者はテンプテーブルでデータを作成し、「送信ボタン」をきっかけに本テーブルにデータを追加します。
データはまとめて送信することもあるので、ユーザ間では本テーブルに追加したデータは追跡キー毎で管理します。
※追跡キー:社員コード + 日付 + 時間
 
「送信ボタン」を押したタイミングで、バックグラウンドで別のAccessを起動しテーブルの内容を監視するのはできないでしょうか。※本Accessを終了してしまった場合の対策。
 
その後ユーザ間でデータの更新があった知らせを、バックグラウンドのAccessが通知トーストもどき的に動作する。
 
まずバックグラウンド別のAccessを起動することは可能でしょうか。
 
 
何卒ご指導ご鞭撻のほどよろしくお願い申し上げます。

回答
投稿日時: 21/08/11 17:32:36
投稿者: Suzu

引用:
入力者はもちろんのこと、受信者も一度は目的のAccessを起動していると前提で話を進めます。
最初の入力者はテンプテーブルでデータを作成し、「送信ボタン」をきっかけに本テーブルにデータを追加します。
データはまとめて送信することもあるので、ユーザ間では本テーブルに追加したデータは追跡キー毎で管理します。
※追跡キー:社員コード + 日付 + 時間
 
「送信ボタン」を押したタイミングで、バックグラウンドで別のAccessを起動しテーブルの内容を監視するのはできないでしょうか。※本Accessを終了してしまった場合の対策。
 
その後ユーザ間でデータの更新があった知らせを、バックグラウンドのAccessが通知トーストもどき的に動作する。
 
まずバックグラウンド別のAccessを起動することは可能でしょうか。

 
 
何の為に別のAccessなのですか?
 
特定 accdb の特定条件のレコード(※追跡キー:社員コード + 日付 + 時間)について
取得できれば良いのではないのですか?
 
閉じれば、質問文 の
引用:
この場合、Bさんの状況は下記の通りになります。
⓵フォームA又はAccess自体を閉じてしまっている。
AフォームAを開きっぱなしにしている。
  
⓵の場合、フォームAを開きなおすことで最新の情報をリストボックスAに取得できます。
Aの場合、最新の情報を取得するには何らかのアクションが必要になります。
  
Aの場合の対策として、フォーム内に「更新」ボタンを設置したとします。(リストボックスAをリクエリ)
しかしこの方法だと、そもそも「更新」ボタンを押し忘れる可能性がでてきます。(押したつもり)
又は、フォームAを立ち上げなおす方法もありますが、Bさんには非常に負担になります。

 
の前提条件の 1 についての 最新が取得できる ので、喜ばしいのではないのでしょうか。
対策が必要とおっしゃっていた、 2 についての対策として、トースト が出てきたのですよね。
 
それでも、別 Access なんて話が出るのは、
 「各 個人宛 に、あなたが処理すべき レコード があります」 の通知が「絶対必要」なのであって
前提条件の 1 であり、最新のデータが表示されていても、処理通知が必要なのでしょう?
 
 
とももとは、SQLサーバーなのですから、SQLサーバー側で、
 
1. 通知用の テーブルを作成
2. リストボックスのソースとなるテーブルのレコード更新時に、
     「次の処理が誰なのか宛先を指定する為のユーザーを特定する情報」、「レコード番号」
     を生成する トリガーを仕込む
を行います。
 
その上で、
 1)既存のAccess 側に、それらのメッセージを表示するフォームを作成
 2)Timer イベントにて、SQLサーバーの 通知用テーブル の 宛先が 自分の レコードがあれば
   ポップアップにて、メッセージ表示フォームを開く
 3)レコードの処理が終わったら、通知用のテーブルのレコードを削除するなり、
   処理を終えた旨のフラグを立て、メッセージフォームが開かない様にする
 
上記を行えば 済むと思っています。
 フォームを用意しないでも、
     テキストボックスのコントロールソースに、DLookUp関数等で、通知用テーブルを参照し
   対象があるかを確認する 式を埋め込み、 Timer関数で、 コントロールに対し再計算をさせる
 
 
ですから、
引用:
フォーム上で表示させる等で対応できると思っています。

と言っています。
 
 
Accessなのですから、
「更新しました」の情報を 配信 するの考えではなく
  必要なタイミングで テーブルのデータ の中から 必要なデータを 探して表示する
で良いと思います。
 
別 の Access を起動させるのは、終了していても、通知を受けたいからですよね。
それは、その Accessが起動した時に、処理すべきレコードの情報が表示される ではダメなのですか?
 
 
それではダメなのだとしても、Accessである必要が判りません。
VBS を作成し、タスクスケジュラー で一定時間毎に SQLサーバーの データを参照すれば良いです。
 そっちの方が、Access 終了されたら終わり を考えないで済みます。
 
 
実現したい内容を きちんと整理し、どのような 手法を 用いたら 良いのか
から検討し直した方が良いでしょう。
 
変に、手法にこだわって質問する よりも良いと思います。
 
 
でもそうなると・・
・運用されているSQLサーバーが既にある
・複数人による、同一レコードの編集があり得る
・処理すべき 情報を ユーザーに提示したい
 
  Access でない方が 柔軟かも知れませんが。。

投稿日時: 21/08/13 23:35:32
投稿者: アロハ

Suzu様
 
コメントありがとうございます。
 

引用:
別 の Access を起動させるのは、終了していても、通知を受けたいからですよね。
それは、その Accessが起動した時に、処理すべきレコードの情報が表示される ではダメなのですか?

 
申し訳ありませんが、今までのやり取りでそれは説明済みです。それではダメなので質問しています。
急ぎで入力した→Accessを終了してしまった→次Accessを起動したのが7日後だった(極端な例)
 
引用:
それではダメなのだとしても、Accessである必要が判りません。

 
Access同士のやり取りにすればやりやすいと思って質問してみた次第です。判りませんと言われても深い意味はありません。(PowerPointやWordにするよりまし)
 
引用:
VBS を作成し、タスクスケジュラー で一定時間毎に SQLサーバーの データを参照すれば良いです。
 そっちの方が、Access 終了されたら終わり を考えないで済みます。

 
ご提案ありがとうございます。具体的にどの様なVBSなのでしょうか。
そのVBSが自分の端末で動作するものであれば、話は戻って自分自身に通知トーストを出すこともできるように思えるのですが、間違っていますか?
 
何卒ご指導ご鞭撻のほどよろしくお願い申し上げます。

回答
投稿日時: 21/08/18 10:35:37
投稿者: Suzu

引用:
引用:
VBS を作成し、タスクスケジュラー で一定時間毎に SQLサーバーの データを参照すれば良いです。
 そっちの方が、Access 終了されたら終わり を考えないで済みます。

 
ご提案ありがとうございます。具体的にどの様なVBSなのでしょうか。
そのVBSが自分の端末で動作するものであれば、話は戻って自分自身に通知トーストを出すこともできるように思えるのですが、間違っていますか?
 
何卒ご指導ご鞭撻のほどよろしくお願い申し上げます。

 
 
手元、SQLサーバーでのテストができる環境にないので
具体的な コードを提示できませんが、
 
『Excel VBA SQLサーバー』等のキーワードでWEB検索を行えば
SQLサーバーのテーブルに対して SELECT を行う VBA の コードが見つかります。
 
それを参考に、Excel VBA にて、目的の動作を実現するコードを作成。
 
そのコードを、VBS 用に変更すれば良いです。
大まかには
・宣言の型の指定をなくす。
・オブジェクト生成に対し、New を使用しない
 
で良いと思います。
 
 
このように、実現したい内容によっては代案の提案が可能なのです。
実現したい処理が判らず、手法を限定されてしまうと代案の提案も難しいです。

投稿日時: 21/08/18 22:08:56
投稿者: アロハ

Suzu様
 
コメントありがとうございます。
 

引用:
『Excel VBA SQLサーバー』等のキーワードでWEB検索を行えば
SQLサーバーのテーブルに対して SELECT を行う VBA の コードが見つかります。
  
それを参考に、Excel VBA にて、目的の動作を実現するコードを作成。

 
作成するべきVBSの内容は大体の想像はついたので、用意はできます。
もう1つ書かれた「タスクスケジュラー」はどうゆうことでしょうか。
該当するレコードを探しにいくVBSを一定時間毎に実行させる為のものだと思うのですが、VBSでもなんでもいいので、「タスクスケジュラー」をどのように組み込むのか具体的にご教授いただけないでしょうか。
 
例)フォームに設置したコマンドボタン1をクリックすると、record_search.vbsを5分毎に実行する。
  フォームに設置したコマンドボタン2をクリックすると、5分毎の実行を解除する。
 
何卒ご指導ご鞭撻のほどよろしくお願い申し上げます。

回答
投稿日時: 21/08/20 09:47:11
投稿者: Suzu

タスクスケジュラー
ではなく
タスクスケジューラ
 
でした。失礼しました。
 
 
Windowsの スタートメニュー Windowsの管理ツール に、タスクスケジューラ があります。
 
タスクの作成 から
 「トリガー」「新規」 にて
     設定     毎日
     繰り返し間隔 確認したい時間間隔
     継続時間   無期限
 
 「操作」「新規」 にて
    プログラム/スクリプト に、VBSファイルを指定
 
 

引用:
例)フォームに設置したコマンドボタン1をクリックすると、record_search.vbsを5分毎に実行する。
  フォームに設置したコマンドボタン2をクリックすると、5分毎の実行を解除する。

 
スケジューラ の操作 には、
API であれば、NetScheduleJobAdd
コマンドラインでの変更であれば schtasks /change
 
あたりが使える様ですが、確認はしていません。
 
 
ただ。。
解除し、その操作をAccess上のボタン等に配置したとして、Accessを(強制)終了したら?
極端な話、7日後 にAccess 起動した際にしかわからないのが困るのではなかったのですか?
それを防ぐために、Accessに依存しない方法を提案したのですが。。
 
スケジューラに対し変更をするのではなく
 スケジューラ にて実行するスクリプト内にて
   Access(指定のファイル/フォーム)が 自マシンにて実行されているか を検知すれば良いと思います。
 
 
ある一つについて思いつくと、それにとらわれすぎる様に見えています。
掘り下げる前に、他に方法が無いか について思いを巡らせること をお勧めします。

トピックに返信