使用DBの変更について
みなさんこんばんは。
昔よりV8でシステム構築しておりましたが、今回マイグレーションをきっかけに下記の観光構築は可能でしょうか？
現行
親機 MagicV8（PVSWKインストール、実ファイル定義はMagicIniで設定）
子機2台 MasigV8（PVSWKインストール、実ファイル定義はMagicIniで設定）
NAS（実ファイルの格納）
新たな環境
親機 MagicXpa（MSSQLSERVEREXPRESS、実ファイル定義はMagicIniで設定）
子機２台 MagicXpa（DBセットアップなし、実ファイル定義はMagicIniで設定）
NAS（実ファイルの格納）
V8の頃よりSQL分でのシステム構築は行っておらず今回も費用面からプログラムはそのままを活用したいと思います。また、DB設定はV8のまま「データリポジトリ」で作成予定です。（MicrosoftSQLSqlserverManagementStudioは使用しない）
実データは一度CSV出力を行い、新DBへ取込み作業を行う予定です。
上記新たな環境構築は可能でしょうか？またPVSDBのセットアップは必要でしょうか？
宜しくお願い致します。
-
こんにちはＰｕです
後気を付ける事は、項目名(予約文字等の関係)
日付や時刻もSQLserverはdatetmeなので
CSVの取り込みでしたらPVSは必要ないです。
でわ～でわ～
-
xpaだと「MGTOOLS」などのDLLが使えません。UniPaas迄は使えたんですけどね。
メッセージボックス等で使っていたら、プログラムを作らないといけません。
SQLServerだとテーブルの項目名に ( )や： ①等が使えないので注意が必要です。
MicrosoftSQLServerManagementStudioはSQLServerを使う場合、バックアップや復元に使えますので
親機にはインストールした方が良いと思います。
メインファイルのインデックスを式で変更する方式のプログラムであれば､PSQLより確実に遅くなります。
そのままのプログラムにして工数を掛けたくないのであればxpa4+Actian Zen v14 for Magicにした方が良いと思います。
-
DBの変更は、Magicの開発版が内蔵しているコンバータに任せるのが一番、安全確実ですよ。外部ツールは一切不要ですし、なおかつCSV等の外部ファイルも経由する必要がありません。
事前にSQLServer用のデータベースを定義し、データリポジトリで「データベース」の欄をそのデータベースに変更するだけです。すると、自動的に変換ウィザードが起動され、コンバータが走り出します。
-
ただし、念のために小さなダミーデータでテストをし、本番のデータも事前にしっかりバックアップを取っておいてから利用されることをお勧めします。データベースが大きい場合は何時間も、あるいは何十時間も掛かる場合もありますので。
-
みなさんこんばんわ。貴重なご意見ありがとうございました。
今までV4から始まりV8での開発ばかり（SQL文も未記載）でDBもBTI→PVS（ワークグループ）のみの使用だった為自分の知識も止まったままです。その為MSSQLSERVERに移そうかと思ってもデータリポジトリではなくSQLSERVER内でファイル構築をしないといけないかとか、テーブルをMAGICで定義する方法とか未知の世界です。
＞MicrosoftSQLServerManagementStudioはSQLServerを使う場合、バックアップや復元に使えますので
親機にはインストールした方が良いと思います。
今までは物理ファイルXXX.DATを丸ごとコピーでバックアップを行っていましたがそういう訳にはいかないということですね。
＞メインファイルのインデックスを式で変更する方式のプログラムであれば､PSQLより確実に遅くなります。
いくつかのメインファイルインデックスを式で使用している箇所があると思います。お客さんが納得してくれる範囲（費用をかけない為）だったらいいんですけどね。
＞そのままのプログラムにして工数を掛けたくないのであればxpa4+Actian Zen v14 for Magicにした方が良いと思います。
今までバンドルされているDBのみ使用していましたので「Actian Zen v14 for Magic」なんかがあるのですね。
＞事前にSQLServer用のデータベースを定義し、データリポジトリで「データベース」の欄をそのデータベースに変更するだけです。すると、自動的に変換ウィザードが起動され、コンバータが走り出します。
SQLServer用データベースを定義というのはINIFileで設定を行うのでしょうか？無知ですみません。
そもそもMSSQLSERVERに接続する際はログインPC名（親機PC名\SQLEXPRESS、SA、パスワード）の設定も必要でしょうか？
本当にDBに関して素人で申し訳ありませんがよろしくお願い致します。
-
MAGIC+SQLServerを理解するにはtandaさんの丹田コンピューターで行われている
「Magic xpa で作るイベントドリブン型プログラム」の講座を申し込まれた方が良いと思います。
私はこの講座のおかげでMagic+SQLServerの基本的な部分を理解することが出来ました。
あとSQLServerを使うのならば日付や時刻項目は文字型にした方が後々楽ですよ。
日付形式や時刻形式だとゼロ値を受け付けませんので。
このことを知らずにそのままPSQLからコンバートしたシステムは後の変更で苦労しました。
-
> SQLServer用データベースを定義というのはINIFileで設定を行うのでしょうか？無知ですみません。
SQLServer側に新しいデータベースを1個登録し（名前を付けるだけ）、それをMagic側のデータベーステーブルに追加します。あとは、そのデータベースをデータリポジトリの「データベース」欄で切り替えるだけです。
※くれぐれも、事前にダミーデータでテストを行ってから本番に臨んでください。
-
Ace_Nagashimaさん、ありがとうございます。
ちなみに、SQLServerに関する記事の部分は次の通りです。
第1回 Microsoft SQL Server 2005 Express のインストール （2008年11月4日）
第2回 SQL データベースの作成と Magic からの接続 （2008年11月25日）
第3回 Pervasive.SQL のデータを SQL Server に移行する （2008年12月8日）
第4回 Pervasive.SQL のデータを SQL Server に移行する(2) （2008年12月30日）
第5回 SQL Server のデータベースを別マシンに移動する （2009年1月9日）
第6回 SQL Server に Magic からリモート接続する （2009年1月26日）
第7回 SQL Server からの定義取得 （2009年2月14日）
第8回 SQL Server からの定義取得(2) （2009年2月27日）
第35回 SQL 上にユニークキーを自動生成する方法 （2011年1月31日）
第38回 SQL Where 句の書き方 （2011年4月30日）
第39回 SQL Where 句の書き方(2) （2011年5月31日）
第40回 SQL Where 句の書き方(3) （2011年6月30日）
第41回 Microsoft SQL Server 2008 R2 Express のインストール （2011年7月31日）
第42回 SQL Server 2008 R2 Express の環境設定の構築 （2011年8月31日）
第43回 データベースのバックアップ、コピー、移動の仕方 （2011年9月30日）
第44回 SQL の外部リンクと結合リンクについて （2011年10月31日）
第45回 外部キー制約について （2011年11月30日）
第46回 外部キー制約について（2） （2011年12月31日）
第47回 外部キー制約について（3） （2012年1月31日）
第109回 Magic から Amazon RDS を利用する （2017年3月31日）
第110回 Magic から Amazon RDS を利用する（2） （2017年4月30日）
第111回 Magic から Amazon RDS を利用する（3） （2017年5月31日）
第112回 Magic から Amazon RDS を利用する（4） （2017年6月30日）
第113回 Magic から Amazon RDS を利用する（5） （2017年7月31日）
第114回 RDSでMagicクラサバの悲観的ロックを試す （2017年8月31日） -
みなさんこんばんは。
数々のご教授有難うございました。
＞日付形式や時刻形式だとゼロ値を受け付けませんので。
そうなんですね。結構バッチ処理で日付型→数値、数値→日付型に処理を行っている箇所があるので、もしMSSQLSERVERにする場合は今のＰＧロジックを見直さないといけないようですね。
＞「Magic xpa で作るイベントドリブン型プログラム」の講座を申し込まれた方が良いと思います。
ご指示有難うございます。今回はお客さんの要望なのでこれを機に追加ＰＧは脱ＲＭなど考えていたのですが費用を抑えてが第一なのでもう少し打ち合わせをして方向性を決めたいと思います。
有難うございました。
-
こんにちはＰｕです
>＞日付形式や時刻形式だとゼロ値を受け付けませんので。
>そうなんですね。結構バッチ処理で日付型→数値、数値→日付型に処理を行っている箇所があるので、もし>MSSQLSERVERにする場合は今のＰＧロジックを見直さないといけないようですね。
Magic側は日付型、時刻型で問題ないです、SQLserver側をchar型にするだけなので
PGは見直さなくても大丈夫です。
でわ～でわ～
-
工数かけずリスクを減らすには
Pervasive（現Actian）でいくのがベターです。マイグレーションした新しいシステムを
もしSQL Serverにするのであれば、
DBの定義は、Magic開発版で行います。
データリポジトリ（旧データ辞書）上には
従来のPervasiveのデータと
SQL Serverのデータと両方用意して
Pervasiveのデータをメインソース（旧メインファイル）にして
登録リンクに、SQL Serverのデータを指定した
データコンバートプログラムはよく作ります。マイグレーション環境でも
客先環境でもこのデータ変換PGは何10回も実行しますので。客先のDB親機にも
SQL Server ManagementStudio は入れています。
私は新規案件ではActianは一切使用しておりません。
私の場合は
MagicでSQL Serverを使いSQL文も多用し開発効率が上がりました。ここにおいでの皆様にも過去沢山教えて頂いたおかげです。
費用や時間が許すのであれば
将来を見越して、脱RM、SQL Server化、
シーンによってはSQLコマンドも使うのも
いいと思います。
今回の案件は、費用第一であれば
繰り返しになりますが
Pervasive（現Actian）でいくのがベターです。 -
ISHIJIMAさんのおっしゃる通りでしょうね。
そのユーザーでしか使えないシステムで
SQL Server化
RM互換廃止（イベント化）
ファントムタスク廃止（サブフォーム化）
などの工数分の費用が出ないなら
しない方がいいという考えもあるでしょうね。 -
私自身はuniPaaSやxpaにマイグレーションしたシステムでRM互換を残してある分は一つもありません。
ですが今の所最新でやったマイグレーション案件はミスりました。
その前の案件はVery Goodでした。 -
こんにちはＰｕです。
技術的なコメントでなくすみません。自分自身に対するメッセージです。(笑)
そのシステムを「投資」と考えるのか、「コスト」と考えるのかの違いだと思います。
「投資」となるようなシステムであればお客様も納得されるのではないでしょうか。
我々エンジニアは、そう思ってもらえるシステムを提供し続ける．．．と言う気持ちで(^^
常に新し事にチャレンジしましょう<=== これは自分への投資です。
でわ～でわ～
-
そうですね。販売管理などはお客様からの改善要望も積極的な会社様もありますし、こうすればもっと便利になりますよね、改善されますよね、経費が永続的に減りますよねと提案してます。
サインインしてコメントを残してください。
コメント
15件のコメント