2015-12-15

マルチ認証ライセンスキーを使って Windows OS エディションをアップグレードする方法

 Windows OS のエディションをアップグレードしようとするとき、DISM コマンドを使うこともあると思いますが、マルチ認証ライセンスのプロダクトキー(MAK キー)で同操作を行うと失敗します。

 ここでは、アップグレードの失敗例をご紹介したあとで、その理由と、対処方法についてご紹介します。

 なお、本記事では Windows Server 2008 R2 を使っていますが、Windows Vista、 Windows 7、Windows 8/8.1、Windows Server 2008、Windows Server 2012/R2、Windows 10 のエディションアップグレード作業時にも参考にしていただけるとのではないかと思います。

注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 事前にアップグレード要件の検討を行い、必要に応じてバックアップをお取りいただき、お客様の責任で操作をお願いいたします。


絵で見る失敗例:マルチ認証ライセンスのプロダクトキーを使うと、Windows OS エディションのアップグレードができない


 コマンド プロンプトから 以下のコマンドを入力し、現在のエディションを確認します。
 
DISM /online /Get-CurrentEdition


 上図では、ServerStandard という文字列が返りますので、Standard であることがわかります。
 (実際に使用しているのは Windows Server 2008 R2 Standard エディションです。)

 次に、アップグレード可能なエディションの種類を確認します。

 以下のコマンドを入力ます。
 
DISM /online /Get-TargetEditions



 ServerDataCenter および ServerEnterprise にアップグレード可能なことがわかります。
 ここで、Enterprise にアップグレードする場合は、以下のようにコマンドを入力します。

 
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX



 しかしながら、ご覧のようにエラー 1605 とともに、「指定したプロダクト キーは、このターゲット エディションに対して有効なキーではありません。このターゲット エディション固有のプロダクト キーを指定して、このコマンドをもう一度実行してください。」というメッセージが表示されて失敗します。


原因:マルチ認証ライセンスのプロダクトキー(MAK キー)は、DISM コマンドには使えない


 MAK キーそのものは複数のエディションに対して共通のプロダクトキーとなっていますが、DISM コマンドは各エディションに固有のキーを要求するため、共通キーの MAK キーが使えません。

 これを回避するには、キー管理サービス(KMS)用のクライアントセットアップキーを使えば、一旦アップグレード操作は成功するようになります。

 KMS クライアントセットアップキーはこちらのページから入手できます。

 付録 A:KMS クライアント セットアップ キー

 一覧より、アップグレード対象のエディションのキーをコピーしておきます。
 お手持ちのマルチ認証ライセンスのプロダクトキーも後で必要になりますので保存しておきます。

KMS クライアントセットアップキーを使った Windows エディションのアップグレード


 コマンドラインより、DISM のアップグレードコマンドを入力し、/ProduktKey スイッチに KMS クライアントセットアップキーを入力します。

 
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX




 指定したエディションと、KMS クライアントセットアップキー が一致すると、プロダクトキーのインストールが行われます。

 その後、10分~程度待ち状態になります。
 既存のパッケージが削除された後に新しいパッケージが適用されます。
 下図は、Windows Server 2008 R2 Standard Edition が削除された後で、Enterprise Edition が適用された様子です。



 すべての操作が終わると、「今すぐコンピューターを再起動しますか(Y/N)?」というプロンプトが出ますので、Y を選択すると、即座にサーバが再起動されます。

 ※作業中のドキュメント等が開いている場合は、事前に保存しておくことを忘れないようにしましょう。

 起動後は、おなじみのアップグレード画面が表示されますので、完了するまで待ちます。



 アップグレードが完了したら、ログインして、コンピュータのプロパティでエディションを確認しましょう。
 下図では、Windows Server 2008 R2 Enterprise エディションにアップグレードされていますね。

 

 エディションが変わるため、Windows ライセンスの認証は解除された状態となりますので、別途認証作業が必要となります。

 「プロダクトキー の変更」リンクをクリックします。



 プロダクトキー入力ダイアログが表示されますので、お手持ちのマルチ認証ライセンスのプロダクトキー(MAK キー)を入力します。



 ライセンスが認証されたら、一連の操作は成功です。



 MAK キーを使うと、どうやってもエディションのアップグレードに失敗してしまう場合は参考にしていただければ幸いです。


参考リンク:
Features missing or incorrect memory reported after using dism /set-edition to upgrade computer (英語)
(dism /set-edition コマンドでコンピュータをアップグレードしようとすると、機能不足やメモリ割当が不正などのエラーが報告される)

KMS Client Setup Keys (英語)





2015-12-11

iSCSI を利用したFileMaker Server の冗長構成を考える

 先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

  1. プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
  2. 前回保存以降(0~99分間)のデータが失われる

 そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。 前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。


注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。


 前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。
iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する
iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
 ※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定:

 iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします(下図のEドライブ)。

 このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ(Eドライブ)に配置します。

 たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。



次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

 下図では、filewin:/E:/FmData/ が公開されるように設定しています。
 また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。




スタンバイサーバーの設定:

 プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
 プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

 ※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
 iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作


 普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態


緊急時の操作


 プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

 そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント:
 ― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

 ― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット(ディバイス)の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

 ― FileMaker Server 14 以前の FileMaker Server にも応用できます。


とっても重要:

 フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

 これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
 また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。






(亀)



2015-12-09

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する


 FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


 スタンバイサーバー - 概要


 プログレッシブバックアップを利用した現用系(プライマリ)と予備系(スタンバイ)のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

 しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

 今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン(VM)のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
 今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
 今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
 スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法


1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
 その後、Windows Server OS と FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント:
 ― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
 ― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



 このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
 上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除(切断)します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD)を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる
ポイント:
 ― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
 このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事:ドメインにログインできなくなって泣かされる

 ― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
  ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX 日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



 シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

 ― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法


1. プライマリサーバの公開済データベースを全部閉じます。



 コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

 接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
 このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント:
 ― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。


4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

 ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。


5. プライマリサーバのデータベースを再度公開します。


 すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。
 このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。



 スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法(メンテナンス時、障害発生時のサーバ切替)は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。



おまけ: FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法


 これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

 そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。


fmsadmin standby disconnect

 本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

 これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

(亀)

FileMaker バックアップ関連記事:

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事:

Hyper-V の仮想マシンの移行方法(エクスポート&インポート)
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る


2015-06-25

新WebDirectのパフォーマンスについてあれこれ

 FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか?実用に耐えるレベルになったのか?
 WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

 FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方(会社)もおいでで、そうした情報はとっても貴重です。

 ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。 (あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。)


米国 FileMaker 社(パートナー)が公開している YouTube ビデオ


 かの有名な  Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

 WebDirect関連のビデオでは 「第一部:FileMaker WebDirect 14 のご紹介」、「第二部:WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部:FileMaker WebDirect 14 のご紹介」 Introduction to FileMaker WebDirect 14


 WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント(リンクはタイムスタンプ):
  1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
  2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
  3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
  4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている
  5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている!(WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。)。
  6. 27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

(動画は英語)
 

 特に 15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見!
 ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部:WebDirect の最適化」 Optimaizing Solutions for FileMaker WebDirect 14 


 2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント(リンクはタイムスタンプ):
  1. 17:55 *.fp7 ファイルを  FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
    これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
    サイズが約半分ということは、転送速度が約2倍になっているといえる。
  2. 18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
  3. 19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、 約15% スリム化されていることがわかった。

(動画は英語)

  今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization (英語)をご覧いただくか、弊社記事 WebDirect 開発の勘どころ をご覧ください。

画像について 


 jpeg, png などの画像利用は最小限にする。
 FileMaker Pro 14 には軽量の SVG ビルトイン画像(glyph)が用意されているので、これを使ってボタンアイコンを装飾することを検討。
 ※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて


 タブ、スライドコントロールの使用もできるだけ避ける。
 必要のない情報をロードさせないのが基本。
 タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて


 FMP13 で導入されたポップオーバーも要注意。
 ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
 裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて


 WebDirect 側にはスクリプトエンジンが搭載されていない。
 このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
 当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
 このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」(PDF)にヒントが掲載されています。こちらも併せて読むと、参考になると思います。




土屋企画による WebDirect パフォーマンス検証

 

 小社でも『FMEasy在庫 IWP/WD R1.5』 という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外:米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内:自社サーバ(VM/占有タイプ)、4GB RAM/core i7(4プロセッサ割り当て)
FileMaker Server: Ver14.0.2(サーバ1/サーバ2共に)
使用ブラウザ:主としてIE10、IE11
注:VM=仮想マシン

■テスト内容
 予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト(後述)作っておき、5~10個のブラウザウインドウからこれらのスクリプトを実行しています。
 で、こんな感じになります。


 上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop (RDT)で複数のセッションを開き、それぞれのセッションで1~複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
 後述の「■テスト」の項では、<社内/1PC/複数ブラウザ>、<社外/複数RDT/1ブラウザ>などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2~1秒ポーズし、50~100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成(クライアントサイド)
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500(25明細×100)件、計2600のレコードが作成される。

4.連続伝票作成(サーバサイド)
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー <社外/1PC/複数ブラウザ>
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。


以下の動画は、撮影の都合上、6つのブラウザで実行しています。


2.連続更新
2-1  連続更新 <社外/1PC/複数ブラウザ>
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2 連続更新による影響  <社外/複数RDT/1ブラウザ>
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。 これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。
  • 6つのRDTの連続更新は時間はかかるもの成功します。
  • ローカルのブラウザでは入力は成功するものの 、レコード移動ボタン(>アイコン)を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。 


2-3 連続更新による影響  <社内/複数RDT/1ブラウザ >
上述の2-2 と同様テスト内容を 社内サーバで実行したときの模様です。

  • 今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
  • このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。 サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。 

2-4 連続更新を24セッションで実行 <社内/複数RDT/複数ブラウザ >
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて(計24セッション=4×5+4)て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成(クライアントサイド)  <社外/1PC/1ブラウザ>
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる(下図)。



4. .連続伝票作成(サーバサイド) <社外/1PC/1or 5ブラウザ>
1つのIE10ブラウザウインドウで数秒で成功。但し、実行直後から全くブラウザが反応(上図と同様)しなくなることがある
バグを修正したところ、上記打消し線部の問題は解消。 5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い


※ 今回のテストを通じて思ったこと ― WebDirect導入時の注意点

  1. 複数のブラウザでループスクリプトを実行しても(動作は遅くても)比較的に安定して動作する。
  2. ユーザが < や > (レコード間移動)ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 < や > を連続押しすると、この現象は高い頻度で発生する。
  3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる(サークルアイコンが出っ放し状態)になることがある。
  4. サーバサイドスクリプトが実行できる状況であれば、使う
上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。 ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして < あるい > をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
 尚、小社のLAN内のWebDirect環境では、ブラウザの > または <  ボタンを連続押ししても、上記の問題は発生していません。  

 以上のことから、WebDirect の導入に際しては、サーバ性能(メモリ/CPU)に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。 またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の < と > (ナビボタン)を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。 導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注:
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ?」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。 ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。



WebDirect のパフォーマンスに関するその他の情報


 バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです(公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが)。

 そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
 リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance


 NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
 こちらのスレッドでは、3 WebDirect ユーザ の場合は 100MB の RAM を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。 すばらしい! \(^o^)/

2. FMS 14 WebDirect Performance?


 WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10~20 秒後にログイン画面に戻ってしまうという現象が発生。

 ちなみに、当方でも同じ現象に遭遇したことがあります。
 ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
 また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。 早く出さんかいヽ(`Д´)ノ


(亀)

2015-06-23

WebDirectの導入事例を渉猟す

 WebDirect の導入に際してやはり気になるのは先行する導入事例。 
 小社でも時たま導入事例の紹介記事を探していますが、記事は多くありません。

 FileMaker 13 の WebDirect は、FileMaker Pro レイアウトのレンダリングが魅力的である反面、動作条件の厳しさ(高スペックなハードウェアの要求)、デザイン時に考慮すべき点の多さ、実行速度の問題など、機能的にはまだまだ発展途上という感じでした(これらの問題については、WebDirect 開発の勘どころ をご参照ください。)


 そんな折、2015年5月13日に FileMaker 14 が発売になりましたが、やはり WebDirect の進化に注目が集まるっているようですね。

 ということで、小社では改めてWebDirect(WD)の導入事例を探してみました。
 以下は見つかった記事の要約、編訳となります。 

※WebDirectが2013年12月にお目見えしてから1年半。まだまだ導入事例は少ない感じです。Ver14で状況は変わるのでしょうか。

【WebDirect の導入事例】

1. Braun Electric Company, Inc. (米国カリフォルニア州)


 電設会社。
 435人以上の従業員の安全を FileMaker Go for iPad/iPhone で管理。
 SeedCode 社の GoMaps プラグインを併用し、従業員の現在地を GoogleMap で確認。

 今後は複数の業務処理の自動化に向けて、WebDirect を導入していく“予定”とのこと(予定なんで、これ、全然導入事例ではないです。GoMapsがCoolそうなんで、思わず載せました。すみません)。

 参照元:http://www.filemaker.com/solutions/customers/stories/braun-electric-company.html 
 参考リンク: GoMaps プラグイン(英語)

2. Annex Medical, Inc. (米国ミネソタ州)


  医療用精密機器製造会社。
 従業員数 20人。
 社内のシステムを FileMaker Go for iPad でフル活用。
 品質記録、検品、工数管理、原料管理、在庫管理、配送、送り状作成までをトータルに行っている。

 作業効率化のためにダッシュボードをWebDirect で公開し、従業員の作業工数をチェックできるようになっている。 

 参照元:http://www.filemaker.com/solutions/customers/stories/annex-medical-inc.html

3. Cure Kids (ニュージーランド・オークランド)


 児童健康研究所。

 乳幼児突然死のリスク計算アプリを WebDirect メインで開発。

 データ入力を行うと、瞬時に死亡率のリスク計算ができるところがウリ。 
 開発期間が数週間だったにもかかわらず、ここ一年間で大きな修正はない。
 今後はカスタム開発を行い、ソリューションを完全レスポンシブな Web アプリケーションに発展させる予定(うーん、このWDソルーションはCWPソルーションに置き換わるのか。 WDで超高速開発して急場を凌だり、あるいはWDでプロトタイプを作成してエンドユーザに試用してもらう。で、本番システムはCWPで開発、みたいな)。

 参照元:http://www.teamdf.com/work/cure-kids
 開発元:http://www.teamdf.com/


【WebDirect 導入の具体例を示しているエンドユーザ】

1. Beko BBL (ドイツ・ケルン)


 プロバスケットボールリーグ。
 32 人の審判と 10 人のスタッフ監督で運用中。

 全国バスケットボールリーグの所属審判を WebDirect および FileMaker Go で管理。


 (動画はドイツ語)


 
 スケジュール、評価、目標達成度、その他要素を含むすべての関連データを iPhone またはiPad で審判に公開。
 審判は、どこにいても iPhone または iPad を使い、 WebDirect や FileMaker Go 経由でシステムにアクセスしてデータ入力可能。
 
 一元管理された目標達成やその他要素を含む情報は、リーグ管理者および審判が人選に利用。

 FileMaker プラットフォームで審判データベースを開発することにより、人材管理を実現。
 所在地情報をはじめ、年間出場試合数、身体データ、資格情報、関連情報、一般・技術審判の区分などを含む試合関連情報に関する個人データを管理。

 参照元:http://www.filemaker.com/de/solutions/customers/stories/bbl.html 

2. Akubra Hats (オーストラリア・ニューサウスウェールズ州)


 服飾品製造業。
 
 生産管理・受注管理に会計パッケージを統合させたシステムを FileMaker プラットフォームで開発。
 新たに導入されたレポート機能によって、季節ごとの商品在庫レベルを把握しやすくなり、在庫回転率が向上。
 早期受注にも対応でき、受注状況の確定も迅速化。

 システム導入後、一年間で受注レコード 2万件(受注明細レコード数 25万件、関連サイズ別レコードも含めると 56万件)を管理。
 工場および事務処理の一日 20 時間相当の業務をこのシステムで実現。
 今後のシステム最適化により、さらなる業務効率化が期待される。

 FileMaker Go と FileMaker WebDirect の併用により、モバイル顧客および遠隔顧客のニーズにも対応。
 また、2015 年の小売業者向けオンライン受注システム導入に向けて WebDirect によるモジュールをテスト運用中。


 参照元:http://www.filemaker.com/au/solutions/customers/local_stories/akubra-hats.html
 

3. サンラモン市街化区域(スペイン)


 都市開発事業。

 マドリードの民間開発区域、サンラモン市の 2000人の居住者を、18人の従業員により24時間体制で監視するシステムを運用。
 一日 3 シフト制でサンラモン市内を監視。
 訪問者・車両登録処理を含め、地域の安全を目指すのが基本目的。
 
 FileMaker Go および WebDirect によるアクセス。

 email を利用した居住者自宅訪問の実現。
 FileMaker Go for iPad を使ったレコード承認、訪問スケジュール管理
 WebDirect を使った居住者データベース管理
 
 より安全でシンプルな承認作業と堅牢なアクセス管理を実現。

 居住者に公開しているデータベースは二種類。
 居住者連絡先詳細データベースは地域事務所が WebDirect を使って更新。
 登録車両情報データベースは居住者自身が編集可能。

 訪問者がある場合は、e-mail または SMS で訪問者情報を監視員に送信。
 これにより 訪問者登録に要する時間を98% 削減。

 FileMaker Go for iPad による訪問者登録処理が可能になり、業務が簡略化されるとともにセキュリティログの記録量が 300% 増加。


 参照元:http://www.filemaker.com/es/solutions/customers/local_stories/Ciudad_San_Ramon.html



【WebDirect を使ったソリューションを提供している業者の開発例】

1. Contraflow (オーストラリア)


 道路交通網関連団体の計画作業と管理サービスを提供するシステムを構築。
 150人の従業員による内勤作業・オンサイト作業の両方に対応したあらゆる管理業務向けのソリューション。

 25 人の FileMaker Pro ユーザ、80人の FileMaker Go ユーザ、関連会社 5 社による WebDirect アクセスによりシステムを運用。

 【導入効果】
 コンプライアンスと安全性の向上、監査時不適合案件の減少、
 ワークフローのペーパーレス化。即時更新、各ステージの時間短縮、
 カオス化の完全排除、効率化されたプロセス、 自動 SMS 送信により電話による通話を廃止
 拠点呼び出しの時間と労力の削減、給与計算の自動化
 回転率の予測作業の迅速化と単純化、人員管理、必要車両とVIP 客の特定


参照元: http://info2.filemaker.com/Contraflow_Contraflow.html

2. SeedCode Calendar for WebDirect (米国)


 WebDirect 対応の FileMaker Pro 向けカレンダープラグイン。
 カレンダーの週間表示、月間表示、 テーマ切替、ガントチャート表示などに対応。

(動画は英語)



 その他詳細は SeedCode 社の製品ページをご参照ください。
 SeedCode Calendar for WebDirect



弊社でも FileMaker 13 版 WebDirect 対応の在庫管理テンプレート製品『FMEasy在庫IWP/WD R1.5』を販売しております。

FMEasy在庫 IWP/WD R1.5 製品紹介ページはこちら
 
この動画には WebDirect の動画部分は含まれていませんm( _ _ )m インスタントWeb(IWP)の動画となっております。 14も出たことだし、WD部分の動画も作ろうか、と思う今日この頃です。
  


(亀)

2015-05-15

ポートスキャン、リモートコード実行、VoIP 攻撃

 先日、連続ネットワークアクセスのログが大量に記録されました。

 こんな感じです。


IP アドレス: 1.20.150.223 (タイ)
ポートスキャン後、連続アクセス。

IPS Prevention Alert: WEB-ATTACKS bash Access, SID: 8920, Priority: Medium -  1.20.150.223, 5313

bash Access とあるので、bash シェルの脆弱性(Shellshock)を狙った攻撃のようです。
 Unix、Linux、Mac OS X をお使いの方は注意が必要ですね。

参考:
bashに存在する「Shellshock」脆弱性についての注意喚起

 そして、この Shellshock 狙いどおり、リモートコード実行試行が10分間で 5700 回以上の連続アクセスが記録されていました。
 攻撃先のポートが 80 (http) だったので、Web サーバ狙いでしょうね。

WEB-ATTACKS Web Application Remote Code Execution 45, SID: 5617, Priority: Medium - 1.20.150.223


IP アドレス: 212.83.136.198 (フランス)

 ポートスキャン後、 連続アクセス。
 過去のレポートを見ていると、先月末からもちょこちょこアクセスしている記録がありますし、この IP アドレスは以前から悪用が報告されているようです。
IPS Prevention Alert: VoIP-ATTACKS SIPVicious Activity 1, SID: 5616, Priority: Medium - 212.83.136.198, 5093

 VoIP で攻撃先のポートが SIP だったので、IP 通話関係の接続確立を試みたようです。



 みなさまもお気を付けください。




2015-04-14

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLを バックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。 
(FileMaker Pro 13使用時)

SET NAMES utf8 [参考URL]

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, future incoming messages from this client are in character set cp1251. It also specifies the character set that the server should use for sending results back to the client.

A SET NAMES 'charset_name' statement is equivalent to these three statements:
SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name; 

SET character_set_results = NULL [参考URL]


If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary:  

SET SQL_AUTO_IS_NULL = 0 [参考URL]

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:
SELECT * FROM tbl_name WHERE auto_col IS NULL
If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0  [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT  [参考URL]

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (232)–1 or (264)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT. 
※うちのDEFAULTは、 (264)–1=18446744073709551615 でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES' [参考URL]

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。


select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。


SELECT TABLE NAME ~ から SHOW KEYS ~ (イタリック部)は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル(ビュー含む)に対して実行される(キリッ


(土屋) 

2015-02-09

ハードディスクの不良ブロックとメーカーサポート


Windows Server 2008 のイベントログに、イベントID:7、「デバイス \Device\Harddisk0\DR0 に不良ブロックがあります。」が記録されていることに気づいた。普段はでないのだが、毎金曜の真夜中に開始されるフルバックアップを実行する度に出ていた。

ググると、CHKDSK /F を行えとか、ディスクのプロパティを選択して、 ツール→エラーチェック を行え、とか書いてある。 CHKDISK単独ならエラーは出ない。 が、パラメータに /F や /R を付けると、サーバ稼働中は実行できない旨のメッセージが出る。サーバなので、そう簡単には落すわけにはいかぬ。
ネット上には、ハードディスクに問題がある可能性があるので交換したほうが良い、という書き込みも散見された。

ということで、メーカーのDELLのサポートに電話をかけるとすぐに繋がる。 DELLはいろいろ言われているが、"サーバ"のサポートはいつも良い。 担当に現象を説明すると、原因を精査するには、以下の3つの方法(いずれもプログラム)があると言う。
  1. Server Asministrator
  2. DSET
  3. Diagnostics
上記1と3はサーバを一旦は停止しなければならないため、 「2.DSET」(ディーセット、と読むらしい)という診断プログラムを送付してもらい、実行した。終了すると、ZIPファイルが出来上がるので、それを返送する。
夜も更けてきても電話が来ないので、こちらから電話をしてみると別の担当者が出て、送ったファイルを見てもらう。と、即「ディスクに異常がある」とのこと(ふーん、そんな簡単に解るのか!?)で、ディスク交換となった。

なにが言いたいかというと、重要なハードはやはりハード屋に任せるのが良いということ。トラブル発生時、イベントログをチェックし、CHKDSK を行い、ググる、位までのところはなんとかなる。 そこで見当をつけてHDDやらの部品を調達して交換とかも、クライアント機であればなんとかなる。が、ダウンタイムを最小限にしなければならないサーバとなると、ソフト屋には厳しい。オンサイト契約料は高いがケチってはいけないと、今日だけは改めて思ったのだった。


後日談(15/4/14追記)
ハードディスクを交換してもらって10時間位かけてリビルド、しかし上記のエラーは解消されず。
サポートにDSETを再度送ると、「(RAID1の)ディスクが両方壊れている」という。ちょっと待った! いまさらそれは反則だ。もしそうなら、全部再インストールすることになる。 とりあえず、前回交換しなかったもう一方のドライブだけ交換してもらうことになったが、同時に不吉な記事を見つける。

Double Faults and Punctures in RAID Arrays


とっとも厭な予感。いい予感はあたったことはないが厭な予感はとっても良く当たる。
数日後メンテの人が来てもう一方のドライブを交換、当然リビルド=10時間。で、やっぱりエラーは解消されない。 結局、一旦Windows Server Backup を実行し、ディスクを初期化後にリストア。以後2か月強、このエラーは発生していない。


(土屋)


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2015-02-04

MySQL 5.1 から 5.6 にデータベースを移行する際、source コマンドを使うとエラーが発生することがある

MySQL 5.1 のデータベースのバックアップを取り、別のサーバ機の MySQL 5.6 にインストールする際、source コマンドを使ってデータベースの復元を行うと、以下のようなエラーが発生することがあります。

ERROR 1146 (42S02): Table 'test.蜃コ蠎ォ' doesn't exist

この文字化けしたテーブル名は日本語表記になっており、データベースの文字コードは utf8 です。

このような場合は、source コマンドの代わりに  mysql コマンドでデータベースの復旧を試みると解決することがあります。


例:
mysql -uroot -ppassword  < test.sql


【注意点】

mysql コマンドを使って大規模データベースを復旧する際、以下のようなエラーが発生して処理が停止してしまうことがあります。

MySQL server has gone away.

これを回避するには、 my.ini(my.conf) の max_allowed_packet の数値を増やします。

max_allowed_packet = 64M
(デフォルトは 4M)


2015-02-03

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one


The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:


Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.


  1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
  2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
  3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.


Common Model BTHM Remarks
Fast development Yes No
Ease of operation Good No so good
Performance for big tables Very poor Good
Weird behaviors Many Minimum
Records order Weird OK Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya