Windows 7 の64ビット化 (5) 64ビット化してから、どうもAccess 2007が不安定
OSを64ビット化してから、どうもAccess 2007が不安定で困ってます。
32ビットOSでは問題なく動作していたが、64ビットOSではエラーがでたり、応答が悪かったり。
どうするか? >自分
とりあえず、Access 2010 でテストしてみて、その結果で考えよう
あまり考えたくはないが、MS-Accessから撤退もあるかな?
MS-Accessは使い慣れているのでよく使っているが、欠点は、動作しなくなったときにブラックボックスが多すぎて、
解決に時間がかかること。
もっと安心して使えるツールに乗りかえるか...
2011/02/04 追記
Access 2010を1本購入して、Access 2007 からアップグレードを行ってみた。
さあ、結果はどうか。 64ビットOSでも、問題なく動いてくれるか。 ドキドキ
結果:
過去に作成したMDBやADPが、ほぼ問題なく動いているようにみえる。
Access 2007 製品版で発生していたエラーが発生しなくなったようだ。
ただ、新たな事象で悩まされている。
どんな時に発生するか特定までいたっていないが、
突然、「VBAのソースが文字化け」するようになった。
こんな感じ...
<文字化け前> Private Sub コマンド88_Click() Me.ソート = 1 End Sub <文字化け後> Private Sub コマン_Click() Me.ソ= 1 End Sub
どうも、全角カナが文字化けというか、ロストしていると思われる。
コントロール名に全角を使わなければ、このような文字化けには遭遇しないのかもしれないが、
過去のMDB,ADPはメンテナンスを考えて、全角文字を多用していたので、いまさら引き返せない。
毎回必ず発生する分けではないので、もう少し様子を見ていきたいと思う。
2011/02/08追記
しばらく様子を見ていたが、昨日また再発が始まった。
この文字化けの現象が起きると、ソースコードが文字化け状態で保存されてしまい、
その後、エラーが必ず発生するようになる。
発生してしまった場合は、バックアップから戻すしかない。 ちょっとへこんでます。
推測ですが、”コマンド”という全角カタカナが、MS-Accessの何らかしらのバグを呼び起こしているんじゃないかと、
にらんでます。
※”コマンド”はボタンにAccessが勝手に付けるコントロール名
一般的に、データベースソフトでは全角文字を使うのはご法度のようです。
Lotus Notesなんかは全角を使えますが、バグが潜んでる可能性が高いので、全角を使わないでプログラミングするように推奨されてるようです。
MS-Accessは、これまで全角を使っても問題が起きなかったんですが、ついに、キタッて感じ...
とりあえず、コントロール名に「コマンド」の文字を含んでいるところを「cmd」に置き換えてみたいと思います。
ボタンの数が数百個ありそうなので、いつ終わるやら。
間違って修正するとアプリがとまるので、テストも必要か... ヤレヤレ
2011/02/14 追記
まだ、コントロール名の”コマンド”を”cmd”に置き換える作業を続行中...
何かほかに安定させる対応策はないか調べていたが、一つ良いことを発見した。
試に1DBを変換してみたが、かなり安定しているようで、”コマンド”を含むDBも問題なく動いているみたい。
とりあえず、コントロール名の”コマンド”を”cmd”に置き換える作業を続行するが、
「accdbへのファイル変換」も実施しようかと思う。
2011/02/16追記
コントロール名の”コマンド”を”cmd”に置き換える作業を続行中であったが、途中で中断した。
理由:
”cmd”に置き換えしたmdbで、ソースの文字化けが再発したため
今のところ、「mdb」を「accdb」にファイル変換したDBでは、1回もソースの文字化けは発生していない。
◆まとめ(現時点の仮説だけど...)
mdbにフォームを含む場合、下記の環境では使い物にならない ・Access 2007 & Win7 x64 ・Access 2010 (x86 , x64ともに) 不具合事象 (必ず発生するわけではないが、突然発生する) ・ソースが文字化けする ・フォームは存在するが、見つけられなくなる 上記の環境では、フォームを含む「mdb」は「accdb」にファイル形式を変換すると不具合は発生しない。
2011/03/04 追記
2月末にaccdbで、またもやソースの文字化けが発生した。
もう打つ手がないか...
で、思いついたのは「accdeへの変換」
◆accdeへの変換
やってみたところ、変換できない。
なんで...
ヘルプには「TableIDが1000を超えている~」なんてトンチンカンな内容が記載されている。 テーブル数は30個程度(これでも多い方)
Visual Basic Editor を開き [デバッグ] メニューの [DatabaseName のコンパイル] を行ったところ、エラーが1ヶ所あった。
エラー内容は、単純なコントロール名の記載ミス。
当初は正しいコントロール名だったが、ソースを書いた後に、フォーム側でコントロール名を変更しており、不整合が発生していたようだ。
accdbを使用している際に、該当の部分の操作を行っていなかったため、いままで表面化しなかったようだ。
ただ、この部分を書いたのはかれこれ2年くらい前... ?
[デバッグ] メニューの [DatabaseName のコンパイル]をやってみて気づいたんですが、
コンパイルが済んでいれば、この[DatabaseName のコンパイル]は、選択できないようになっている。
◆ソースの文字化けについて
これまで、さんざん悩まされてきた「ソースの文字化け」は、DBを利用するさいにコンパイルするから発生するのかも。
ソースを修正した後は必ず、 [DatabaseName のコンパイル] を行い、コンパイルが未完了でない状態にすれば、もしかしたら回避できるかも。
確実な方法は、accdeに変換してしまうこと。 これなら、コンパイルが発生せず、ソースの文字化けは発生しないのかも。
あくまで仮説の状態ですが、 [DatabaseName のコンパイル]を行い引き続き様子をみていこうと思う
その後、そちらではAccess君は迷走していませんか?
こちらでも同じ症状が発生しました。accdbです。
Windows7もOffice2010もServicePack1+最新のパッチが当たっているのに。
※最後の更新ファイルは8/13に当ててますので、(『インストール日』?で確認)
パッチのせいでは無さそうです。
64ビットPCでは相変わらず発生しますね。
最近は慣れてきて、32ビットのサーバーにAccess2007を入れておいて、リモートデスクトップで入って、修正&accde変換してユーザに公開しています。
自分のPCが64ビットなので、たまにaccdbを開けてしまうんですが、間違いなくソースが壊れてしまうんで、バックアップは念入りに行ってます。
早く治るといいのですが、気長に待とうと思ってます。
...と、言いつつ、今月末までにクラウドへの移行のために何本かAccessアプリを修正しないといけないのですが、間違って最新のaccdbを壊したりすると痛い目をみるので、注意して作業しようかと思ってます。
お忙しい中、お付き合いいただき有難うございます。
今は腫れ物に触るように使っています(メインはWinXP & Acc2002に逆戻り)。
少しだけわかった?こと
モジュール内で、Me!コマンドやMe.コマンド→Me!コマになっている場合でも、
Me.Controls(”コマンド”)としてある場合は、伝染しない。
一旦おかしくなった場合に、Accessアプリケーションを終了しないで
他のファイルを開くと、そっちでも起こりやすい。
早く修正されますように。合掌。
なんとかAccessアプリの修正がおわり、オンプレミスのサーバーが使えなくなっても、アマゾンクラウドにスイッチできる環境が整いました。
今回の修正の際は、自分の64ビットPCから、Accessはアンインストールしてrutimeに切り替えてしまい、修正は32ビットPCにリモートデスクトップで入って作業しました。
これなら、ソースが壊れることはないので、つまんないことに時間をとられることなくスムースに作業できたかな...
しつこくて、すみません。(^^ゞ
もしかして、
http://support.microsoft.com/kb/2297924/ja
では?
互換モードから呼び出されたものも互換モードで動作する様です。
現象的には当たりかも...
ただ、互換モードは指定していないし、Accessアプリを「あやめ」というランチャからきどうさせてるんですが、これも互換モードではないですね。
発生契機が「互換モード」だけというのが怪しいかも...
しっかりと確かめたわけではないですが、最近、mdb,accdb,adpを開いてもソースが壊れることがなくなったみたいな感じです。
時間取れたら確認したいと思います。