4Dのフィールドタイプ「UUID」は，GUIとランゲージにおいて文字列のように扱われますが，内部的には128ビット整数であり，データベースエンジンの検索も文字列ではなく整数値に対して実行されます。キャッシュに格納されるのも32文字の16進数（64バイト）ではなく，128ビットの整数（16バイト）です。
UUIDプライマリーキーのインデックス検索は最適化されており，まず，前半の64ビット値に対して検索が実行され，複数のレコードがヒットした場合には，後半の64ビット値に対して絞り込み検索が実行されます。UUIDの特性により，ほとんど場合，前半の検索だけで1件のレコードが特定されるため，UUIDプライマリーキーの検索速度は，実質的に64ビット整数型のプライマリーキーと遜色ありません。
v19r6以降，プロジェクトモードのチーム開発ができるようになりました。開発モードが有効にされている場合，クライアントはネットワークファイル共有システムを介してサーバー側のプロジェクトにアクセスすることになります。
開発モードのクライアントは，常にローカルのプロジェクトフォルダーを最新に保つため，更新されたファイルを特定し，必要に応じてリロードするようになっています。通常，この処理は瞬時に完了します。しかし，サーバーがWindowsの場合，macOSのSMBクライアントで開発モードのパフォーマンスが著しく低下することが観察されています。同じサーバーに接続しているWindowsのSMBクライアントでは問題ありません。パフォーマンスの低下は，メソッド数が300,000程度のプロジェクトで顕著です。
調査により，macOSのAPIから間違った情報が返されるため，大量のリロードが頻繁に発生していることがわかりました。問題を回避するため，macOSでプロジェクトモードのチーム開発をする場合，SMBではなく，NFSのファイル共有を使用することが勧められています。
4Dアプリケーションは，必要時にライセンス情報を更新するため，ライセンスサーバー（autoregistration.4d.com）にアクセスします。また，4Dサーバーアプリケーションは，統計情報を収集するため，週に1回，テレメトリサーバー（dcollector.4d.com）にアクセスします。統計情報の送信は任意ですが，ライセンス情報の更新がブロックされていると支障が生じることがあります。
運用中にライセンス情報を更新することにより，クライアント同時接続数などの追加ライセンスを有効化することができます。また，サブスクリプションであれば，新しいフィーチャーリリース（Rバージョン）が利用できるようになります。有効期限が設けられているライセンスの場合，有効期限の10日前から起動時にライセンスが延長されていないかどうかをチェックします。ライセンス画面の「更新」ボタンをクリックすることにより，あるいはRefresh licenseコマンドを実行することにより，任意のタイミングでライセンスサーバーをチェックすることができます。後者は，ヘッドレスモードで運用している場合，特に有用です。
上記のメカニズムにより，ライセンスサーバーにアクセスができるネットワーク設定であれば，サブスクリプション更新時にライセンスを再入力する必要はありません。
印刷コマンドでPDFまたはXPS形式のドキュメントを出力した場合，プリンターのように印刷ができない領域というものは存在しないため，SET PRINTABLE MARGINに-1（プリンターのマージン）や0（用紙マージン）の指定は無視されます。PDFまたはXPS形式のドキュメントがプリントプレビューとおなじようなレイアウトになることを望むのであれば，用紙およびプリンターを設定した後，GET PRINTABLE MARGINで理論マージンを取得し，SET PRINTABLE MARGINで出力に反映させる必要があります。
Microsoftの実装により，一部のWin32 APIは，プリンター名の31文字目以降を切り捨てるようです。従来のバージョンでは，この振る舞いを看過していましたが，Windows 24H2で発生するようになったMicrosoft Print to PDF印刷の不具合（ACI0105743）を調査する過程でエラー処置が強化されたことにより，特定のビルドではカレントプリンターの名称が30文字を超える場合に初回だけエラーが返されるようになりました（ACI0105792）。後者のエラーは，以前から潜在していた制限が修正の過程で浮かび上がったものであり，リグレッションではありません。
Windows版のMDIモードで最大化することができるのは，最前面ウィンドウだけです。最前面ではないウィンドウを最大化することはできません。これは仕様です。最前面であっても，フォームのサイズがプロパティで制限されているために最大化できない場合，そのウィンドウは最大化モードが解除された状態で表示されます。
アプリケーションをコンパイルせず，プリエンプティブモードのプロセスやワーカーを活用しなかった場合，すべてのメソッドは原則的にメインアプリケーションのコオペラティブスレッドで実行されます。つまり，複数のスレッドで同時に複数のプロセスが実行されるのではなく，メインアプリケーションのコオペラティブスレッドで少しずつ順番に実行されることになります。
コオペラティブモードでは，特定のプロセスが長時間にわたってCPUを独占するようなことを避け，プロセス同士でCPUを譲り合うことが重要です。たとえば，ループ処理中にDELAY PROCESSを呼び出すことができます。DELAY PROCESSが呼び出されると，一旦，スケジューラーに制御が返され，順番を待っている他のプロセスにメソッドを実行する機会が与えられます。プロセスを遅延することは望まず，単純に「息継ぎ」をしたい場合には，遅延時間に0を指定します。遅延時間に0を指定した場合であっても，必ずスケジューラーに制御返されるからです。
最近，新しいデータベースパラメーターUncooperative process threshold (132)が追加されました。このパラメーターはメインアプリケーションのコオペラティブスレッドを「独占」しているプロセスを特定するのに役立ちます。閾値（デフォルトは500㍉秒）を超えてプロセスがCPUを独占した場合，
Cooperative process doesn't yield enough
という警告が診断ログに出力されます。閾値はカスタマイズすることができます。また，このメッセージはエラーではなく警告なので，データベースパラメーターDiagnostic log level (86)でログレベルを「エラー」に設定することにより，抑制することができます。