TL;DR AccessのグラフはModernとClassicの2種類。細かい要件は無くて手っ取り早くきれいなグラフを作るならModern、調整が必要な場合はClassic。(Classicならどんなグラフも可能とは言ってない) 経緯 Accessでグラフを作ることになり調査。最新のMS365のAccessでは、ModernとClassicの2つがあることが分かった。 Modernは、今どきのおしゃれな感じのグラフがパッとできる。が、マーカーのサイズを調整したりとか、凡例の位置を微調整したりとか、細かいところができない。 一方Classicは、見た目は古臭くて野暮ったいが、かなり細かい調整ができる。 MicrosoftとしてはModernを売っていきたいのだろが、Classic出ないとできないことがまだ結構ある印象。それでも長期的にはModernに統一される可能性はあるので、Modernで十分な場合は採用し、そうでない場合のみClassicとするのがよいだろう。
TL;DR .Net FrameworkからAccessの通貨型の列に値を設定する場合は、System.Decimal型を利用する。 経緯 伝票番号が11桁の数値となるシステムにて、値をSystem.Int64型に格納していた。最終的にAccessのテーブルに格納する必要があり、こちらは通貨型で整数部11桁で定義していた。 OleDb経由でParameterを利用して(SQLにべた書きせずにobject型の変数として渡す)INSERTしたところ、何のエラーも吐かずにこけた。 どうも、System.Int64(=long)が渡されるとAccess側ではLong型(-2,147,483,648 ～ 2,147,483,647)に変換しようとするらしい。ただ、該当の列に「1L」(System.Int64型)を与えるとこけるが、「1」(System.Int32)ではこけないので、値そのものではなく型の違いによるエラーなのだと思われる。DEBUG実行してもエラーをはかずにこけるので切り分けに時間がかかった… 相手が通貨型11桁なのでそれに合わせてよしなに変換してくれるものと思っていたが甘かった。が、前回同じコードを実行した際にはエラーは起きなかったはずなのだが… 仕様が変わったのか? まぁ、特にAccessのような(レガシーな?)システムとの接続の際には、自動変換には期待せずこちらで必要な型が分かる場合は指定したほうが無難だと理解した。
Access であるフォームを起動時に、特定の列が存在しない旨のエラーが表示された。その原因究明について。 該当フォームのレコードソースを見るとクエリが指定されており、エラーメッセージに表示された列が存在しないことを確認。ただ、どこから参照されているかがわからない。 該当フォームはマクロで起動されていたのでマクロを調べてみたが、フォームを起動する処理のみでおかしなところはない。 該当フォームの全てのコントロールのコントロールソースのプロパティを調べてみたが、エラーとなっている項目を参照している箇所はない。 VBAマクロにて該当フォーム内の全プロシージャを調べてみたが、やはり参照箇所はない。 最終的に、フォームの並び替えのプロパティで参照されていた。 かなり時間がかかってしまったが、次回同じようなことが起こった際には、ariawaseのようなツールでVBAをエクスポートしたあと、grepするほうが早くて確実だと思う。
mdbファイルが破損している場合、最初のクエリ実行時にOleDbExceptionが発生します。 これをキャッチすれば破損を検知するロジックはとりあえず書けます。
過去に開発された内製アプリを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アプリが残っている未来を想像したくない。