HeidiSQLがDEFAULT CURRENT句を認識しない

社内データベースをMariaDBで構築しており、Windows 10からHeidiSQLにてアクセスしているのだが、TIMESTAMP型の列にDEFAULT CURRENT_TIMESTAMP を設定すると、更新は成功するのだが、画面上表示されない。コメントまで表示されなくなる。 値が設定されていないわけではなく、 show full columns from テーブル名 で確認するとちゃんと設定されているので、別画面で確認しながら進めないといけない。めんどい。 OS: Windows Server 2008 R2 SP1 MariaDB: 10.2.9 HeidiSQL: 9.4.0.5125 本家のForumを見ると、2件同様の報告が上がっているが、コメントがついていない。 別のツールに切り替えるか。

<span title='2017-10-19 16:45:52 +0900 +0900'>October 19, 2017</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

中年プログラマーの気概

ネガティブな話から始まりますが… 作者は来年で40になります。 Software DesignやWeb DB Pressなどの雑誌を見ていると、自分より若いと思われる人の記事が圧倒的に多くなってきました。 技術・スキルが優れていれば年齢など関係ないことはわかっているのですが、ちょっとした疎外感を感じたりします。 私が新卒入社した際には、ウォーターフォール開発全盛で記事も40~50代のものが多かったような気がします。Web系の技術は特に技術の進歩が早く、若い人ほどキャッチアップしやすいという状況はあるように思います。 ですが、IT技術が好きという気持ちは今でも変わりませんし、幸い(?)まだまだコーディングに携われますし、それなりの権限を持って作業ができるポジションにいます。 今の自分のポジションでしかできないことを行い、発信していこうと思います。定年までには雑誌に記事1本載せて見たい!!

<span title='2017-10-17 12:22:46 +0900 +0900'>October 17, 2017</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

.Netプログラムの配布

今さら、とは思われるとは思いますが… 当社の社内システムは、外部業者に保守を依頼している販売管理システムとパッケージの会計システムを除いて、はほぼAccessでした。データもファイルに含んでいるタイプ。 なので、各自ファイルをデスクトップにコピーするとデータが共有できなくなるので、ファイルサーバにファイルを置いて、各自が直接実行する形で利用していました。たまに動作がおかしくなったのは、同時起動でファイルが壊れたりしたのではないかと思ってます。 現在、社内システムをC# + RDBMS(SQL Server, MariaDB)に移行中。 上記の感覚で、C#のプログラムは、dllも含めてファイルサーバに置いて、各自直接実行してもらってました。さすがに動作がおかしくなることはないのですが、dllも含めて手動で配置しないといけないとか、ファイルサーバの場所を忘れると実行できないとか、いまいちだな~と思ってました。 そう、ClickOnce。 プロジェクトの設定にて「発行」の項目でファイルサーバを指定して発行すれば、インストーラが生成され、それをインストールしてもらえば以降はスタートメニューから起動可能。バージョンアップ時の更新も勝手に検知してやってくれる。最高!! 10年遅れ? でMicrosoftさんの素晴らしさを実感しました。

<span title='2017-10-12 17:52:37 +0900 +0900'>October 12, 2017</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

MariaDBからSQL Serverを直接参照するテーブルを作成

概要 Windows上のMariaDBからSQL Serverを直接参照するテーブルを作成します。Accessのリンクテーブル。 Connect Storageという機能を利用します。 経緯 社内データの保管に、以下の理由でSQL Serverを利用していました。 ODBCを設定せずにExcelから参照できる。 Windows認証を利用できるので、アプリで認証を考慮する必要がない。 後者に関しては、エラー時の対応等、逆にややこしくなりそうでメリットにならないと判断。ただ、前者を利用した、簡易BIとしてのExcelピボットテーブルファイルが利用されているため、うまく対応する必要がありました。 将来性を考えると、10GBに制限されるSQL Server Express Editionは避けたいところ。そこで、まずMariaDBサーバを立ててSQL Serverのデータを参照する形で運用を開始することにしました。 MariaDBには、異種データベースを参照するConnect Storage Engineという機能があることが分かり、これを利用して実装しました。 前提 OS: Windows Server 2008 R2 Maria DB: 10.2.9 SQL Server: SQL Server 2008 R2 Express Edition データベース名: DBTEST DBユーザー名: USERTEST, パスワード: PASSTEST テーブル名: TABLETEST 手順 管理ツールの「データソース(ODBC)」にて、SQL ServerへのDSNを登録(DSN名を「SQLSVR」とする) MariaDBにmysqlクライアントで接続し、以下のコマンドでConnect Storage Engineを有効化する。 INSTALL SONAME 'ha_connect' 以下のコマンドでConnect Storage Engine経由での参照を利用したテーブルエントリを作成する。 CREATE TABLE TABLETEST ENGINE=CONNECT DEFAULT CHARSET=cp932 TABLE_TYPE=ODBC CONNECTION='DSN=SQLSVR;UID=USERTEST;PWD=PASSTEST'; 問題点 上記手順だと、該当のデータベースの一覧(show tables)まではできるが、内容を取得(select * from …)できない。 SELECTしか必要ない場合においても、全データベースに対する全操作の権限(grant all on ....

<span title='2017-10-10 00:00:00 +0900 +0900'>October 10, 2017</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41

Dockerでstorageにoverlayを使う際の注意事項(2016/2時点,CentOS7)

Dockerでstorage driverにoverlayを使ってはまったこと。 2016/2時点 CentOS7でのdocker(1.8.2)においては、コンテナのファイルが2GBを超えると、読み込めなくなるようだ。 mariadbにて、dumpファイルの取り込みまでは問題ないのだが、これを一旦停止し、再度立ち上げようとすると「27: File too large」というメッセージが出て起動できない。 ググってみたところ、どうもこのメッセージはMariaDBというよりもOSが出しているようだ。そのことに気づいてoverlayをdevicemapperに戻したところ、現象は発生しなくなった。 開発者サイドでも、まだoverlayは何が起こるかわからない、というスタンスらしいので、要注意。

<span title='2016-02-09 02:00:00 +0900 +0900'>February 9, 2016</span>&nbsp;·&nbsp;1 min&nbsp;·&nbsp;tack41