クラシック言語のQUERY BY FORMULAに相当するクエリをORDAで実行する場合，.query()のプレースホルダーとFormulaオブジェクトを使ってフォーミュラ引数を条件に使用したり，eval()ステートメントを使ってテキストでフォーミュラを記述したりすることができます。あるいは，検索条件そのものをフォーミュラで渡すこともできます。
ドキュメントに明記されているように，クエリ条件のフォーミュラはサーバー側で評価されます。
4D Server: クライアント/サーバーにおいては，フォーミュラはサーバー上で実行されます。このコンテキストにおいては，
querySettings.argsオブジェクトのみがフォーミュラに送信されます。
4D 20以降，サーバー側のデータモデルクラス関数がコンパイルモードでは常にプリエンプティブプロセスで実行されるようになりました。
クライアント/サーバーで動作するように設計されているプロジェクトでは、データモデルクラス関数のコードがスレッドセーフであることを確認してください。 スレッドセーフでないコードが呼び出された場合，実行時にエラーが発生します （シングルユーザーアプリケーションではコオペラティブ実行がサポートされているため，コンパイル時にはエラーが発生しません）。
4D 19では，シングルユーザーアプリケーションと同じように，呼び出し元のプロセスによってプリエンプティブまたはコオペラティブプロセスで実行されるという仕様でした。
.query()をクライアント側のプロセスがコオペラティブモードで実行されている場合，eval()やFormulaはそちらのメソッドに記述することになるため，コンパイル時にはスレッドセーフのチェックをすり抜けてしまい，サーバー側のプリエンプティブプロセスで当該メソッドを実行しようとした段階でランタイムエラーが返されることになります。クエリにフォーミュラを含める場合，そのフォーミュラがスレッドセーフであることをしっかり確認してください。
.query()の条件にフォーミュラを埋め込むよりも，クラスを拡張してメンバー関数を実装したほうがORDAらしいコーディングであるといえます。個別のメンバー関数に「プリエンプティブプロセスを使用」という属性はありませんが，スレッドアンセーフなコードはシンボルファイルまたはCompile projectのステータスオブジェクトで確認することができます。クラスを拡張してメンバー関数でサーバー側の処理を記述する場合，クラシック言語や既存のプロジェクトメソッドを混在させたりせず，プリエンプティブモードを前提にORDAでコーディングすることを心掛けると良いでしょう。
4D 20ではC_POINTER($test; 0)（第２引数が間違っている）のようなコードがランタイムエラーを返します。4D 19ではエラーが返されません。なお，どのバージョンでもコンパイル時にコードがシンタックスエラーとして検出されることはありません。宣言レベルでこのようなミスをキャッチするためには，C_@コマンドではなく，varシンタックスを使用することが勧められています。
Outlook アプリのプレビュー表示から4Dの入力エリアに添付ファイルを直接ドラッグ＆ドロップすることはできません。Pasteboard data size("com.4d.private.file.url")が-102を返すことからわかるように，ファイルがドロップされているわけではないからです。
コードライブチェッカーは，タイプ入力中（コピー＆ペーストを含む）にオブジェクト記法の整合性をチェックする新しい仕組みです。var宣言・property宣言・#DECLARE構文およびメンバー関数のプロトタイプ・コンポーネントの名前空間といった新しいシンタックスを十分に活用していれば，従来のシンタックスチェックでは検出できない，論理的な不整合がエラーまたは警告としてコーディング中に表示され，ミスを未然に防ぐことができます。
コンパイルまたはシンタックスチェックを実行すると，ライブチェッカーの警告は一旦クリアされます。enterキーでトークナイズを実行するか，メソッドの編集を再開すると，ライブチェッカーが発動し，警告が再表示されます。これは仕様です。
GET MEMORY STATISTICSとCache infoから返される情報，およびランタイムエラーに表示されている「使用中仮想メモリ」の値は，Windowsの場合，MEMORYSTATUSEX構造体のullTotalVirtualフィールドからullAvailVirtualを差し引いた値です。「仮想アドレス空間のユーザーモード部分で予約あるいはコミットされている仮想メモリの量」なので，厳密な意味で「使用中」ではないかもしれません（PowerShellのProcess.VirtualMemorySize64では，この値がAllocated memory と表現されています）。
Apple Siliconターゲットのコンパイル処理は，内部的にXcodeツールチェーンを使用しています。Xcodeが出力したエラーは，/DATA/Logs/build.txt ファイルに出力され，メッセージはコンパイラー画面にも表示されます。4Dアプリケーションをアップグレードした場合，コンパイラーが参照する内部リソースのタイムスタンプが一致しないなどの理由により，再コンパイル時にエラーが返されるかもしれません。あるいは，特定のメソッドを削除または再作成したことがコンパイラーに正しく認識されず，エラーが出力されることがあります。そのような場合，「コンパイルコードを削除」ボタンをクリックし，コンパイルをやり直してみてください。
フォームイベントのコンテキストで共有コンポーネントメソッドを実行した場合，Current form nameはホストプロジェクトのフォーム名を正しく返しますが，コンポーネントからフォームのプロパティ等に直接アクセスすることはできません。たとえば， FORM GET PROPERTIESを実行した場合，エラー81「フォームが見つかりません」が返されます。これは仕様です。Formula from stringと定数sk execute in host database を使用し，明示的にホストプロジェクトのコンテキストでフォーミュラを評価する必要があります。
collection.findIndex()は特定の条件に合致するコレクション要素をサーチするメンバー関数です。配列とは違い，コレクション型にはさまざまなタイプの値を収めることができるので，コレクション型のサーチは概してFind in arrayのようなコマンドよりも低速です。Find in arrayは，配列の各要素に対してCPUの比較命令を単純に実行するだけですが，コレクション型の各要素に対してフォーミュラを適用するためには，整数を比較するだけでも300以上のCPU命令を実行する必要があります。ランゲージにコレクション型と配列の両方が用意されているのはそのためです。柔軟で汎用的なコンテナが必要であればコレクション型，パフォーマンスを重視するのであれば配列型が適しています。