サポート

V11アップグレードセミナー

ホーム » サポート » v11アップグレードセミナー
in

v11アップグレードセミナーは, 現在, 4D 2004/2003/6.8/6.7/6.5を使用しており, 4D v11 SQLへのアップグレードを控えている方々が対象です。アップグレードを実施する前に確認するべきこと, アップグレードの手順, 変換がうまくいかなかった場合の対処方法, 文字コードの問題, 新しいデータベースのパラメータ設定など, スムーズに移行を進めるために必要な知識と理解を得ることができます。

 

〜次回開催予定〜

 

このセミナーの定期開催は終了しました。

 

現在は内容の要約および関連資料を公開しています。

 

■手元に必要な資料を揃える

 

4Dは互換性を重視しており, 変換に伴う処理の大部分は自動化されていますが, 何の予備知識もなくアップグレードに臨むのは賢明ではありません。v11ではかなり大掛かりな設計見直しが施されています。正確な情報に通じていることがアップグレード成功の鍵です。

 

 

■必要なファイルを揃える

 

ダウンロードURLは, 最新版, 旧バージョン, Hotfixに分かれています。通常は最新版を使用するべきですが, 変換の際に4D Toolsや4D Insiderなど, 旧バージョンのソフトウェアが必要になることもあります。

 

 

■健全なストラクチャの必要性

 

変換が途中で失敗する場合, 恐らく変換前のストラクチャに問題が潜んでいます。4D Toolsなどの修復ツールを使用し, 事前にストラクチャを整えることが大切です。タグによる修復は, 他に方法がない場合を除き, 実行するべきではありません。

 

■カタログの役割と目的

 

変換後, 新しいストラクチャの隣にcatalog.xmlという名称のファイルが作成されます。このファイルには,　変換により割り振られたUUIDが記録されており, 同じストラクチャを複数回変換し, かつ, 同じUUIDを再利用したい場合に使用するものです。catalog.xmlを使用せずに同じストラクチャを変換すると, 新しいUUIDが割り振られ, UUIDの合致しないデータファイルが開けないので注意が必要です。

 

■非Unicodeモード

 

変換直後のストラクチャは, Unicodeモードが無効, つまり非Unicodeモードに設定されています。このモードでは, 文字列操作のコマンドがShift-JIS（Windows-31J）エンコーディングで実行されるため, 既存コードの大部分は特別な修正を必要としない利点がありますが, 下記のデメリットもあり, また将来的にはサポートがなくなることが決定しているので, 計画的にUnicodeモードへの移行を進める必要があります。

 

  • 文字コードの変換が頻繁に発生するためにパフォーマンスが低下する
  • 変換に失敗する文字は失われてしまう
  • 参照カウントが働かないために代入/引数/返り値/複製にメモリを使用する
  • 32,000バイト相当のサイズ制限がある

 

■Unicodeモード

 

Unicodeモードでは, 文字コードがUnicode（UTF-16のコードポイント）で扱われます。コードが別でも同等に扱われるべき文字に判別は, 以前のような変換テーブル（'TRIC'/'宜盟'）ではなく, ICU（International Components for Unicode）が使用されています。単純な比較には#や=などの演算子とワイルドカードの@で十分ですが, より正確な判別には正規表現が有用です。
 

 

■文字列コマンド

 

TEXT（Unicodeモード）に代入できるのは, UTF-16テキストだけです。バイナリデータなどのバイト配列（UTF-8を含む）は, すべてBLOBで処理するべきです。ただし, 一部の文字列操作コマンドは, アスタリスクを渡すことにより, 制御文字（キャラクターコードの0番など）を扱うことができます。

 

 

■Unicodeモードの混在

 

Unicodeモードと非Unicodeモードでは, TEXTのコンパイルされるオブジェクトが違うため, ランタイムでモードを切り替えたり, 異なるUnicodeモードのコンポーネントを混在させてコンパイルすることはできません。Unicodeモードの混在させるためには, POINTERを使用し, モードを超えたTEXTの受け渡しを回避することが必要です。

 

■CPU優先順位

 

環境設定に表示されるダイアログは, ３段階でプライオリティを設定することができますが, 時折, スライダーがグレーアウトされ, カスタム設定のチェックボックスが表示されている場合があります。そのような設定は, パフォーマンスを低下させる要因になるので, カスタム設定を解除し, 標準（中間）の設定に戻すべきです。プライオリティを高くしても, アイドル時に4DのCPU占有率が上昇するだけであまり意味がありません。プライオリティを中間にしても, ５個以上のプロセスが実行されていれば, 最高のプライオリティと同じ実行サイクルになります。

 

■タイムアウト

 

クライアントとサーバーのタイムアウトは, それぞれがリクエストを送信してからレスポンスを受信するまで待機する時間を設定するものです。具体的には, 相手アプリケーションが応答可能であることを確かめるために使用されています。これに対し, アイドル接続タイムアウトは, 最後にネットワーク通信が使用されてから経過した時間を計測するものであり, このタイムアウトを超過した場合は, 新しいネットワークソケットを確立, そうでない場合は以前のソケットを再利用するために使用されています。

 

  • サーバータイムアウト（データベース設定#13）
  • クライアントタイムアウト（データベース設定#14）
  • アイドル接続タイムアウト（データベース設定#54）

 

■フィールドとテーブルの削除

 

フィールドおよびテーブルは削除することができ, 欠番となった番号は新しく作成されたフィールドやテーブルにより再利用されます。削除したフィールドに登録されていたデータは, 圧縮するまでデータファイルに残っており, フィールドを再作成することにより復活させることができます。これに対し, 削除されたテーブルのデータをv11で復活させることはできません。

 

 

■トリガ

 

2004までのトリガは, 完了するまでデータベース全体をロックするアトミックなコンテキストで実行されていました。v11のトリガは, 対象テーブルだけをロックするように改良されているので, 複数のトリガが同時に実行される可能性を考慮する必要があります。2004までのトリガは, クライアントプロセスから全テーブルのカレントレコードとカレントセレクションを継承していました。v11のトリガは, 対象テーブルのカレントレコードとカレントセレクションだけを継承するように改良されているので, 必要なコンテキストは明示的に複製また同期する必要があります。新しいメソッドプロパティ「サーバーで実行」は, トリガが実行されるプロセスと同じプロセスで実行することを意味するものであり, このプロパティを使用してトリガのコンテキストを管理することができます。なお, トリガが実行されるプロセスはトリガの終了後も残っているので, レコードのアンロードなど, クリーンアップを忘れないようにすることが大切です。

 

■クエリのスピードアップ

 

新しいタイプのインデックスを導入し, クエリプランとクエリパスをチェックするようにすれば, データベースの設計をまったく変えずに検索と並び替えの速度を大幅に向上できる場合があります。

 

 

■リソースフォルダ

 

v11では, テキストやピクチャなど一般的データは, フォームに直貼りしたり, ピクチャライブラリなどに登録するのではなく, Resourcesフォルダに収録することが推奨されています。フォームに直貼りされたテキストは, Shift-JIS（Windows-31J）で保存されるため, 使用できる文字列に制限があり, 文字コード変換のドローバックがあります。フォームに直貼りされたピクチャは, 無駄なサイズを占有し, メモリを圧迫します。これに対し, Resourcesフォルダを使用することのメリットには次のようなものがあります。

 

  • テキスト（XLIFF）：Unicode文字がすべて使用できます。
  • テキスト（XLIFF）：言語の切り替えに対応することができます。
  • ピクチャ：参照カウントされるので, メモリ使用が効率的です。
  • ピクチャ：ネイティブフォーマットでフォームに表示され, クオリティが高く, GIFが動きます。

 

■式オブジェクト

 

v11では, フォームオブジェクトの「変数」に式を割り当てることができるようになりました。つまり, 変数名の代わりに値（文字列または数値）を返すコードをフォームオブジェクトにすることができ, 内容がフォーム上で随時アップデートされるようにすることができます。条件分岐はChooseコマンドにより表現することができます。この方法に活用すれば, プロジェクトメソッドの数を節約することができ, アプリケーションのメモリフットプリントを減らすことに役立ちます。

 

 

■キャッシュの設定

 

キャッシュのサイズは, 特別な理由がない限り, 動的キャッシュの計算をするではなく, 絶対値で入力するべきです。v11は, 32ビットアプリケーションなので, 2.5GB程度がキャッシュサイズの限界値です。もっとも, キャッシュサイズばかりに気を取られてはいけません。ボトルネックは別に存在する可能性があります。多数のクライアントが接続するサーバーのキャッシュは, プリエムプティブスレッドのデフォルトスタックサイズを抑えることにより, 余裕を持たせることができます。多数のシーケンシャル並び替えを実行するデータベースのキャッシュは, テンポラリメモリのサイズに上限を設けることにより, 余裕を持たせることができます。

 

  • プリエムプティブスレッドのデフォルトスタックサイズ（データベース設定#53）
  • テンポラリメモリの上限（データベース設定#61）

 

■いろいろなクエリ

 

フォーミュラによるクエリは, クライアントとサーバーの間で毎レコードを逐一送受信するため, パフォーマンスを落とすコマンドの代表格でした。v11のQUERY BY FORMULAは, フォーミュラをサーバーで実行するため, 一躍このコマンドは最強コマンドのひとつになりました。レコードの絞り込みは, QUERYの連結やQUERY SELECTIONで処理されるのが一般的でしたが, これらのコマンドはインデックスフィールドに対して使用した場合, （インデックスの性質上）実際にはレコードを絞り込むのではなく, セット演算を実行していました。v11では, QUERY SELECTION WITH ARRAYやQUERY SELECTION BY FORMULAでレコードの絞り込みを実行することができます。v11は, インデックスがあってもなくても, Find in fieldやリレーションコマンドが実行できます。実際, リレーションが設定されていなくても, QUERY BY FORMULAの新しい記法を使用することにより, その場でリレーションを定義（JOIN）することができます。

 

QUERY BY FORMULA

QUERY SELECTION BY FORMULA

QUERY SELECTION WITH ARRAY

 

■SQLがQUERYよりも望ましい場合

 

v11では, QUERYだけでなく, SQLでもデータベースのレコードを取り出すことができます。一般にQUERYのほうが実際的でパフォーマンスも優れていますが, 次のようなケースではSQLを使用したほうが良いといわれています。

 

  • 外部データベースにアクセスするとき
  • 新しいデータタイプ（float, Integer64bits）を使用したいとき
  • クエリの場合はループ処理にならざるを得ない検索条件（ループ処理は極力回避するべき）
  • エイリアス（同一テーブルの再帰的参照など）を使用したいとき
  • カレントセレクションを変えたくないとき

 

■トラブルシューティング

 

ログファイルを解析することにより, デバッガやランタイムエクスプローラーだけでは特定が難しい問題を突き止めることができる場合が少なくありません。

 

  • デバッグログ（データベース設定#34）
  • サーバーリクエストログ（データベース設定#28）
  • クライアントリクエストログ（データベース設定#45）

 

キャッシュは, さまざまな一時オブジェクトが置かれるメモリ領域です。確保されたメモリが使用後も解放されないこと（メモリーリーク）は, アプリケーションのクラッシュに至りかねません。キャッシュをフラッシュするコマンドにアスタリスクを渡すことにより, キャッシュを完全にパージ（未使用領域を強制的に解放）することができます。パージ後に残るメモリ（つまり使用中の領域）を監視することは, メモリーリーク調査のための有効な手段です。