VBAでレポートのウィンドウサイズを変更した際の残像をなくす
VBAでレポートを開き、それをMaximizeなどでウィンドウサイズを変更すると、まるで処理落ちしたかのような、ウィンドウのサイズが変わる最中の残像のようなものが出ることがある。
これはスクロールバーで表示領域を変更したり最大化を解除すると解消されるのだが、レコード数もフィールド数も少ない状態ではスクロールバーが表示されないことがあるし、例え表示されたとしても、それをエンドユーザーに押しつけるのは鬱陶しい。
そして最大化を解除などしては本末転倒だし、一度解除してから手動で最大化しても、やっぱり残像が発生する。
これがフォームであれば、RefleshやRepaintで解消出来るのかもしれないが、あいにく、レポートオブジェクトに対してこのメソッドは用意されていない。
しかし、作業をしている中で、一部のレポートはこの残像が発生していないことに気付いた。それは、Maximizeの後で、レポートのサイズなどをVBAで変更しているもの。
そして上記の通り、画面スクロールなどでもこの残像は解消される。要は、画面の再描画が必要になる何らかの動作を加えれば残像が消えるということ。
そこで、Maximizeで最大化した後、ウィンドウの幅を取得し、それをそのまま再設定することで、見事に残像が解消された。
なお、そのままやると最大化などで画面がちらつくので、事前にApplication.EchoをFalseにしておき、処理が終わってからTrueに戻した方が良いだろう。
'レポートを開く
DoCmd.OpenReport ReportName
'画面の再描画をオフにする
Application.Echo = False
'ウィンドウを最大化する
DoCmd.Maximize
'ウィンドウサイズを再設定する
Forms(Me.Name).Width = Forms(Me.Name).Width
'画面の再描画をオンにする
Application.Echo = True
Nullを含むテーブル同士のユニオンクエリ
ユニオンクエリはフィールド数が同じテーブル同士を一つにまとめるが、最終的に出力されるフィールドのデータ型は、最初に記述したテーブルに依存する。
通常、ユニオンクエリでまとめるテーブル同士は同じ構造を持っているものを使うだろうし、それで何の問題もないのだが、Null値を含むテーブル同士の結合になると問題が生じる。
具体的には、次のようなデータ構造を持つテーブル同士をユニオンクエリでまとめると、2つめのテーブルのフィールドFがText型や文字化け状態になってしまう。
SELECT フィールドA（Long型）, フィールドB（Date型）, フィールドC（Null）
どうやら、先頭のテーブルでNull指定のフィールドがあると、正常に型の判断が出来なくなるらしい。
ならば先頭にNullがないテーブルを持ってくれば良いのだが、どうしてもこのような構造にしたい場合には、テーブルの順を入れ替えても今度はフィールドBがText型扱いされるだけ。
そこで、型指定のためだけに、中身のないテーブルを先頭に配置することで解決する。
SELECT CLng(0) As A, CDate("2000/1/1") As B, CDate("2000/1/1") As C
ポイントは、先頭のテーブルで型変換関数を用いてフィールドのデータ型を明示してやること。
無論、そのままでは型指定のためのダミーデータが表示されてしまうので、WHERE句でFalseを指定してやることで、これを防いでいる。
なお、このダミーテーブルは何のテーブルのデータも使っていないが、FROM句を指定しないとエラーになるので、Table0には実在する適当なテーブル（何でもいい）を指定しておく。
