シングルユーザー版のアプリケーションをビルドしてWindowsのProgram Filesフォルダーにインストールした場合，初回のPHP Executeでエラーが返されるかもしれません。PHPを実行するためには，php.iniファイルを更新し，auto_prepend_fileに_4D_Execute_PHP.phpのパスを追加する必要がありますが，シングルユーザー版の場合，このファイルはアプリケーション内のResourcesフォルダーに作成されるため，ファイルの更新には管理者権限が必要です。エラーを回避するためには，コンテキストメニューを使用し，初回だけ管理者として実行することができます。
クライアント版アプリケーションの場合，Resourcesフォルダーはアプリケーション内ではなく，AppData内のクライアントデータベースフォルダーに作成されるため，php.iniファイルの更新に管理者権限は必要ありません。
DOM SET XML ELEMENT VALUEでXML要素値を設定した場合，"（クオート）および'（アポストロフィ）記号は" 'にエスケープされません。これは仕様です。
4Dが採用しているXMLライブラリ「xerces-c」は，SAXとDOMで別々のシリアライザーを実装しています。XML SET OPTIONSコマンドのXML String encodingをXML with escaping（デフォルト）に設定した場合，SAX APIのほうは，要素値の" 'も" 'にエスケープしますが，DOM APIは< > &だけをエスケープします。属性値は常にエスケープするべきなので，セレクター指定に左右されません。いずれにしても有効なXMLが出力されるようになっており，パーサーで解析することができます。
Windows 2012 R2でv18を使用した場合，SET CURRENT PRINTERでPDF Creator 1.7.3をカレントプリンターに設定できないことがあります。もちろん，PDF Creatorはインストールされており，PRINTERS LISTから返される配列にも含まれています。すべてのマシンで問題が再現するわけではありません。また，問題が発生するマシンでも，v15であれば，PDF Creatorをカレントプリンターに設定することができます。
原因は，Microsoft Office 2013アップデートに伴い，Visual Basicランタイム・COMインタフェースのタイプライブラリ・バージョンが変更されていることにあります。32-bit版は変更されていないため，問題がありません。
問題が発生する場合，Visual Basic 6.0のサービスパックをインストールすることにより，解消することができます。
https://www.microsoft.com/ja-JP/download/details.aspx?id=24417
特定の環境では，サービスパックのインストールに失敗するかもしれません。その場合，下記のコマンドラインを実行してみてください。
C:\WINDOWS\system32>%systemroot%/SysWoW64/regsvr32.exe %windir%/SysWoW64/msvbvm60.dll
情報源: 4D Forums
テキスト・ピクチャ・BLOB・オブジェクト型を総称してBLOBと呼ぶことがありますが，上限サイズはそれぞれ違います。テキストは，4GiBが4Dのメモリ管理によって扱える理論的な上限サイズであり，UTF-16コードポイント（文字）数でいえば，20億弱となります。オブジェクトの場合，テキスト型のプロパティには前述した制限が適用されますが，プロパティはいくらでも追加することができるので，単体としてのサイズは4Dのメモリ管理ではなく，システム側の制限によって上限サイズが決まります。ピクチャも，4Dではなくシステム側の制限によって上限サイズが決まりますが，ネットワーク・ファイル・レコード・シリアルポートなどを介してストリーム入出力する場合，ストリームのサイズ上限（2GiB）によって制約されます。WRITE PICTURE FILEコマンドでエクスポートするのであれば，ストリームの限界サイズには制約されません。
v16では，キャッシュマネージャーが新しくなりましたが，技術的な制約により，種別（BLOB・ピクチャ・テキスト）毎の合計サイズが2GiBと決まっていました。つまり，BLOBの合計2GiB，ピクチャの合計2GiB，テキストの合計2GiBが上限でした。たとえば，2GiBのBLOBを1個，あるいは200MiBのBLOBを10個まで作成することができます。
V18では，テキスト・ピクチャ・BLOB・オブジェクト型の変数，プロパティ，および「レコードの外」に保存されるフィールドそれぞれに2GiBまでデータを代入できるようになりました，たとえば，1GiBのBLOBを4個（BLOB合計で4GiB）作成することができます。「レコードの中」保存されるフィールドの場合，レコード1個の最大サイズが2GiBなので，他のフィールドとの合計で2GiBを超えることはできません。
これらの数値はいずれも設計上の理論的な最大サイズです。快適に管理できる最大サイズは，オペレーションシステムにも左右されます。たとえば，Windows Server 2016以前の場合，数百GiBのキャッシュをフラッシュするのにかなりの時間を要することが知られています。その点，Windows Server 2019と4D v18の組み合わせであれば，パフォーマンスが劇的に向上します。
ベータ公開されている18 R5では，エンティティセレクションの実装が変わり，デフォルトで共有オブジェクト版のエンティティセレクションが作成されるようになりました。共有エンティティセレクションは，新規プロセスまたはワーカーにパラメーターとして渡すことができます。
仕様の変更に伴い，query()やall()のようなメソッドから返されたエンティティセレクションに対してentitySelection.add()を使用した場合，エラー1637が返されることになりました。共有エンティティセレクションは，リードオンリーだからです。まず，エンティティセレクションをコピーし，共有オブジェクトではないエンティティセレクションを作成してから，エンティティを追加する必要があります。
仕様が変更されたのは，ORDAコーディングの特性に関する理解が進み，将来を見越した最適化が図られたためです。
注記: ベータ版の情報です。リリース版では仕様が変更される可能性があります。
大抵のORDAアプリケーションでは，エンティティセレクションを作成した後，or() minus() and()のような「セット演算」に使用したり，query() slice() orderBy() のような「フィルター」で絞り込んだりするようなロジックが一般的です。列挙したメソッドは，いずれも新規エンティティセレクションを返し，元のエンティティセレクションは変更しません。別の言い方をすれば，オブジェクトとしてのエンティティセレクションはミュータブル（変更不可）です。
たとえば
$es:=ds.Company.query(…).orderBy(…).minus(…)
というコードは，３段階にわたってエンティティセレクションを絞り込んでいますが，その都度，返されたエンティティセレクションに基づいて新しいエンティティセレクションを作成しているのであり，単一のエンティティセレクションを縮小しているわけではありません。ドット記法を連鎖せずに書き換えれば，その点が明確になります。
$es1:=ds.Company.query(…)
$es2:=$es1.orderBy(…)
$es3:=$es2:.minus(…)
このようなクエリ処理であれば，エンティティセレクションがリードオンリーであっても実行できることに注目してください。
add()は，元のエンティティセレクションを変更する例外的なメソッドです。ORDAでユーザーインタフェースを実装するような場合に使用します。リードオンリーのエンティティセレクションにエンティティを追加することはできないので，OB CopyあるいはentitySelection.copy()であらかじめ共有ではないエンティティセレクションを作成しておき，リストボックス等のデータソースに設定するのがポイントです。
Form.company:=ds.Company.query(…).copy()
Form.company.add(…)
Form.company.add(…)
つまり，18 R5以降，ユーザーインタフェースに表示するエンティティセレクション，特に内容を更新する可能性があるエンティティセレクションは，all()やquery()で作成した後，仕上げにcopy()を実行する，というコーディングになります。
エンティティセレクションを作成するコマンドは，いずれも共有オブジェクトを返しますが，Create entity selectionだけは例外です。このコマンドは，共有エンティティセレクションを作成し，その参照を返すわけではありません。そうではなく，クラシックコードで作成された既存のカレントセレクションに対するエンティティセレクション型の参照を作成し，その参照を返します。元となったカレントセレクションをREDUCE SELECTIONした場合，対応するエンティティセレクションもリサイズされるのはそのためです。
ドキュメントの記述は「新規エンティティセレクションを返します」となっていますが，前述したように，新規に作成されるのは，エンティティセレクション型のオブジェクトであり，エンティティセレクションそのものではありません。この振る舞いは，命名セレクションからカレントセレクションを「作成」するUSE NAMED SELECTIONに似ています。
エンティティセレクションは，オブジェクトの参照なので，変更不可ということに決めれば，実体の代わりに参照を複製するだけで済みます。100万件の順列なしエンティティセレクションの実体は，100キロビットのスペースを占有することがあります。順列ありのエンティティセレクションであれば，エンティティ1個につき，4バイトです。共有エンティティセレクションの参照であれば，エンティティ数に関係なく，サイズはわずか8バイトで済みます。
プロセス間で受け渡しができるといっても，すぐには共有エンティティセレクションの効果的な用途が思い浮かばないかもしれません。4D Remoteのクライアントであれば，DIALOGコマンドの*オプションやFormオブジェクトを活用することにより，アプリケーションプロセスだけでユーザーインタフェースを実装することができます。そのため，別プロセスにエンティティセレクションを渡して処理するようなことは限定的です（集計処理など）。
共有エンティティセレクションは，将来を見越した仕様です。現在，どのプロセスからでもアクセスできるStorageという共有オブジェクトがあり，プロセス間でオブジェクトを共有することができますが，同じように，Webリクエスト間で共有できるSessionオブジェクトの開発が進められています。これが実現すれば，Webリクエスト間でエンティティセレクションを共有できるようになります。Webクライアント（ブラウザ）は，ひとつのセッションで多数のプロセスを使用し，サーバーと非同期でプリエンプティブに通信するので，エンティティセレクションをコピーする代わりに参照を使用すれば，メモリとCPUの負担が大幅に軽減できる，と期待されています。
詳細は4D Forumsで読むことができます。