Windows版のシステムWebエリアはMicrosoftのレンダリングエンジンを使用しており，その挙動を踏襲します。コマンドのWA SET URL FILTERはナビゲーションをフィルターするコマンドですが，HTTPリクエストの送信をブロックすると保証されているわけではないことに留意してください。Microsoft Edge WebView2のドキュメントに述べられているとおり，NavigationStartingイベントでフラグをセットしてGETをキャンセルした場合，ページは遷移せず，ナビゲーションが中止されてNavigationCompletedイベントにステータスコードが返されますが，GETリクエストはすでに送信された後かもしれません。これは仕様です。
上下矢印キーでポップアップ/ドロップダウンメニューの項目をハイライト選択した後，escape キーで操作をキャンセルした場合，Windowsでは On Data Change イベントが発生します。macOSでは発生しません。これは仕様です。Win32 APIでは，上下矢印キーでメニューの項目をハイライト選択したタイミングで入力イベントが発生します。escape キーはメニューを閉じますが，それまでの操作が取り消されるわけではありません。
数値フォーマットを文字列に適用した場合，桁区切りや小数点は特別なプレースホルダーとして処理されません。たとえば12345678という数値に"####,####"というフォーマットを適用した場合，桁区切りにピリオドを使用するロケールでは1234.5678が返されますが，"12345678"という文字列に同じフォーマットを適用した場合，1234,5678が返されます。これは仕様です。
4D Writeや4D Viewのライセンスを保有している状態でCHANGE CURRENT USERを実行し，拡張ライセンスのアクセス権を持たないユーザーに切り替えた場合，自動的にライセンスが解放されるわけではありません。ライセンス数が同時接続ユーザー数よりも少ない場合，ユーザー＆グループのアクセス権を設定し，ログイン時にライセンスを配分することが必要です。必要なときにライセンスを使用し，用が済んだらライセンスを返却するといった運用はできません。これは仕様です。
特定のデータベース処理がボトルネックとなっているように思われる場合，クライアント側のリクエストログを活用できるかもしれません。このログファイルは，クライアントからサーバーに送信されたリクエスト情報が記録されています。
SET DATABASE PARAMETER(Client log recording;1)
リクエストログには，さまざまな事例に基づき，パフォーマンスと関係のあることが実証されている情報が記録されています。
v19の時点でリクエストログに含まれているのは下記の情報です。
| フィールド名 | 詳細 |
|---|---|
| sequence_number | オペレーション番号 |
| time | タイムスタンプ |
| systemID | システム識別子 |
| component | モジュール識別子 |
| process_info_index | プロセス識別子 |
| request | リクエスト識別子 |
| bytes_in | 受信バイト数 |
| bytes_out | 送信バイト数 |
| duration | オペレーション全体に要した時間 ms |
| server_duration | サーバーがリクエストの処理に要した時間 μs |
| write_duration | クライアントがリクエストの送信に要した時間 μs |
| task_kind | プリエンプティブスレッドかどうか |
| rtt | ネットワーク通信そのものに要した時間 μs |
リクエスト識別子のニーモニックはGitHubで公開されています。v20では14000番台にRESTリクエストが追加されました。
リクエストログのファイルサイズは，クライアント/サーバー間のネットワークトラフィックが妥当な範囲に収まっているかどうかのバロメーターとみなすことができます。
わずかなバイト数のリクエストが大量に送受信されている場合，通信の回数をもっと抑えるよう，プログラムを見直すことが必要かもしれません。
リクエストの処理に要した時間と通信そのものに要した時間を突き合わせることにより，通信設備やハードウェアのスペックが充分かどうかを見定めることができます。
コオペラティブスレッドのリクエストが相当な割合を占めている場合，プリエンプティブスレッドをもっと活用することでパフォーマンスを向上できる見込みがあります。
リクエストログはサーバー側で記録することもできます。
SET DATABASE PARAMETER(4D Server log recording;1)
v19r5 Hotfix 2では，サーバー側のリクエストログがテーブルに関わるものだった場合，extra項目にテーブル名が記録されるようになりました。
| - | - | - | - | - | - | - | - | - | - | - | - | extra |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 60 | - | - | ‘srv4’ | 5 | 71 | 11 | 4 | 1127 | 34 | c | 1000 | |
| 61 | - | - | ‘INFO’ | 5 | TTF/i | 0 | ||||||
| 62 | - | - | ‘dbmg’ | 5 | 11041 | 362 | 62 | 1132 | 65 | c | 1000 | Table_1 |
上記の例では，[Table_1]のトリガがコオペレティブモードで実行されていることが確認できます。
リクエストログは，クライアント/サーバーのネットワーク通信に焦点をあてたログファイルです。4Dには，他にもさまざまなデバッグツールが用意されています。
公式サイトのダウンロードページには，簡潔な最小動作環境およびソフトウェアとハードウェアの必要環境の詳細のURLが掲載されています。ハードウェアについては，クライアントは2コア以上，サーバーは4コア以上のCPUを搭載しているコンピューターが推奨されています。
Client computers must have a minimum of a 2 core CPU, while servers should have 4 or more cores.
推奨されているCPUコア数やメモリの容量はひとつの目安です。実際には同時接続ユーザー数・アプリケーション設計・データファイルのサイズといった要素を考慮に含める必要があります。
クライアントのコア数として2が推奨されている背景には，アンチウイルスなどのセキュリティソフトの存在が関係しています。多くの企業では，損害保険上の必要事項としてセキュリティソフトをインストールすることが要求されていますが，大抵の場合，バックグラウンドで動作するそのようなソフトはCPUコア1個をほぼ占有するので，4Dを快適に使用するためには少なくとも2個のCPUコアが望ましいと考えられています。
アプリケーションの設定やプロセス処理の方法にもよりますが，4D Serverは，ORDA・DB4D・HTTP・SOAP・SQLなどリクエストをプリエンプティブモードで並行処理することができるので，4コア以上が推奨されています。
v19r7以降，Webサーバーにアクセスするとステータスコード429 Too many requestsが返されることがあります。これは，Webサーバーを外部に公開するライセンスがインストールされていない場合に返されるエラーです。
v19r3以降，4Dには，OAuth2認証を容易にする4D Netkitコンポーネントがプリインストールされています。OAuth2認証は，Microsoft 365のようなWebサービスで採用されています。Microsoft 365の場合，POP3やIMAPプロトコルの 基本認証が廃止されたことに伴い，ユーザー名とパスワードによるログインができなくなりました。
OAuth2認証をするためには，Webサービスのプロバイダーからトークンと呼ばれる情報を受信するためにWebサーバーを開始する必要があります。4D Netkitも例外ではなく，OAuthトークンを受信するためにコンポーネントのWebサーバーを利用しています。クライアント側でOAuth2認証するためには，クライアント側のWebサーバーを使用します。
v19r7以降，4D NetKitでWebサービスのOAuth2認証ができるようにするため，Webサーバーを外部に公開するライセンスがインストールされていなくても，1分間に数回の制限内でHTTPリクエストが処理できるよう，仕様が見直されています。この状況でWebサーバーを外部に公開することはライセンスで許可されていません。限度を超えたリクエストを受け付けた場合，サーバーはステータスコード429 Too many requestsを返します。