Accessでフォーム起動時に該当列が存在しないエラーの原因究明
Access であるフォームを起動時に、特定の列が存在しない旨のエラーが表示された。その原因究明について。
該当フォームのレコードソースを見るとクエリが指定されており、エラーメッセージに表示された列が存在しないことを確認。ただ、どこから参照されているかがわからない。
該当フォームはマクロで起動されていたのでマクロを調べてみたが、フォームを起動する処理のみでおかしなところはない。 該当フォームの全てのコントロールのコントロールソースのプロパティを調べてみたが、エラーとなっている項目を参照している箇所はない。 VBAマクロにて該当フォーム内の全プロシージャを調べてみたが、やはり参照箇所はない。
最終的に、フォームの並び替えのプロパティで参照されていた。 かなり時間がかかってしまったが、次回同じようなことが起こった際には、ariawaseのようなツールでVBAをエクスポートしたあと、grepするほうが早くて確実だと思う。
Gitbookで丸かっこを含むリンク先の指定
Gitbookで丸かっこを含むリンク先(ローカルファイル変相対パス、URL)を指定する方法。
にある方法では、Visual Studio Code上のプレビューではうまくいくようだが、html出力した際にうまくいかない。 対処として、リンク先指定にて丸かっこをパーセントエスケープして指定する。
[例] test(1).txt → test%281%29.txt
Markdown上の表記と実際のリンク先が異なるのは気になるが、ほかに方法が見つからず。
サーバ台数1-2台でDocker or Kubernetes
私の勤めている会社では、サーバは全部で4台、そのうち3台はパッケージシステムやADが動作しているWindowsサーバでそのまま運用するだけ(過去に開発されて引き継いだAccessアプリはこの3台のWindows上で動作) 内製アプリは残りの1台でやりくりしています。とは言え利用者は限られているのでリソース的には余裕です。
Dockerで複数コンテナを立てて運用していましたが、Kubernetesが流行っていることも知っていたので是非導入したいと思い、チャレンジしていました。 結論としては、うちの規模では割りに合わない、Docker運用に戻すことにしました。
Dockerのメリットは * コンテナ化することで複数のサーバを独立に動作させることができる * PublicなDockerイメージからDockerfileでイメージを構築する形にすれば、Dockerfileさえあればどの環境でも同じように動作させることができる * docker-composeを利用すれば、コンテナ起動時の連携設定等も行える
Kubernetesのメリットは、上記に加えて * 同一イメージのコンテナを複数立てて負荷分散する設定を簡単に行える * Blue-Greenデプロイのように既存の環境を維持したままのDeployが設定で簡単にできる あたりが一例としてあると思います。
一方でDockerに対するKubernetesのデメリットとして * DBの運用が難しい - PVCを使えばできるようだが、壁は低くない * 非Publicなコンテナを利用するのであれば、別途Registryサーバが必要 * ネットワーク構成が複雑、外部に公開するためにまぁまぁの設定が必要 - 複数ノードで負荷分散を可能にするための抽象化だが、そこまでいらない場合にはつらい
現状では、内製アプリが死んでも即困る状況ではなく、気付いたらDockerコンテナを起動すれば良い程度の状況なので、Kubernetesで複数コンテナを分散運用する必要もなく... ただDBだけは守る必要があるので、しっかりバックアップしてすぐに復旧できるようにしたい。となるとDockerでホストVolumeを使ってやるくらいがメンテしやすい。
このような理由でDockerに戻します。 その上で、DBのバックアップやリストアなどの手順をAnsibleでコード化しておく、あたりが今のインフラ規模ではベストだと判断しました。
Kuberetesのソリューションには、シングルで運用できるminikubeやmicrok8s,k3sなどのソリューションがあり簡単に始められますが、運用にあたっては同一コンテナの負荷分散が必要、のような必要性がないと難しいと思いました。お金をかけられるのであれば、EKSなどのマネージドサービスがベストだと思います。
mdbファイルが破損している場合
mdbファイルが破損している場合、最初のクエリ実行時にOleDbExceptionが発生します。 これをキャッチすれば破損を検知するロジックはとりあえず書けます。
IaCの壁
社内のLinuxサーバは極力Ansibleで状態を管理し、サービスはDockerコンテナで運用している(DB除く)。いわゆるIaC(Infrastracture as Code)を実践しているつもり。 これの何が嬉しいかというと、正直なところ個人的にコマンド一発で全てが出来上がるのが楽しい、というところが大きかったりする。ピタゴラスイッチ、ルーブ・ゴールドバーグ・マシンを見ているような爽快感、とでも言うのだろうか。
そんな感覚はない場合、紙の手順書をコードに置き換えるのは面倒と感じるのもわかる。何が面倒かと言えばコードには曖昧さが許されないことだと思う。手順書は曖昧に書いて「言わなくてもわかるよね」という雰囲気で終わらせることもできるが、コードは書いたようにしか動かない。コードに落とすためには対象のプログラム・システムの仕様を正確に理解しないといけないし、何をもって正常とするのか、それはどんなケースでも正常と言えるのか、突き詰めて考えないといけない。この辺りが利用する組織や文化によって大きな壁になるのだと思う。
ただ、慣れてしまえばむしろ誰かが決めた書式・ルールに従って手順書を書く手間、変更された際に保守する手間もなくなるし、手元の仮想化環境などで簡単に再現してテストできる、最高の環境になる。
Kubernetesでコンテナ動作させる際の基本
思い切ってKubernetesを構築、試験運用を始めました。Ubuntu Server 20.04のMicroK8sです。
docker-compose で動作するところは確認できていたので余裕かと思っていたのですが、はまってしまいました。
症状は、 CrashLoopBackOffで再起動が続く状態。これ当然まともにコンテナが起動せずに終了してしまっているからなんですが、手元の環境ではDockerfileとdocker-composeの合わせ技で奇跡的にうまく動作していたため、Kubernetes側の問題だろうとあれこれ調査して時間を浪費してしまいました。
KubernetesではDockerfileによるbuild済みのコンテナイメージを起動します。docker-composeに記載している処理は、Kubernetesのyamlに記載するか、Dockerfileに記載する必要があります。 が、Kubernetesのyamlに同じ内容を記述できるとは限らず、また記述できても同じ動作をするかはわかりません。ですので、極力Dockerfileに記載してdocker-compose.ymlはシンプルにとどめておいたほうがよさそうと感じました。
また、内部の名前解決用に使用しているDNSは、解決できないと8.8.8.8にforwardしてしまう。Kubernetesの外の社内サーバを名前で参照する場合には、dnsConfigなどの設定でforward先を変更する必要がある。
Accessはできることが多すぎる
過去に開発された内製アプリをC#+RDBMSに置き換えていて思うこと。
kintoneやPowerAppsのようなローコード、ノーコードと言われる分野のアプリで置き換えようとすると機能が足りず、ガッカリして断念している。 ふと思うのは、むしろAccessが高機能すぎるのではないかということ。特にVBAはやろうと思えばなんでもできてしまう。会社の前の基幹アプリはAccess VBAでできていたし。
Accessが目指すべきなのは、クエリ、マクロ、フォームの組み合わせでできることに特化すべきで、それ以上のことは別のやり方でやってください、とすべきだったのではと思う。VBAは禁止。クエリもGUIで組み立てられるレベルまで、サブクエリは禁止、くらいでちょうど良い。
WordやExcelのVBAは、普通に作る分にはUI,データソース共に限られるので問題にならないが、AccessはなまじDBMSとしてテーブル、SQLをサポートしているので複雑なことまでやろうとしてしまう。グラフもそれなりに書けてしまうし。
他の言語がここ十何年で目覚ましい進歩を遂げて入り一方でVBAがここ何年もほとんど進化していないのは、できることが多すぎてそれらを維持したまま進化させるのが難しいという一面もあると思う。メインの利用者が非開発者でそのような進歩を望んでいないことも大きいと思うが。
最新の言語を書いた後にVBAのプアな機能を使ってコードを書くのはとても辛い... Visual Studio Tools for OfficeもAccessはサポートしてないし。
ローコード、ノーコードアプリはスプレッドシートをデータソースとすることが多いので、AccessはExcelのみをデータソースとしてサポートする、くらいで良いと思うが、それってPowerBIだよねという話で、Accessはもはや不要な製品だと思う。
Accessの値段でAccessと同等の機能を持つ製品はなく、(自分も含めて)影響は大きいが、大規模な時代遅れなAccessのVBAの保守を任される開発者も、時代遅れなVBAを進化させることができずに細々とサポートするMicrosoftの開発者も不幸な今の状況を考えると、Accessは終了すべきと思う。長めの期間をとって移行のロードマップを示す必要はあるが。10年後にVBAバリバリのAccessアプリが残っている未来を想像したくない。
