XML形式のインポートプロジェクトファイル（.4SI）をコードで構築する場合，フィールド番号だけでなく，テーブル番号（table_no）も省略せずに指定する必要があります。テーブル番号が省略されている場合，正しくレコードがインポートできないかもしれません。32ビット版のエディターで作成されたプロジェクトは，テーブル番号が省略されていることがあります。そのような場合，プロジェクトを再作成することで問題を解消することができます。
GET BACKUP INFORMATIONコマンドにNext backup dateセレクターを渡すことにより，次回に予定されているバックアップの日時を取得することができますが，この情報はバックアップ完了後に更新されるものなので，データベースメソッドのOn Backup Shutdownで参照することはできません。これは仕様です。On Backup Shutdownは，バックアップ終了直前に発生するイベントですが，この時点ではまだバックアップ処理の途中であることに留意してください。
リストボックスの背景（CSSのfillプロパティ）が「なし」（CSSのtransparent）に設定されている場合，リストボックスそのものに背景がないため，メタ情報式やコマンドで行・列・セルに個別の背景色を設定することはできません。これは仕様です。
RESTサーバーを公開する場合，必ずOn REST Authenticationデータベースメソッドを実装するようにしてください。データベースメソッドがFalseを返せば，クライアント接続ライセンスが消費されることはありません。データベースメソッドで認証されたリクエストは，既存のセッションクッキーを再利用するので，新しい接続ライセンスを消費することはありません。
On REST Authenticationメソッドが実装されていない場合，すべてのリクエストは新規ゲストユーザーとなり，たちまちクライアント接続ライセンスが減ってしまいます（Denial of Service攻撃）。また，URLさえわかっていれば，どんなクラスメソッドでも自由に実行できてしまいます（セキュリティ問題）。
REST APIのライセンスは，Webサーバーではなく，クライアント/サーバーのビジネスモデルに準拠しています。
シングルユーザー版のアプリケーションをビルドして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の組み合わせであれば，パフォーマンスが劇的に向上します。