Pervasive⇒SQLServerへの移行
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
ara
投稿数: 122
投稿数: 122
このたびMagicV8のシステムをxpaにバージョンアップすることになりました。これに伴ってDBも、Pervasivev8からSQLServer2012に移行の予定です。
そもそもMAGICでSQLServerの利用が初めてなので不安もありますが、ひとまず下記2点質問させていただきます。
��PervasiveデータをSQLServer側に移行するには、MAGICでコンバート用のPGを作成することになるのでしょうか？
それとも何かコンバート用の便利なツールがあったりするでしょうか？
��PervasiveからSQLServerへの移行に伴う注意事項（テーブル設計、項目設計、プログラミング等）があればご教授いただけないでしょうか。
以上、どうぞよろしくお願い致します。
そもそもMAGICでSQLServerの利用が初めてなので不安もありますが、ひとまず下記2点質問させていただきます。
��PervasiveデータをSQLServer側に移行するには、MAGICでコンバート用のPGを作成することになるのでしょうか？
それとも何かコンバート用の便利なツールがあったりするでしょうか？
��PervasiveからSQLServerへの移行に伴う注意事項（テーブル設計、項目設計、プログラミング等）があればご教授いただけないでしょうか。
以上、どうぞよろしくお願い致します。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
データリポジトリの「データベース」欄をPervasive用のデータベース
からSQLServer用のデータベースに変更すれば、あとはMagicが
自動でコンバートしてくれますよ。
からSQLServer用のデータベースに変更すれば、あとはMagicが
自動でコンバートしてくれますよ。
投票数:0
平均点:0.00
ara
投稿数: 122
投稿数: 122
Tanda様
レスありがとうございます。
Magicが自動コンバートしてくれるんですか？！
それは知りませんでした。
SQLServer側にテーブルクリエイトも自動でやってくれるんでしょうか？まだ開発環境がないのでご質問させていただきます。
レスありがとうございます。
Magicが自動コンバートしてくれるんですか？！
それは知りませんでした。
SQLServer側にテーブルクリエイトも自動でやってくれるんでしょうか？まだ開発環境がないのでご質問させていただきます。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
全部、自動です。
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
居住地: 大阪
投稿数: 775
丹田さん こんにちは Ｐｕです。
テーブルリポジトリをPervasive==>SQLserverへ変更するだけで
ほんとうに全自動で全て変換（ＡＰＬも含めて）してくれるんでしょうか？
本当なら素晴らしいです（私も知りませんでした）
そこで疑問なんですが
PervasiveとSQLserverではカラムの名前の制限事項は異なりますよね
それとプライマリーkeyの名前もＤＢ内で重複してはいけません
データベースデフォルト値は？
nullの許可等
それとトランザクション
上記まで全て全自動で行ってくれるのなら
あの遅いPVSからすぐにSQLへマイグレーションしたいです
でわ〜でわ〜
テーブルリポジトリをPervasive==>SQLserverへ変更するだけで
ほんとうに全自動で全て変換（ＡＰＬも含めて）してくれるんでしょうか？
本当なら素晴らしいです（私も知りませんでした）
そこで疑問なんですが
PervasiveとSQLserverではカラムの名前の制限事項は異なりますよね
それとプライマリーkeyの名前もＤＢ内で重複してはいけません
データベースデフォルト値は？
nullの許可等
それとトランザクション
上記まで全て全自動で行ってくれるのなら
あの遅いPVSからすぐにSQLへマイグレーションしたいです
でわ〜でわ〜
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
Puさん、
はい、データリポジトリの「データベース」欄をPervasiveからSQLServer
に変更するだけで、あとはコンバータが自動的に起動して、すべての
変換処理を全自動でやってくれます。
レコード件数が少なければ、一瞬で終わります。レコード件数が多くても、
時間は掛かりますが、全自動です。
この機能は、もう何10年も前から同じですよ。Magicが「マジック」たる
ユエンですね。すばらしいです。
はい、データリポジトリの「データベース」欄をPervasiveからSQLServer
に変更するだけで、あとはコンバータが自動的に起動して、すべての
変換処理を全自動でやってくれます。
レコード件数が少なければ、一瞬で終わります。レコード件数が多くても、
時間は掛かりますが、全自動です。
この機能は、もう何10年も前から同じですよ。Magicが「マジック」たる
ユエンですね。すばらしいです。
投票数:0
平均点:0.00
Kurogane
投稿数: 50
投稿数: 50
Puさん、こんにちは。
テーブルに重複不可キーがなければ、MAGICがその旨をエラーで
知らせてくれます。
DBを切り替える際に、モデル辞書側の設定を見直して上記の設定を
引き継いだ形となるので、モデルさえ正しく設定されていれば、
丹田さんの言う通り、データソースのみの変更でいけます。
逆にテーブルのカラムにモデルを指定していない場合は、個別に
修正が必要かと思われます。
テーブルに重複不可キーがなければ、MAGICがその旨をエラーで
知らせてくれます。
DBを切り替える際に、モデル辞書側の設定を見直して上記の設定を
引き継いだ形となるので、モデルさえ正しく設定されていれば、
丹田さんの言う通り、データソースのみの変更でいけます。
逆にテーブルのカラムにモデルを指定していない場合は、個別に
修正が必要かと思われます。
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
居住地: 大阪
投稿数: 775
皆さん ご回答ありがとうございます。
まず知りたいのはカラム名です
PVSの場合ほとんどの列名が使用できますが
SQLの場合予約語や記号などでDBカラム名でひっかからないのか？
KEYの名前を どのテーブルもKEYと言う名前でも
PVSは問題ないが
SQLに変換した場合KEY名はどう変換されるのか
この辺が解決されれば 試してみようと思います。
でわ〜でわ〜
まず知りたいのはカラム名です
PVSの場合ほとんどの列名が使用できますが
SQLの場合予約語や記号などでDBカラム名でひっかからないのか？
KEYの名前を どのテーブルもKEYと言う名前でも
PVSは問題ないが
SQLに変換した場合KEY名はどう変換されるのか
この辺が解決されれば 試してみようと思います。
でわ〜でわ〜
投票数:0
平均点:0.00
Kurogane
投稿数: 50
投稿数: 50
Puさん、こんにちは。
カラム名はデフォルトだとMAGIC上の名称を引き継ぎますが、
予約語や記号があってもそのまま引き継ぎますので、エラーに
なるかと思われます。
インデックスについても、KEY名はそのまま引き継がれます。
デフォルトだとPK扱いにはならないので、テーブル間で名前が
重複していても問題ありません。
弊社ではカラム名、インデックス名のどちらも予約語やアンダー
バー以外の記号が使われていないことを事前に確認してから変更
しました。
カラム名はデフォルトだとMAGIC上の名称を引き継ぎますが、
予約語や記号があってもそのまま引き継ぎますので、エラーに
なるかと思われます。
インデックスについても、KEY名はそのまま引き継がれます。
デフォルトだとPK扱いにはならないので、テーブル間で名前が
重複していても問題ありません。
弊社ではカラム名、インデックス名のどちらも予約語やアンダー
バー以外の記号が使われていないことを事前に確認してから変更
しました。
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
居住地: 大阪
投稿数: 775
Kuroganeさん
貴重な情報ありがとうございます。
新規作成はほとんどSQLなんですが
マイグレーションでPVS==>SQLはやった事なかったんで
少し安心しました。
でわ〜でわ〜
貴重な情報ありがとうございます。
新規作成はほとんどSQLなんですが
マイグレーションでPVS==>SQLはやった事なかったんで
少し安心しました。
でわ〜でわ〜
投票数:0
平均点:0.00
ara
投稿数: 122
投稿数: 122
お世話になります。
遅くなりましたが、Pervasive→SQLServer（バージョンは2012）への移行に取り掛かり始めました。
自動コンバートすごいですね。ちょっと感激です。
MAGICでは初めてSQLServerを扱うので不慣れなのですが、コンバートしてみたマスタを使用しているPGを動かしてみました。
テーブルコントロールに一覧形式でデータ表示させるという、単純なPGです。
このPGを実行してみたところ、Pervasiveでやっていた時よりも、カーソルの動きが遅く感じました。試にデータリポジトリからAPGで実行させたところ、これまで通りさくさくと動きました。
先頭レコードから最終レコードに到達するまで、下矢印キーを押し続けたところ、APG画面では8秒程度であったのに、作成したPGでは30秒ほどかかりました。とくに範囲指示などはせず全件表示させているのですが…。
SQLServerの移行とともに、PG側でチューニングしないといけない箇所があるんでしょうか。
何かアドバイスいただけたら幸いです。
よろしくお願い致します。
遅くなりましたが、Pervasive→SQLServer（バージョンは2012）への移行に取り掛かり始めました。
自動コンバートすごいですね。ちょっと感激です。
MAGICでは初めてSQLServerを扱うので不慣れなのですが、コンバートしてみたマスタを使用しているPGを動かしてみました。
テーブルコントロールに一覧形式でデータ表示させるという、単純なPGです。
このPGを実行してみたところ、Pervasiveでやっていた時よりも、カーソルの動きが遅く感じました。試にデータリポジトリからAPGで実行させたところ、これまで通りさくさくと動きました。
先頭レコードから最終レコードに到達するまで、下矢印キーを押し続けたところ、APG画面では8秒程度であったのに、作成したPGでは30秒ほどかかりました。とくに範囲指示などはせず全件表示させているのですが…。
SQLServerの移行とともに、PG側でチューニングしないといけない箇所があるんでしょうか。
何かアドバイスいただけたら幸いです。
よろしくお願い致します。
投票数:0
平均点:0.00
nkmt
投稿数: 1668
投稿数: 1668
データベース特性の中の
テーブルの存在チェック を外すと
速度が向上するかもしれません。
速度向上のメリットもありますが、SQLのデータの新規生成を
してくれなくなるデメリットもあります。^^;
実運用ではメリットの方が大きいと思います。
テーブルの存在チェック については当フォーラムでも
何度か出てますので、そちらもご覧下さい。
テーブルの存在チェック を外すと
速度が向上するかもしれません。
速度向上のメリットもありますが、SQLのデータの新規生成を
してくれなくなるデメリットもあります。^^;
実運用ではメリットの方が大きいと思います。
テーブルの存在チェック については当フォーラムでも
何度か出てますので、そちらもご覧下さい。
投票数:0
平均点:0.00
ara
投稿数: 122
投稿数: 122
お返事ありがとうございます。
テーブルの存在チェックは外しておりました。
いろいろ見ていたところ、画面にDbRecs関数を用いてテーブルのレコード件数を表示させておりました。また、タスク特性のオプション項目にもDbRecs関数を使用しての条件式がセットされていました。これらを取り除いたところ、PERVASIVEで実行していた時と同じぐらいのスピードになしました。
画面いテーブルのレコード数を表示させたい場合、DbRecs関数は用いない方がよいでしょうか‥
テーブルの存在チェックは外しておりました。
いろいろ見ていたところ、画面にDbRecs関数を用いてテーブルのレコード件数を表示させておりました。また、タスク特性のオプション項目にもDbRecs関数を使用しての条件式がセットされていました。これらを取り除いたところ、PERVASIVEで実行していた時と同じぐらいのスピードになしました。
画面いテーブルのレコード数を表示させたい場合、DbRecs関数は用いない方がよいでしょうか‥
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
> 遅くなりましたが、Pervasive→SQLServer（バージョンは2012）への
> 移行に取り掛かり始めました。
> 自動コンバートすごいですね。ちょっと感激です。
このことをご存じない方が多く、SQL Serverは敷居が高いと感じられて
いる人が多いことが残念です。
> 移行に取り掛かり始めました。
> 自動コンバートすごいですね。ちょっと感激です。
このことをご存じない方が多く、SQL Serverは敷居が高いと感じられて
いる人が多いことが残念です。
投票数:0
平均点:0.00
nkmt
投稿数: 1668
投稿数: 1668
速度改善して良かったですね。
私は販売管理システムで使っているデータ
30本位を１画面でいっぺんにDBRECSで件数表示させる
プログラムを用意しております。
PervasiveよりもSQL Serverの方が、
時間がかかるのを自分も感じております。
私は販売管理システムで使っているデータ
30本位を１画面でいっぺんにDBRECSで件数表示させる
プログラムを用意しております。
PervasiveよりもSQL Serverの方が、
時間がかかるのを自分も感じております。
投票数:0
平均点:0.00
Kurogane
投稿数: 50
投稿数: 50
SQLServerはテーブルにもよりますが、基本的にレコード件数の取得が遅いですね。
インデックスが多く件数が1千万を超えると、結果を得るのに10秒以上かかることも。
インデックスが多く件数が1千万を超えると、結果を得るのに10秒以上かかることも。
投票数:0
平均点:0.00