DAブラックホール, 日記

DAブラックホール1.8の主要 3機能が、おおむね完成。

いずれも旧版にあった機能だが、まったく新しく作り直した(後述)。
ただ、外観はできるだけ1.7を踏襲するよう努力した。
いまのところRC2までは、このUI(仕様)の予定。

インクルード(1.8/RC1)
インクルード(1.8/RC1)
ピンポイント(1.8/RC1)
ピンポイント(1.8/RC1)
シーケンサー(1.8/RC1)
シーケンサー(1.8/RC1)

なぜあたらしく作り直したか

これまで(~1.7)はインクルード/ピンポイント/シーケンサーが、単発解析(手動解析)を代行する扱いだった。ユーザーの代わりに解析ボタンを押してくれる機能と言っていい。このため「インターバル」も、解析と解析の間の「ウェイト」としての扱いだった。

しかし、1.8では1クライアントに最大12台のTA・通信端末が接続できるので、たとえば12個の電話番号が「どん!」と同時に解析されることもある。インクルードが、いきなり12個も進むといった具合だ。
そうすると従来の解析間「ウェイト」という考え方は、実態にそぐわない場合も出てくる。

ただウェイトっぽい機能は残しておきたい。

そこで導入したのが「周期」で、ほぼウェイトと同じ使い方ができる。内部技術的には、ここで定めた秒数毎に割り込みが入り、解析をリクエストする。
もしTA・通信端末がビジー、またはリクエスト上限にあるときは次の周期を待つ。

非なるものを似せるわけなので、インクルード/ピンポイント/シーケンサー すべて 作り直すことになった。

3大機能の同時使用ができる

これまで三大機能の同時使用は、
~1.6「解析順番が来たとき、ポートが空いていれば解析できないこともない(結果は保証しない)」
1.7「三大機能および外部データベース連結のいずれかが使用中の時は、他の代行機能は動作しない」
という仕様だったが、1.8では同時使用が可能になっている。
1.8には独立した解析ハンドラーが常駐し、適切にリクエストマネージメントを行っているためである。

マルチランゲージに対応

公式機能としてアナウンスするかはまだ決めていないが、マルチランゲージ対応している。

シーケンサー(1.8/RC1/英語設定)
シーケンサー(1.8/RC1/英語設定)

フォーム上の語句を、設定ファイル(実装上はレジストリの編集)で変更できるようにしている。
これはユーザーサポートに、日本語がネイティブでない方からの問い合わせが何度かあったので、それに合わせることにした。

なおこの機能を使って「1.7モード」にすることも可能だが、実際にその設定ファイル例を出すかは決めていない。

それにしても

1.8は「最後の大型アップバージョン」という前提で一から設計しなおしているので、将来の拡張性はまったく考慮しなくて済んでいる。このため各機能の洗練度(削り込み)っぷりが格段に高い。
2.0とネーミングしてもいい出来だが、1.x系列にほぼ完全な上位互換を持っており、フレームワークも安定したVB6ライブラリを使っているので、やはり 1.8 とするのが適切だろう。

当然、この1.8がDAブラックホールのシリーズ中、最高の出来になっていることは、自信を持って言える。

DAブラックホール, 日記

今週、Office365のオフラインインストール環境で、「外部データ連結」を介したxls/xlsxへの書き戻しに不具合が生じるという報告があった。

事象の概要

Office365のオフラインインストール環境(2013か2016かクイック実行形式かは不明)にインストールしたDAブラックホール1.7で、
「外部データ連結」を介したxls/xlsxの「読み取り」はできるし解析結果も表示されるけど「書き戻し」だけが反映されないにという不具合報告であった。

ふむ、2010に対する完全な後方互換ではないかもしれないねぇ → 2013/2016

そもそも Office 2013/2016 をクイック実行でインストールした環境では、ODBCドライバーが入っていないという問題があって。このことから、Office 2013/2016 は ODBC ドライバや OLEDBコンポーネントを自身では使っていない可能性が示唆されていたんだよね。
すなわち後方互換性のために、ODBC ドライバや OLEDBコンポーネントをパッケージしているにすぎないのではないか、という印象を持った。

ベンダーがこのあたりを使ってないなら、もしODBCやOLEDB周辺に潜在的な問題があったとしても、ベンダー側に認知されにくいのではないかと思ったのだわ。

DAブラックホールでは

DAブラックホール1.7は、どのバージョンのデータベースエンジンであっても「動けばそれでよい」という思想に基づいて、実装している。

プログラムでは、起動時に
dablack.accdb (DAブラックホールの解析結果保存ファイル)

Provider=Microsoft.ACE.OLEDB.12.0 (Microsoft ACE OLEDB)
で開き、
そこでエラーがスローされれば、必要な Office System Driver が入っていないと判断して、

データベースエンジンのインストールを求める表示(これは32bit環境のもの)

を表示する。

インストールメディアに同梱されている、AccessDatabaseEngine.exe は、Microsoft Access データベース エンジン 2010 再頒布可能コンポーネントの32bit版と同じものであり、通常はこれをインストールすることでDAブラックホール1.7が使用可能になる。
(※64bit環境では他の選択肢があることがサジェッションされる)

逆に言えば、Microsoft ACE OLEDB が使用できる状況であれば、DAブラックホール1.7はなんら案内を行うことなく起動する。データベースのバージョンは問わない。

このため、後方互換(上位互換)のデータベースエンジンが入っているときも、特に警告は出さないので、そのエンジンに問題があったとしても、ユーザーは気が付きにくいかもしれない。

データベースエンジン対応表

DAブラックホール1.7は Microsoft ACE OLEDB を使用するので、基本的には Office 2010 またはそのエンジンを用いるのが最もよい。

ただし環境や将来設計によって、32bitと64bitを使い分ける判断が必要になることもあるので、以下に対応表を示す。

 

環境条件 Windows 10,8,7,
Vista SP1,XP SP3
Windows Vista, XP SP2
MS Office2007/2010 をインストールしている 追加エンジン不要 追加エンジン不要
MS
Office2007/2010
のいずれもイン
ストールしてい
ない
OS は 32bit 2010 Office system ドライバ
AccessDatabaseEngine.exe
2007 Office system ドライバ
AccessDatabaseEngine.exe
OS は 64bit 2010 Office system ドライバ
AccessDatabaseEngine.exe
または
AccessDatabaseEngine_X64.
exe
2007/2010 以外
の Office をイン
ストールしてい
る ( またはその予
定がある )
32bit 版 2010 Office system ドライバ
AccessDatabaseEngine.exe
64bit 版 2010 Office system ドライバ
AccessDatabaseEngine_X64.
exe

赤字はメディアに同梱しているデータベースエンジン

Office 2013/2016で、もし問題が生じた場合は、Office 2010またはそのエンジン(2010 Office system ドライバ)をインストールする、という順序でもいいのではないかと思う。

DAブラックホール, ユーザーサポート

Windows7以降は「原則・電源を切らない」人が増えていると思うのだけど、Windows Updateなどで久しぶりに再起動してたら、DAブラックホールが 解析で「調査元エラー」を吐き出すようになっちゃったという事例報告を散見する。

  • アップデート後のWindowsに、通信端末のドライバーが対応していない(USB接続の場合)
    原因:ドライバーの不適合等により通信ができなくなっている
    確認:デバイスマネージャーで × になっているハードウェアに通信端末のドライバーが含まれていないか確認
    対策:通信端末のメーカーに問い合わせる。メーカーでも対応できないときは、システムの復元を使用してパソコンを以前の状態に戻す。
  • 再起動時にBluetoothが眠ったまま(Bluetooth接続の場合)
    原因:Bluetoothが立ち上がっていない
    確認:デバイスマネージャーで Bluetoothが起動しているか、またはコンピューターの管理→サービスでBluetoothのサービスが起動しているか確認
    対策:Bluetoothで通信できるようにする
  • DAブラックホールの設定がOSによって部分的に変更されている
    原因:Windowsは、OSの更新の際に、ソフトウェアが記録している重要情報(レジストリ)やハードウェア設定を変えてしまうことがある(Windows10で特に多い)
    対策:次項を参照

再起動時にハードウェア&ソフトウェアの設定が変わっているケース

OSの更新によって、ハードウェアの設定が初期化されるなどして、その影響がDAブラックホールの設定に及んでいることがある。

通信デバイスの設定
通信デバイスの設定(赤枠は 特に注意して見るところ)

その場合は、特に赤枠の部分に注意が必要で、中でも「汎用コントロール」のチェックが、入っていたり・あるいは入ってなかったりすることがある。

 

「汎用コントロール」とは、32bitOS用のシリアルポートコントロールのことで、1998年から用いられている歴史の長いコントロールだが、64bit環境で用いると通信機器によっては不具合が発生することがある。

そこでDAブラックホール1.7では、64bit環境でも不具合なく動作する自社製のコントローラーを内蔵しておりデフォルトでは自社製を使用するようになっている。(汎用コントロールのチェックはオフになっている)

ただ通信機器によっては32bit専用の「汎用コントロール」のほうが相性がよいケースもあるので、そのときには汎用コントロールを使うことになる。

再起動時にトラブルが生じているときには、これらの設定に勝手な変化がないか、確認しておくとよいかもしれない。

DAブラックホール

DAブラックホール1.7.29にアップデートした。

  • Improved デバイス試験に「ポート起動テスト」追加
    ユーザーさんで、そもそもシリアルポートドライバに異常があるケースがあったので、デバイス試験にポート起動テストを加えた
  • Improved 起動時のスプラッシュにバージョン情報を表示
    1.8系からのフィードバック。起動時のスプラッシュにバージョン情報が表示されると便利。
  • Changed 試用期間の制限を廃止
    インストール後・30日を経過すると、ライセンス認証を行わないとメインフォームが開かない制限があったが、これを廃止
  • Changed ライセンス認証フォームのキャンセルボタン廃止・閉じるボタンに変更
    [OK]ボタンの存在が、認証の際も「認証開始」「登録」のボタンまぎらわしかった。そこでOKボタン・キャンセルボタンを廃して、[閉じる]に統一した。
  • Fixed 起動時にイレギュラー終了すると、OSを再起動するまで起動できなくなるケースがある問題
    なんらかの理由で起動時にエラーが生じ、起動ができなかった際に、再起動すると「二重起動」とみなされ起動ができなくなることがあったので、修正。

DAブラックホール

当然のことに、なにを言っているのかわからない、という向きもあるかもしれないが、電話回線をIP化するとDAブラックホール(ISDN用)が使えなくなるという「問題」は、増えている。

事象

あるとき、DAブラックホール(1.3~1.7)をISDN回線で使うと、リザルトにx063などの「サービス利用不可クラス」ばかり返るようになり、意図した解析結果が得られない。

特徴

TAにNEC Atermシリーズを用いている場合は、リザルトに2063(自分側の局交換機)が返る。
リザルトが返るということで、ローカルインターフェースの切断・解放完了が行われていることがわかる。(すなわち機器の故障ではない)
解析タイムは100~300msと短く、局交換機(LN)が返したにしては、タイムが速すぎる。

対応

念のためDAブラックホールのメイン画面のスクリーンショットとデバイス試験データの作成をユーザーにお願いしている。これらに異常がない場合は、回線そのものに原因があると考える。

実例として最も多いのが、「事業所をひかりIP化した」というものである。
導入業者の事前説明で「ISDNがそのまま使える」と言われたから、というのもポイントになっている。

もちろん業者さんの説明不足である。IP用のゲートウェイ装置を間に入れて「ISDN機器の多くがそのまま使える」ということではあろうが、G4FAXやISDNデータ通信は 2017年現在、NTTのISDN網(PSTN/SS7)には抜けない。
例外的に支社のIP網からVPNを介して本社のISDN回線を使っているという方は知っているが、一般的とはいえない。

おそらくは請負契約書に「G4FAXやISDNデータ通信は除く」と免責事項が書かれているはずだから、工事したあとはどうにもならない。

あたらしくINSの回線を引きなおすか、他の回線種に変更せざるをえない。

ひとこと

ISDN機器とIP網の間に入れるゲートウェイ装置が、サービス利用不可クラスの生成源を 2(LN・ローカルユーザ収容公衆網)ではなく 1(LPN・ローカルユーザ収容私設網)で返してくれると わかりやすくなるんだけどね。

DAブラックホール, 日記

偶然重なったのかもしれないけれど、ここ数日で この「Windows ファイアウォールによりライセンス認証が行えない問題」が2件・サポート報告で上程された。
たまーに、ある。この事象。

事象の概要

オンラインによるライセンス認証機能を持つDAブラックホール1.5~1.7で、Windows ファイアウォールによりアプリケーションの通信がブロックされているときには、ライセンス認証が有効にならない、という現象が起きる。

まぁ、当然なんだけどね。

このときDAブラックホールは、「ライセンス認証が行えませんでした。」というクリティカルメッセージボックスを表示する。

厄介なのは、DAブラックホールにとっては「OS」が「正常に遮断」しているので、なんらOSのエラーを拾えないまま、しかし認証結果だけは返ってこないので、自動的な障害判定ができないことである。(ユーザーに対して、こういった原因で処理が行えませんでした、というサジェッションができない)

さらに厄介なことに、Windows ファイアウォール で レシーブだけカットするような設定であれば、当社サーバーは「正常に処理を行った」というログを残していくので、問い合せを受けた際の異常の検出に時間を要する。(細かく調べればわかるのだけど)

対応方法

サポートに問い合わせると、回答フローの最初のほうで

  • ルーターがHTTPS(TLS)通信を閉塞していませんか?
  • アプリケーションの外部通信に制約・遅延を与えるソフトウェアはありませんか?

と案内されるので、その時点でだいたいの人はピンとくる。(FWを設定するぐらいのユーザーであれば特に)

気がついてしまえば

コントロールパネル→Windows ファイアウォール→Windows ファイアウォールを介したアプリまたは機能を許可

で、DAブラックホールを許可してしまえばいいだけなんだけどね。

だけど、アプリケーション単位のFW設定なんて、安定して長いこと使ってるPCなら、設定していることを忘れることあるもので、そうなるとユーザーサポートへの問い合わせまでに、わりと長時間、ドはまりしてしまう方もいるかもしれない。
初心者ほど「ぱっ」と聞いちゃうものだが、もしFW設定を自らするような上級者であれば、問い合せまでに時間を要することもあるだろう。

特定プロトコルだけの閉塞または開放忘れを、クライアント側のアプリケーションだけで自動判定するのは荷が勝ちすぎているかもしれないが、これを機に、何か考えてみようと思う。

DAブラックホール

DAブラックホールは、

  • 販売期間3年
  • 耐用年数5年

で、企画・設計している。(各マイナーバージョンごとに)

企画は1年前にはじめるので、

「だいたい9~10年後まで使える設計思想」

を基本に開発がはじまる。
(企画開発1年+販売期間3年+終売ギリギリに買ってから5年)

販売終了後のサポート期間を原則1年に設定しているが、これは終売から5年持たせるための補強期間としての意味合いも含んでいる。

元となる考え方は、企業会計と税務における「ソフトウェアの原価償却期間」である。
製造元の原版の償却期間が3年であることはいうまでもなく、続編を作る前提であれば、3年ごとに新作を作っていくことになる。
一方利用者にとって、DAブラックホールは高くて6万円ぐらいなので、すでに持ってるPCにインストールして組み上げる個人事業者さんなら、経費か一括償却になっていると思う。
しかし、法人さんになるとシステムとして予算を組んで構成することもあるので、ソフトウェア部分については5年の耐用年数で定額法を採用している法人もあると思う。

このため、DAブラックホールの耐用年数は5年を想定することになる。
つまり企業会計上および税務上の減価償却期間によって、製品ライフサイクル(≒寿命)が決まっているともいえる。

旧製品の稼働期間は10年以上

では実際の寿命はどうだったかというと

  • DAブラックホール → 1.0への無償乗り換え
  • DAブラックホール1.0~1.3(1.4) → 1.5への無償乗り換え
  • DAブラックホール1.5(2007/3/15発売)→ サポート終了(2012/5/31) → 2017年現在 WindowsXPで動作中
  • DAブラックホール1.6(2011/6/1発売) → サポート終了(2015/3/31) → 2017年現在 WindowsXP/Vistaで動作中

という状況なので。
OSやDLLのサポート終了を無視すれば、ソフトウェア使用許諾上の観点からは、初代DAブラックホール(1997年製)を買った方でも、20年経過した現在 1.5にアップグレードして使用できているので、寿命は来ていない。

性能的な寿命は、1.6および1.5は現役稼働中の方が多く、1.3(SIP2.0を含む)についても、ライセンス認証のログを見ると、まだ継続認証をしている方が複数いらっしゃるので、稼働中といえるだろう。(11~16年経過)
おそらくSIP2.0は、PSTN網がなくなってもOSが動く限り実用に耐えうるんじゃなかろうか。

フロッピーディスク版の1.2は ログを見る限りでは、2011年ごろを最後に途絶えているようだが、こちらは約10年使用されたと推定している。

こういった状況から、
「耐用年数は5年」だけど「だいたい10年以上は使ってもらっている」
と考えており、
おおむね企画時の設計寿命は越えて稼働していると受け止めている。

1.x系列の将来像

DAブラックホールの販売計画については、買い替え(リプレース)需要サイクルを建て付けてはいないので、どのバージョンであっても、今後も 使えるいっぱい使ってほしいと思っている。

ただ、細かな部分やキャリアごとに、ムリがでてくる部分はある。使い続けてくれるユーザーさんにはそういった内外の要因変化を考慮してリプレース計画をたててほしいとも思っている。

たとえば、Windows2000環境を想定したバージョン(~1.3)では、事実上OSがTLSに対応していないので、すでにソフトウェア単体によるライセンス認証はできなくなっている。1.5にアップグレードしてWindowsXP/Vistaで用いることが推奨されている。
ただ1.5~1.6は、コード署名の期限が 2018 年 6 月 16 日なので、UACが作動するOSでは この日を過ぎると警告が表示されるようになる。
したがってDAブラックホール1.5および1.6を組み込み(またはラッピング)で使用している場合は、この日が限界ということになるかもしれない。

一方、キャリア情勢の変化も考慮しておく必要がある。
PHS勢の一角であったNTTパーソナルがサービス終了した際は、対象ユーザーについてDAブラックホール1.6への交換を、最低限の事務手数料¥2,000(当時)のみで行った。
2017年現在、旧ウィルコム・現ワイモバイルはPHSサービスの新規加入を2018年度には停止することを表明しているので、今後3~5年程度で停波する可能性がある。その場合は、同様の配慮措置を検討することにしている。

またNTT東西はPSTN網(アナログ/ISDN 各交換網)のIP網置き換えを2020年をめどに開始してゆくことを発表している。こちらについてはNTT側の技術的な課題が大きすぎるため、この目標には懐疑的な見方が少なくない。とはいえ将来のいずれかの時点でPSTN網が終了することはまちがいないと思われる。
その点においては、携帯電話の3Gサービスが いますこし長く生き残ると考えられるので、DAブラックホール1.x系列は、最終的に3Gに収れんされて、その役割を終えることになるのだろう、と考えている。
ただ1.8では、解析エンジンが独立しており、ユーザー自身で設計したエンジンを組み込めるようになっているので、独自にIP網用の改修を行う人も出てくるのではないかと思っている。そうなると、1.x系列の終わりは もう少し先のことになるだろう。

DAブラックホール, 手続き

DAブラックホールは、一定要件を満たせば(学生ライセンス等の特殊なライセンスを除けば)、譲渡可能なライセンスなので、ネットオークションやSNS、企業間での譲受・譲渡ができる。
ソフトウェア利用許諾契約では、弊社の承諾なく譲渡はできないことになっているが、一定要件を満たしてる場合は承諾しているのでOK

それぞれの取引について、ダイアモンドアプリコットは関知しないのだけれど、詐欺まがいな取引に引っかかって気の毒なことになっている例が散見されるので、デベロッパー(メーカー)として中古の当社ソフトウェアを譲り受けるときに必ずしておくべきことを助言として述べる。

相手からライセンスカード(原本)を受け取ること

ライセンスカード

譲り受けるときは、かならず「ライセンスカード(原本)」を受け取ること。
これがなければ、そのほかの物・たとえばインストールメディア(CD)や包装パッケージ、購入時の領収証などがあったとしても、それはゴミでしかない。

プロダクトキーをプリントした紙や、ライセンスカードをコピーした紙をもらったとしても、それらは「ライセンスカードの原本の提示」によって、いともたやすく無効化させられる。

実際に、プロダクトキーだけをネットで中古で購入したものの、その売主が、原本のライセンスカードを別の人に譲渡し、その買い取り先がプロダクトキーを無効化してしまって、大量のクライアントが失効してしまったという例もある。

ライセンスを譲り受けるときは、必ず事前に「ライセンスカード(原本)」の存在と有効性を相手に確かめ、その原本を受け取るようにしてほしい。
また、そのやりとりは保存しておくことが望ましい。

ユーザー登録を変更すること

ライセンスカードを受け取ったら、そこに書かれているプロダクトキーを使って、すみやかにユーザー登録(メールアドレス)を変更すること。ネットだけでできるし、無料である。
これをしないとサポートが受けられない。
当社のユーザー登録はメールアドレスだけで、名前や住所・電話番号等は不要であるから、かならず変更の手続きを行うようにしてほしい。

ユーザー(利用者)登録変更

https://customer.nda.jp/acs_out/mailnew.php

ライセンスカードを失効させ作り直す

元の持ち主の信頼性によるし、手数料もかかるので、これは「推奨」の範囲ではあるが、以下に述べる背景があるので「ライセンスカードを失効させ」「作り直すこと」については、よく検討してほしい。

ライセンスカードの原本が手元にあったとしても、元の持ち主がコピーを持っていて、それを誤ってライセンス認証に使ってしまったとする。
すると、あなたのPCにインストールされたDAブラックホールの認証が解除されることがあるのだ。(許諾クライアント数を超えてしまう場合などで)

あるいはライセンスカードの原本の譲渡を受けたときに、元の所有者の手元にもライセンス認証済みのクライアントが残っていたとする。
元の所有者がそのことに気づかず、そのクライアントを起動したら、タイミングによってはあなたのPCにインストールされているDAブラックホールの認証が解除されてしまうことがある。

いずれもソフトウェア使用許諾上の違反ではあるのだけど、故意か過失かの判断は客観的にはつかない。そこで ライセンスカードの原本保有者から求めがあった場合にだけ、プロバイダ責任制限法の手続きに準拠して解除原因となったIPアドレスを開示することにはしている。ただ、正規の所有者にとっては、かなりめんどくさい事態になっていることには違いない。

このような事故を防ぐには、譲り受けたライセンスカードを一度失効させ、別のプロダクトキーで作り直すことが有効である。

600円~からできるので、話し合いが難しそうな(連絡の取りにくい)相手からライセンスを譲り受けた場合は、ライセンスカードの作り直しを是非かんがえてほしい。
手続きはユーザーサポートで簡単に行える。

DAブラックホール

ソフトウェアで「最新版アップデート」を実施すると、現在の実行ファイル群はロールバック用のフォルダに保管され、サーバーから最新の実行ファイル群をダウンロードしてシステムの再構成が行われる。

この処理は daupdate.exe (Diamond Apricot Updater)が行っているが、この実行ファイルは
「ソフトウェアの復元」
の機能(GUI)がある。
この機能を使って、アップデートしたDAブラックホールを元に戻すことができる。

daupdate.exe

コマンドライン(CUI)での構文とパラメーターは次の通り。

構文

daupdate [<Source>][<Options>]

パラメーター

<Source> アップデートマニフェストのURL ※復元では使用しない
<Options> ※以下の表に示す

オプション 説明
/nr アップデート時にロールバックファイルを作らない
/restore 「ソフトウェアの復元」画面(GUI)を開く
/tmp=[ディレクトリ] ダウンロードするファイルの一時保管先
指定しない場合は daupdate のフォルダに一時フォルダを作成
/tv=実行ファイル名 アップデート終了後に実行する外部プログラムを指定
※daupdate.exe を 管理者権限で起動している場合にのみUACの制限を受けない

解説

  • Source を指定している場合は、ただちにアップデートを行う。取得したアップデートファイルは daupdate.exe のあるフォルダに展開される。
  • Source を省略し、Optionsに /restore を指定している場合は、「ソフトウェアの復元」画面が開かれる。
  • Source および Options の両方を省略した場合は、マニフェスト情報の入力画面が開かれる。

マニフェスト情報の入力画面では、コマンドラインで入力するパラメーターを入力することができるので、Windows のエクスプローラから 直接 daupdate.exe を実行して、後からパラメーターを入力することもできる。

使用例(GUI)

エクスプローラを使って、DAブラックホールのフォルダ内にある daupdate.exe をダブルクリックして起動する。

マニフェスト情報に /restore と入力する。

復元ポイントを選び [復元] を押す。

復元ポイントの確認が行われる。よければ [はい] を押す。

 

ここでいう「このポイントの直前の状態」という表現がひっかかるむきもあるかもしれない。
これは 復元ポイント(スナップショット)についた「原因名」に対して その原因を取り消しますよ、という意味だからだ。
たとえば、ここでは 1.7.27 と書かれているが、1.7.27に復元するという意味ではなく、
「1.7.27になる直前の状態にする」
ということである。
「ロールバック」は、かならずそれが作られた原因があり、その原因以前に復元するためにロールバックがあるので、「原因に対して ロールバックに戻しますよ」という理解をしてもらえるとよい。

実際、この操作を行うと ロールバックから復元されるとともに、「ソフトウェアの復元」操作に対する復元ポイントが作られる。
今回の復元を取り消すなら、今回作られた復元ポイントで復元すれば、今回の復元を取り消すことができる。

rollbackフォルダは消していいのか?

「最新版アップデート」や「ソフトウェアの復元」によって生成されるロールバックフォルダは、

rollbackYmdhis

というタイムフォーマット形式で生成される。

特に意図がなければ過去のロールバックフォルダは消しても問題ない。
むしろ、データベースエラーを復旧するための「再構築」のために最新版アップデートしているような場合は、大きなファイルがそのままストレージに残ってしまうこともあるので、不要になれば積極的に消去したほうがよいと考えられる。

復元ポイント名は変更できるのか?

復元ポイント名(原因名)は変更できる。
ロールバックフォルダの中にある description.txt が原因名になっているので、テキストエディタで変更すれば、任意の文字列で表示されるようになる。

DAブラックホール, 日記

エラーといえば、サポートに上がってくるDAブラックホールの「致命的なエラー」の上位2つが
データベースエラー
である。

  1. 「データベースの不具合があります。- n  サポートにご相談ください。」
    nには -2147467259 が入るケースが多い。その場合はデータベース損傷である。ファイルが壊れているため、システムを再起動したとしても改善することは少ない。
    破損の場所によっては、DAブラックホールの起動そのものができなくなることもある。
  2. 「解析結果のデータベース記録に異常が発生しました。( n ) 解析を中止しますか?」
    nには -2147024882 が入るケースが多い。その場合はメモリ不足またはストレージ不足(HDD/SSD)である。

この2つのエラーは、どちらか一方というよりは、「どっちが先に出やすいか」みたいなところがある。

背景と原因

2000年代前半のDAブラックホールでは、これらのエラーはよく出た。
Jetエンジンを使用していたということもあるが、解析結果の記録に必要なマシンリソースが足りなければ、容易にOSが処理を中断してアプリケーションを強制終了させていたからである。そうなると、何割かの頻度でデータベースファイルに不整合が生じ、結果としてファイルが開けなくなった。
あるいは、処理に必要なメモリが足りなくなって頻繁にスワップが生じ、タイムアウトして強制終了したときは、メモリ不足を表示した後、再起動すると、ファイルまで壊れている、開かないといった順序。
いずれも、必要な処理量に対してPCのマシンリソースが追い付いていないときに、よく起きていた。

これも、2000年代後半になると、PCの価格に対する性能(価格性能比)が向上してきて、標準的なPCであれば、データベースエラーはめったに起きなくなった。
起きたとすれば、旧式なPCでのリソース不足か、ノートPCの排熱不足などシビアコンディションにあるかのどちらかであることが大半だった。

ところが2015年以降から、じわりとではあるがデータベースエラーの報告が増え始めてきた。
当社では再現しない(もう起きない)ので、ユーザーのイベンログを送ってもらったところWindows (8/8.1)/10の Windows Update による強制再起動が原因のひとつとなっていた。

また、「SSDが原因」というケースも見受けられた。
データベースファイルの処理落ちを防ぐためにSSDを用いる、という この一見 優等生的な環境で起きていたのは「肥大したデータベースファイルの放置」によって、データのロード時にメインメモリが足りなくなりエラー停止、あるいはSSDの小柄な領域を圧迫していたということもあった。こちらは、どちらかというと完璧ゆえの油断といえるのかもしれない。


予防方法

Windows Update については防ぎようがないこともあるが、シビアコンディションについては予測や予防が可能であることが多い。

たとえばdablack.accdb のファイルサイズが メインメモリの1/2(半分)を超えないようにすると、ある程度 有効に防げることがわかっている。
とはいえども、いちいち監視はできないと思うので、数カ月から1年に1回程度、ファイルサイズを確認してメインメモリの1/2を超えていないか確認する、というペースで 多くの人は大丈夫なんじゃないかと思う。
もしオーバーしていた(またはオーバーに近づいていた)ときは、DAブラックホールと同時インストールされている
DABHREFL.exe
を使って、余分な領域を削ぎ落すといい。

復旧方法

もしDAブラックホールの起動ができるなら、最も容易な復旧方法は「最新版アップデート」で、データベースごとシステムを再構成することである。この方法であれば、もともとの解析データは
rollback*
というバックアップフォルダに入るので、Microsoft Office Access 2007 以上を用いて開くことができれば、解析データもムダにならないかもしれない。

もしDAブラックホールの起動ができない場合は、残念ながらアンイストール後に再インストールを行うのが一般的である。その際のインストールメディアは、当社ダウンロードサイトから取得した最新のインストーラーを用いることをおすすめする。(最新版で運用していたところに旧式のCDからインストールすると、環境によっては必要なファイルがインストールされないおそれがあるため)