※前回までのシリーズの一連の話にはなるのですが、データコンバートとは違うので別にしました。
話が長くなるので先に答えを貼り付けておきます。「ExportFile」という関数を実行しています。
タスクスケジューラの登録はこういう感じで
・プログラム/スクリプト
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
・引数の追加
-Command ".\ExecuteAccessVBA.ps1"
・開始
D:\test
「開始」にカレントディレクトリを設定しておけば、
引数に指定するPS1ファイルを相対パスで指定できるようになります。
Access内の関数やクエリを、定期実行したいと思ったことありませんか?
えーとこれはシステム設計がヒドイいという前提ですが、
今回の背景としては、
・Access内のDBをすべてデータベースサーバーへ切り離した。
・しかし当該Accessを参照しているAccessが多く、これらをひとつひとつ改修するには時間がかかる。
・ひとまず当該Accessと同名同箇所にダミーAccessを生成、定時実行してAccess内のDBを更新する。
というものです。AccessやExcelでシステム設計するとこんなヒドイことになる、という一例です。
皆様もくれぐれもお気をつけを(ってそんなことしないかw)。
例示のため、今回は関数名の通りテーブルをExcel出力しています。
・PowerShellでAccess.Applicationを取得
・Accessファイル「powershell実行テスト.accdb」をオープン
・Access内関数「ExportFile」を実行
という段取りです。
MSDNはこちら。
https://docs.microsoft.com/ja-jp/office/vba/api/access.application
https://docs.microsoft.com/ja-jp/office/vba/api/access.application.opencurrentdatabase
全然調査はしていないんですけど、AccessのApplicationオブジェクト取得後、
操作対象のAccessファイルをopenした後は、VBAを書くように操作できるみたいです。
これを用いた技術情報は、びっくりするくらい見つからないですが、
VBAの知識とMSDN読めばなんとかなると思われ。
そして書いたコードはこちらってわけです。
クエリを実行したいときはこういう感じです。
アラートを消しておかないと、普通にメッセージが出ちゃって煩わしいので、
ちゃんとSetWarnings($False)しておきます。
って感じで、オブジェクトを取得してしまえばあとは普通に操作できちゃいます。
AccessやExcelなどとは、うまくお付き合いしつつ、
今後は引退してほしい仕組みだと個人的には考えておりますが、
なるべく今っぽい仕組みでフォローしてやる場合もありますよね。
PowerShellとタスクスケジューラで、Accessの関数やクエリを定期実行する
どうしてこんなことしたのか!?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
$file = "C:\test\powershell実行テスト.accdb" | |
$access = New-Object -ComObject Access.Application | |
$access.OpenCurrentDatabase($file) | |
$access.Run("ExportFile") | |
$access.Quit() |
タスクスケジューラの登録はこういう感じで
・プログラム/スクリプト
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
・引数の追加
-Command ".\ExecuteAccessVBA.ps1"
・開始
D:\test
「開始」にカレントディレクトリを設定しておけば、
引数に指定するPS1ファイルを相対パスで指定できるようになります。
必要となる状況は限られると思いますが…
ここからは背景についてAccess内の関数やクエリを、定期実行したいと思ったことありませんか?
えーとこれはシステム設計がヒドイいという前提ですが、
今回の背景としては、
・Access内のDBをすべてデータベースサーバーへ切り離した。
・しかし当該Accessを参照しているAccessが多く、これらをひとつひとつ改修するには時間がかかる。
・ひとまず当該Accessと同名同箇所にダミーAccessを生成、定時実行してAccess内のDBを更新する。
というものです。AccessやExcelでシステム設計するとこんなヒドイことになる、という一例です。
皆様もくれぐれもお気をつけを(ってそんなことしないかw)。
PowerShellは何でもできる子!!
さてそんなときは、PowerShellからAccessファイル内の関数を実行してやりましょう。例示のため、今回は関数名の通りテーブルをExcel出力しています。
・PowerShellでAccess.Applicationを取得
・Accessファイル「powershell実行テスト.accdb」をオープン
・Access内関数「ExportFile」を実行
という段取りです。
MSDNはこちら。
https://docs.microsoft.com/ja-jp/office/vba/api/access.application
https://docs.microsoft.com/ja-jp/office/vba/api/access.application.opencurrentdatabase
全然調査はしていないんですけど、AccessのApplicationオブジェクト取得後、
操作対象のAccessファイルをopenした後は、VBAを書くように操作できるみたいです。
これを用いた技術情報は、びっくりするくらい見つからないですが、
VBAの知識とMSDN読めばなんとかなると思われ。
そして書いたコードはこちらってわけです。
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
$file = "C:\test\powershell実行テスト.accdb" | |
$access = New-Object -ComObject Access.Application | |
$access.OpenCurrentDatabase($file) | |
$access.Run("ExportFile") | |
$access.Quit() |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
$file = "D:\test\powershell実行テスト.accdb" | |
$access = New-Object -ComObject Access.Application | |
$access.OpenCurrentDatabase($file) | |
$access.DoCmd.SetWarnings($False) | |
$access.DoCmd.OpenQuery("insert_record") | |
$access.Quit() |
ちゃんとSetWarnings($False)しておきます。
って感じで、オブジェクトを取得してしまえばあとは普通に操作できちゃいます。
AccessやExcelなどとは、うまくお付き合いしつつ、
今後は引退してほしい仕組みだと個人的には考えておりますが、
なるべく今っぽい仕組みでフォローしてやる場合もありますよね。
0 件のコメント:
コメントを投稿