データベースはOracle。一時作業用にParadoxを使用。
すべてのプロジェクトで同じようにいくとは限りません。たまたま、弊社で対応したものの記録です。少しは参考になると思います。
一時作業用（Paradox）のTTableのTADMemTable化を先にやります。
TTable
=>
TADMemTable
この後一度、IDEで開いておいたほうが良いです。
次に、オラクルアクセス用のコンポーネントの変換
DMDataBase.OraDBは、TADConnectionの名前です。
----------------------
TTable
＝＞
TADTable
Connection = DMDataBase.OraDB
＊
＊ SchemaNameを指定するとテーブルがないとエラーが出ることがある。この場合、 SchemaNameは削除する。
----------------------
TQuery
＝＞
TADQuery
Connection = DMDataBase.OraDB
----------------------
TUpdateSQL
＝＞
TADUpdateSQL
Connection = DMDataBase.OraDB
----------------------
各コンポーエントのDatabaseNameプロパティを削除しておいてもよいが、今回はそのまま残し、削除は、IDE任せで行った。
ADOコンポーネントの時のように、イベントが消えることもないのでそのあたりのフォローは少なくて済む。
TUpdateSQLも、TADUpdateSQLとして残るので助かる。
TADQueryの項目のDisplayLavelプロパティで、"#,#" はＮＧ（メモリ例外）。
”0,#”にするとＯＫなところがあった。(原因は不明)
以下は、データマッピング機能を使うと変換の必要がないのかもしれないが、今回は使用せず、また次回試すことにする。
----------------------
TFloatField
＝＞
TBCDField
Size = 0
----------------------
これはソース側。TADStoredProcのParamsの設定
AsInteger => value
AsDate => value
AsDateTime => value
----------------------
TADStoredProcで、IDE上で、StoreProcNameを再設定しないとパラメータ設定部分でエラーが出るものがいくつか発生（すべてでない）
StoreProcNameを一度クリアして、再設定してやるとうまく行くようになった。これも原因は今のところ不明。
TADQueryで、同様に、SQLを再設定してやらないと、上記と同様、パラメータ設定部分でエラーが出るものがいくつか発生（SoredProcより少ない）
これも、SQLを一度クリアして再設定で治った。こちらは、同一名のパラメータ名が複数あるときに起きるようだ。
＃
FireDACへの変換も一通りのテストはやはり必要なようで、ノンテストで置き換えられるコンポーネントはないものか。。。。無理かな？
numeric(12,2)
だと
NumericScale = 2
Precision = 12
Size = 0
が正しいようだ。--------------------------------------------------------------
FireDACの資料(日本語)は、これが一番まとめられていると思う。
２６回エンバカ・デブキャンプ資料
http://edn.embarcadero.com/article/images/43368/a2.pdf
