Magic xpa（にかぎらず、V8からありますが）では、Dbdel・FileDeleteなどのDB関数・File関数が実行されず、不整合やバグとなることがあります。
たまに変なデータがある・・・という方はチェックしてみてください。
公式見解 Readmeより引用
DB関数やIO関数が正しく動作しない場合があります。
Windows Vista以降において採用されたSMBv2プロトコルの影響と思われます。Magicを使用しない環境において、サーバ側に作成した直後のファイルをクライアント側からdirコマンドを実行したときにもファイルの存在が確認できないことがあります。
そのため、Pervasive SQLファイルのように物理的にファイルを作成するDBMSにおいてこのような現象が発生することがあります。以下のような回避方法をご検討願います。
- ワークファイルなどは、クライアント側に作成する。
- Dbdel関数でファイルを削除せず、バッチタスクの削除モードでレコードのみを削除する。
- IOExit関数を繰り返し実行して、「True」が返されてから、次の処理を実行する。
- SMBをv1にする。
以上引用でした。この詳細と、私が発見した別の原因もご紹介します。
Pervasiveにて問題が起こっている方だけ見ていってくださいね。
- クラサバ環境
- RemoteApp環境
- 公式対処法②③について
この3つに分けて解説していきます。
クラサバ環境の場合
物理的原因と対処
- Wi-Fiなど無線でつないでいるため動作が不安定→LAN線をつなぐ
- HUBが遅い→LANの通信規格と合っているか確認する
- File関数ではなくDB関数に変更する
クライアント→サーバにつながるのが遅いため、消す処理を実行する前に次の処理が走っています。
これは、FileDeleteの方が起きやすいです。
Dbdelの場合、テーブルにアクセス・ロックするため、次の処理が走っていくことも少ないですが、FileDeleteはサーバにファイル消して、という指示を出して終わりになるため、環境のスペックに影響されてしまうからです。
物理環境を変えられない、というときは一旦File関数をDB関数に変更してみて下さい。これで解決できたこともありました。
インストール環境の原因と対処
- ワークファイル（一時的に使用するファイル）をローカル（クライアント側）に設置する。
- リクエスタではなくワークグループをインストールする。
公式対処法①のことです。
Dbdelする、ということはワークファイルが多いと思います。
何人かで書き込みに行く共通のテーブルであればサーバに置く必要がありますが、何度も書き込み削除するワークファイルであれば、通信速度に影響されないローカルに配置しましょう。（クラサバの時ですよ）
そのためにも、リクエスタではなくワークグループをインストールして、データの管理をできるようにしましょう。
RemoteApp環境の場合
・SMBをv1にする
公式対処法④のことです。が、おすすめはできません・・・
たまに古いアプリを使用したいというお客様の要望で変更することはありますが、セキュリティ面で不安が残ります。
また、これで解消できたお客様はいませんでした笑
あくまで私のお客様の話なので、一度試してもいいと思います。うまくいかなければ戻しましょう。
RemoteAppの場合、クラサバみたいにローカルで全部処理しているのと同じため、他に改善策は思いつかず・・・もし改善方法を見つけたら追記します。
公式対処法②③について
- Dbdel関数でファイルを削除せず、バッチタスクの削除モードでレコードのみを削除する。
- IOExit関数を繰り返し実行して、「True」が返されてから、次の処理を実行する。
できたらいいですよね～笑
すでにシステムを作っているのに、全部にこれをするのは現実的ではないです。
時間・労力のコストとシステム規模で採算が取れるならやってもいいですよね。確かに不具合は起こらなくなると思いますので、どうしても・・・って方はぜひ。まずはこれ以外の対応策で試してみてください。
まとめ
DB関数とFile関数の不具合対処法でした。
今回私がご紹介した、クラサバの対処法はすべての導入で行っておくべき基本だと思います。
不具合が起きる前に、思い当たるお客様がいたら確認しておきましょう。
以上、参考になれば嬉しいです。おわり。
コメント