Access 2013 Access 97 ファイル形式のmdbをなんとかする

Access 97 ファイル形式を サポート してないのだからしょうがない。なら、なんとかするまでよ。

　JET 3.x をサポートしないから Access 97 ファイル形式を Acccess 2013 で開こうとするとこうなる。Access 2013 上で Access アプリケーション としての動作しないとしても、せめて ファイル形式を読み込める状態に。Access 2013 (ACE15)では対応できないから、ほかの方法で変換するしかない。Access 97ファイル形式を読み込める バージョン の Access がなくても、今のところなんとかなるはず。

Access 2010 / 2013 マクロ ビルダー -5-

少し便利です。ユーザー インターフェイス (UI) マクロを作成する にある情報ではあるけど、文字情報がちょっと多い。

　マクロ の作成/更新中にほかのマクロの参照ができる。

　検索にも対応してるので、ささっと同じ処理や似た処理のマクロを記述できるという仕掛け。

Office 2013 エスクローキー

やっとこさ、それなりの情報が出ましたね。そのうち試してみましょうか。

まぁ、Accessには関係ない話ですが。

• Now you can reset or remove a password from a Word, Excel, or PowerPoint file—with Office 2013!
• Remove or reset file passwords in Office 2013
• Microsoft Office 2013 DocRecrypt Tool

Office Open XML format documents such as docx, pptx, and xlsx files.

Access 2010 / 2013 マクロ ビルダー -4-

サブマクロ / SubMacro がコンパイルされない。そんな話。

　サブマクロがUI上では保存されているのだけど、実行可能な状態になっていないことがある。おそらくパーサが原因でしょう。ただし、影響を受けることはわずかだ。

　たとえば、この状態で保存されているマクロなのだが、サブマクロとして認識できないものがある。確認してみる。

Access 2010 / 2013 マクロでマクロ自身の名前を知る

がっつり昼寝した日の夜に徹夜して導き出した答え

　マクロ名をそのマクロ自身が知るためにはどうしたらよいのでしょうか？ そんなこと考えたことはないですか？私はありません。
　でも、マクロ名ゲットだぜぇっ！

　夢が広がるよね。そう思える想像力豊かな人もしくは多少のことは気にならない心穏やかな人以外は、この先読む資格がありません。ちなみに私は大雑把な性格です。

Access 2010 / 2013 マクロ ビルダー -3-

クエリ や データマクロ の パラメータ に値を渡しちゃう。

大してややこしいことではないのだけど。たとえば、

PARAMETERS Param01 Long;
SELECT ID, Field1, Field2
FROM Table1
WHERE ID = [Param01];

こんな クエリ があったとして、この クエリ を開く マクロアクション はこうなる。

パラメータ 句が解析されて入力できるようになる。VBA だと DoCmd.SetParameter ということ。ただ、少し注意しておくことがある。

Access 2010 / 2013 マクロ ビルダー -2-

FAQ的な話。

マクロアクション：[値の代入]がない！なんて言わないの。
Unsafe Actionのひとつなので表示されていないだけ。

"すべてのアクションを表示"を押下すると表示される。

実行したい内容によっては、マクロアクション：[プロパティの設定]を使ったほうがよいし、存在を知らないというのはよくない。

Access 2010 / 2013 マクロ ビルダー -1-

UI操作について、補足的内容

　Access 2010 からマクロ ビルダーがガラッと変わっていて戸惑うことが多いのでしょう。まぁそれ以前に グリッドで表現されてた以前のバージョンよりは使いやすいのでいいんじゃないかなと。

ビデオ: マクロ ビルダーの概要

ビデオにない操作方法についてのメモ

Powershell 言語仕様書

眺めてるだけでもわかったような気がする不思議

Windows PowerShell Language Specification Version 3.0
Windows PowerShell Language Specification Version 2.0

PowerShell DAOでAccessファイルを操作

Access が導入されていない環境で accdb (Access ファイル)を操作する。ただし、DAOで。

　集計フィールドをどうやって作ればよいのだろうと右往左往した結果。新規ファイルを作成して、テーブルといくつかのレコードを追加するメモ。

　忘れてしまうほど使うことがない。

Office 2013 を導入したとして、、、

Office 2013 はApp-V 5.0 ベースなのだから。

アプリケーションは仮想化ということだけど、普通に使う分には何ら問題もなく。ただ、分離された実行環境であるから、違いがあるんだなということをちょっと感じた。

PS C:\> $ds = ".\Database1.accdb"
PS C:\> $cs = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=$ds;"
PS C:\> $cn = New-Object System.Data.OleDb.OleDbConnection($cs)
PS C:\> $cn.Open()
"0" 個の引数を指定して "Open" を呼び出し中に例外が発生しました: "The 'Microsoft.ACE.OLEDB.12.0' provider is not registe
red on the local machine."
発生場所 行:1 文字:1
+ $cn.Open()
+ ~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : InvalidOperationException

PS C:\>

まぁそうなるわな。なんか方法あるかな。。。

Access 2010 / 2013 集計フィールド / Calculated Fields - 2 -

で、どんな時に使うと効果的か。

　テーブルに収めるロジックなのだから、基本的に変更されることがないロジックであるべきなのだろう。たとえば、[数量] * [単価] で [金額] 的なことだけど、該当のレコードが頻繁に更新されるものでなければよいということ。といっても、レコード数とマシンスペック次第だから選択は "お好みで"。きっと、ほとんど参照のみのテーブルに使うと効果はでやすいはず。
　MSのサンプルでも使われているけれども、名簿要素なテーブルに使うイメージがとても強い。[姓] & " " & [名] とか。MSのサンプルだといろんなフィールドを結合して検索用にしてあるよね。この場合、フィールドを演算する必要がないからその分クエリのパフォーマンスは高くなるという手筈。さて、もう少し具体的に。

Access 2010 / 2013 集計フィールド / Calculated Fields - 1 -

集計フィールドの使いどころ的なこと

　クエリで計算すれば以前のバージョンであっても使えるのだから使わないというのも良いのだけど、どこで使うかに大きな誤りがなければそれなりの成果があるわけで。要は非正規化。

集計フィールドを作る手順は難しいことはない。選ぶだけ。