tech

IODATAのNASで利用しているクラウドストレージ連携でS3にバックアップしているのだが、今日、急に以下のようなエラーが出るようになった。 <?xml version="1.0" encoding="UTF-8"?> <Error><Code>AuthorizationHeaderMalformed</Code><Message>The authorization header is malformed; the region 'us-east-1' is wrong; expecting 'ap-northeast-1'</Message><Region>ap-northeast-1</Region><RequestId>...</RequestId><HostId>...=</HostId></Error> NAS, S3側で特に設定変更はしていないのだが… クラウドストレージ連携のバージョン1.28が2020/2/26にリリースされているようなので、これが自動更新されたのかもしれない。 https://www.iodata.jp/support/qanda/answer/s30471.htm https://github.community/t5/GitHub-Actions/Cannot-get-an-AWS-Action-to-run-in-the-correct-region/td-p/17413 にあるように、既定で接続するとリージョンがus-east-1となり、ap-northeast-1リージョンのS3 bucketを操作しようとしてエラーとなっていると推測される。 対応として、詳細設定にあるエンドポイント指定にて、今まで未指定だったところに「s3.ap-northeast-1.amazonaws.com」を指定したところ、接続テストが成功することを確認。

すべてのイベントハンドラを一括で登録、削除する関数を作成する すべてのイベントハンドラの最初で削除し、最後に再登録する イベントの多重起動(Leaveイベント内で別ControlのFocusを実行して再度Leaveが実行される、等)を防ぐにはこれが確実 関数のreturn部分が複数あって複雑な場合は、try-finallyのfinally内で再登録する イベントハンドラから呼び出す関数内で削除,登録処理を行うと、その関数の呼ばれ方によって再登録が多重に行われてしまう可能性がある。関数を使う場合もイベントハンドラの中で直接一括削除、再登録を行う 複数のイベントハンドラが同じ処理をする場合でも、別のイベントハンドラを直接呼び出す実装をすると上記を満たさず破綻する。共通部分を別関数に切り出して使用する。

DataRow.Field とConvert.ToInt32 の違いについて、 int がstringになった場合でも同様。 DataRowの値がDBNullかどうかで分ける場合に var val = (dr["name"] == DBNull.Value) ? "" : Convert.ToString(dr["name"]) とやっていたのだが、 var val = dr.Field<int?>("name") ?? "" と書けるという記事を発見し、早速使ってみたのだが… Field版では、データがdecimalの場合にInValidCastExceptionが発生してしまう。値の範囲がintの範囲に収まっているかどうかは関係ない。 利用しているデータがdecimalの桁数指定で定義している箇所がほとんどという性質のため、これでは全く使えないと判明した… ただ、Convert.ToString(DBNull.Value) はstring.empty(空文字)に、Convert.ToInt32(DBNull.Value)は0になるので、これがOKであればこれが最も手っ取り早いとわかった。 DataRowのFieldやGetValueOrDefaultのようなジェネリクスメソッドは型変換の範囲が厳しく、逆にConvert系はおおらかなのだろう。

WindowsのMariaDBを10.2 -> 10.4のようにメジャーバージョンアップする場合について。 バージョンアップ自体は公式サイトの手順に従って行えば良い。インストーラにより、上記の場合はバイナリはC:\Program Files\MariaDB 10.4、データはC:\Program Files\MariaDB 10.2を参照するようになる。MySQLサービスの実行パスは "c:\Program Files\MariaDB 10.4\bin\mysqld.exe" "--defaults-file=C:\Program Files\MariaDB 10.2\data\my.ini" "MySQL" のようになる。 で、時間があるのでデータもバイナリも10.4のフォルダにするためにバックアップを取得した上で10.4をアンインストール、再度10.4をインストールすると、サービスが起動しない。 原因は上記実行パスのサービスがアンインストール時も消されずに残ってしまうためのよう。 MariaDBをすべてアンインストールした状態でsc delete MySQLを実行して残ったサービスを削除し、再度インストールすると正しい実行パスのサービスのエントリが生成される。

内製のシステムを、Accessベースから.Netに移行している。 その際に最大のネックになるのはレポート機能。 Accessのレポート機能は正直相当優秀だと思う。.Netの有償アプリで同等の機能を持つものを選定すると、開発者向けライセンスが100万レベルのものになってしまう。 それが、Officeの上位ライセンスに付属し、ランタイムだけなら無償で利用できる。 一方でネックはコードの開発生産性の低さ。VBAの文法は古めかしいし、何よりテキストではないのでGitで管理できない。 上記のいいとこ取りとして、Accessファイルのレポート機能だけを利用する方法を考えている。 Accessファイル側はレポートとレコードソースとなるテーブルのみ保持し、起動時にそのレポートが初期表示されるように設定しておく。 .Netのプロジェクト側では常に配布するコンテンツとしてAccessファイルを保持し、ADO経由でレコードソースとなるテーブルにデータを設定する。 その後外部プロセスとして該当のAccessを起動すると、レポートが表示される。 外部プロセスなので細かい制御はできないが、用途によっては十分だろう。 帳票数が多いアプリではきついかもしれないが、移行できない少数のレポートを活用する場合には十分かと思われる。