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ブラックホール・1.8を、CDにプレスするべきか悩ましい。

ビジネスソフトであれば、リリース後も、どこかをたえずアップデートしてるもの。
いまや ほとんどのソフトウェアは、(CDなどから)インストールしたら、ただちに
「ネットワークアップデート」
するのが普通である。
ならばCDではなく、最初からネットワークで(ダウンロードして)インストールするのが常道だと思う。

ただ、一方で

  • 可搬型メモリ(USBメモリ等)の使用は禁止されているが、CDに関してはおとがめがない
  • ネットワークが外部接続していないので、CDからインストールできないと困る

という企業・団体もあって、そうなると CDになってないことが、完全にクリティカルになる。
以前(1.3)はCD-Rで その時点の最新の版を送付していたが、じつは その頃が一番 ユニバーサルに堅かったんじゃないかという気もする。

いまのところ、ISOイメージの頒布を考えているが、やはりCDメディアがあると
「買いました感」
もあって、わりとこれ無視できない感覚だから、いろいろ悩ましい。

正直、もうちょっと別のところにリソース配分することで、満足感を上げたいんだけど。(使用感や便利さとか)

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系列の終わりは もう少し先のことになるだろう。

ユーザーサポート, 手続き

ライセンスカードの紛失(亡失)では、こういうケースがよくある。

3年前にDAブラックホールを会社で購入して使っていたが、先日、パソコンが壊れてしまい、あたらしいパソコンに再インストールしようとしたが、プロダクトキーが見つからない。
当時の担当者は退職しており、ライセンスカードの所在も不明である。
購入したときの振込明細書は残っているので、会社宛てにライセンスカードを再発行してほしい。

その気持ちはわかる。
わかるし気の毒だと思うけど、再発行はできない。(例外あり※1)
控えがないので物理的に再発行ができない※2というのもあるが、それとは別に、根本的な理由がある。

市販ソフトウェアのライセンスでは、使用する「権利」を条件付きで得る。
その権利が移転可能であれば、手放した時点で、権利は移転・または消滅する。

銀行でお金を引き出して、それを使ったり失くしてしまったとき、引き出した銀行に戻って
「ここで引き出したのはまちがいないので、もう一度、お金をくれ」
という人は まずいない。

上記のケースでは、

  • 会社で買ったと思っていたが、役員が個人で買っていて、退職と同時にライセンスカード一式を持ち帰った
  • 事業がのれん分けになった際に、口頭で譲渡が決まり、ライセンスカード一式は引き渡されたが、インストールされたPCは そのままを残された
  • そもそも購入した事実がなく、振込明細書は別の製品だった

などなどの事例がある。
もちろん、それらは違法性のない(または小さな)「きれいな例」「かんちがい」であるが、担当者が退職時に意図的に売却したり廃棄処分したりというドロっとした話もないではない。

いずれにせよ当社としては、よその内部事情に関わることはできないので、
「ライセンスカードを持っている人に使用権があるので、失くしてしまうと使用権も失います」
という説明をする。

※1 購入から1年以内であればなんとかなることもある。
※2 ライセンスカードの控えは当社にはなく、あるのは不可逆にハッシュ化された暗号文がデータベースに載っている状態なので、聞かれてもわからない。

災害・盗難は別

ただし、災害・盗難のように 亡失理由が公的機関によって証明される場合は別である。
罹災証明書や盗難届の写し(遺失届や紛失届は不可)により失くしたことが証明できる場合は、一定の条件で「補助ライセンスカード」を作成し提供する。

「補助ライセンスカード」は記名式のため譲渡はできないが、失くしたライセンスカードがみつかるまでの間、使用することができる。

ライセンスカードを失くしたら使用できない?

ライセンスカードを失くすと、ライセンス認証ができないだけではなく、インストール済みのソフトウェアも使っちゃいけない状態になるソフトウェア許諾契約もあるけど、当社の場合は、みつかるまでの間は使ってよい。ただ、あらたなライセンス認証はできない。

使用権ではなく 使用資格にはできないのか?

担当者がぞんざいだと ライセンスカードを失くしたときに困る。
そこで ライセンスカードによる使用権ではなく、個人・法人への恒久的な使用資格にすることはできないか?という要望もある。

使用資格というわけではないが、ライセンスカードに記名(自署)すれば、それに近い効力が発生する。
すなわち、ライセンスカードの余白に

  • 個人ならフルネームで自署
  • 団体なら組織名・社印

をそれぞれ記述し、「譲渡無効」と書いておく。
そのライセンスカードの原本は厳重に保管し、担当者には記名後のモノクロコピーを渡しておけば、不正・紛失・盗難に対抗できる。
不正な転売や持ち出しが発覚したときは、原本を用いて失効させることもできる。

 

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 が原因名になっているので、テキストエディタで変更すれば、任意の文字列で表示されるようになる。