タイトルの通り。 Accessで、OLEDB経由でもAccessで直接クエリをたたいても「カレントレコードがありません」と表示されるエラーに遭遇し、SQLを切り分けたところ、Yes/No型のフィールドが原因と判明。 ググってみると、Yes/No型を外部結合してGroupByすると、Nullが発生した場合に処理できず、このようなエラーが出るらしい。 https://www.pcreview.co.uk/threads/no-current-record-error-in-group-by-query-with-outer-joins-solution.2126293/ 対処法は、リンク先にある通り、SELECT、GROUP BYの双方をNzでNullの場合の値を指定すること。 OLEDB接続の場合はNz関数が利用できないので、IIfとIsNullを組み合わせる。 Access嫌だ…
RTX1200でL2TP,IPSECによるVPN接続を行った。 iOS11(iPhone 7, iPad Pro 1st)では問題なく接続できるのだが、Android, Windows, Linux(Ubuntu)はことごとくダメだった。Windowsはそもそも保証対象外と明記されているらしいのだが、iOSがつながるのならAndroidもつながっても良いと思うのだが… Ubuntuの事例として、あわしろさんの記事を見つけたので、これを参考に再チャレンジしようと思う。
今日は有給をとって近くをドライブした。 Web+DBでYahooマップの記事があったので、ナビを使ってみようと思ったのだ。 そもそもにしてYahooマップとYahooナビは別アプリなのだが… 手持ちのNexus5Xで試した。アプリの機能としては問題ないと思うのだが… それよりもバッテリーのヘリが気になってしまう。充電しながら使っているのだが、それでも2,30分で10%は減る。これでは、そもそも長距離ドライブには使えない。ナビなんて長距離でしか使わないのに… で、会社で支給されているiPhone7にGoogle Mapを入れてナビを使ってみたところ、充電中は電池が減らないどころか、少しずつ充電されてる!!! iPhone使ってる人や、バッテリの持ちの良いAndroid使ってる人なら当然かもしれないが、その世界を知らない僕はふつうに驚いた。 やはり、Androidスマホと比較するとiPhoneは素晴らしいと。今回はバッテリーでその点に気付いたが、社内のスマホに関する障害の問い合わせもiPhoneよりAndroidの方が圧倒的に多い。 それも当然で、AndroidとiPhoneでは1機種にかける開発・保守費用が全然違う。Androidの代表としてGoogleのPixelを参照したとしても1桁どころか2,3桁は違うのではないだろうか。 ソフトウェアと違ってハードウェアはかけた金額が性能により効いてくると思う。正直Appleにばかり儲けさせるのは気に食わないという気持ちもあるが、価格以上の性能、信頼性があるのだと実感する。 この構造は、独禁法などで介入でもされない限り今後も当面変わらないのではないか。 今後は、Androidでしかないアプリがあるとか、ハードも含めてガンガンいじって開発したいとかでなければiPhoneを薦めたいと思う。公私ともに。 自分はAndroidが好きなので使うが、割り切って安いモデルを2年間使い倒すのが、今のAndroidには合っていると思われる。iPhoneのように長く使うには向いていない。
社内にて、NAS(Buffalo Terastation)、UPS(APC)の切替を行った。 社内の機器の監視はzabbixで行っており、これらの設定をする際、Zabbix Share のテンプレートが使えたのは非常にありがたかった。 Terastationは3.2用のテンプレートだったが、社内では3.0を運用しているためバージョンの指定を変更後、mokeblogさんのエントリを参考に不要なタグを削除してインポートした。 APCは2.0用だったが、バージョンの指定を変更するだけでインポートできた。(電圧上限、下弦の閾値は200V前提となっていたため、下限:190->90,上限250->120に修正した) これらのSNMP MIBを調べて設定するのは時間がかかるので、こういうのが公開されているのは時間がない管理者としてはありがたい。細かいところを自社に合わせて修正して利用しようと思う。
以下の要件で、ファイルサーバーの移行を行った。 移行元サーバー: Windows Server 2008 R2 (Enterprise) 移行先サーバー: Windows Server 2016 (Standard) 移行容量: 150GB程度 移行に使用した方法: Windows Server移行ツール 結果は、権限はNTFS、共有のものも含めて完璧に移行できた。移行後は既に公開設定が済んだ状態となっていた。 時間は8時間ちょっとかかった。複数の対象フォルダがあったため、Powershellでのバッチを作成して両方で動作させたため、つきっきりだったわけではない。 移行は2段階で行い、最初に10GBほどのフォルダの移行を行った。この移行では暗号化を行うのだが、これによるCPUの負荷が大きいことに気付き、2段階目ではCPUを2->4に増強した(共にHyper-V上のVM)。 2段階目において、Trend Micro Business Securityのスキャンが開始されたことに気付いたのだが、管理者権限で停止しようとしても受け付けてもらえず、結局アンインストールすることで停止するしかなかった。その間1.5時間ほどメモリ、ディスクIOがかなり高い状態だった。 上記の問題がなかったとしても6-7時間はかかったと思われる。容量に対してあまりに時間がかかりすぎている。同ツールでは移行後に権限だけ付け直す「-Include Share」オプションがあるようなので、robocopyでファイルだけ移行し、「-Include Share」オプションで権限を移行する方法が最も時間をかけずに確実に移行できたのではないかと思う。