メインコンテンツへスキップ

登録リンク時のDBエラーについて

コメント

17件のコメント

  • Tanda

    > データベースをOracleからSQL Serverへ変更しました。

    変更作業はどういう手順で行いましたか?

  • じゃいあん

    ISHIJIMAさま、tandaさま 

    ご返信ありがとうございます。

    変更作業はSQL Server マイグレーションツールを用いて移行しました!

    マイグレーション時に日付項目等のエラーが出ている箇所はMagicでテキスト入出力で移行をおこなっています。

     

  • じゃいあん

    ISHIJIMAさまが仰る通り登録リンクにすべて定義する方法しかないかもしれないですね

    Optimaizerを使って登録リンクを1つずつ確認していってみます。

  • Tanda

    > 変更作業はSQL Server マイグレーションツールを用いて移行しました!

    外部ツールを使って変換するより、Magicが自前で内蔵する変換機能を使ったほうが安全確実ですよ。

    データリポジトリで「データベース」の欄をOracleのものからSQLServerのものに変更するだけで、自動的にコンバータが起動されて、「変換しますか?」と聞いてきます。

    外部ツールを使用するより変換に時間が掛かるかもしれませんが、すべてMagicが自動で変換を行いますので、トラブルなく変換できます。ただし、万が一にそなえて事前にバックアップはしっかり取ってから作業してください。

  • Tanda

    注意:
    この時に、SQLServer側では事前のテーブル定義やカラム定義等は一切行わないようにしてください。Magicが全てを自動でやってくれます。Magicがマジックと呼ばれる所以ですね。

  • Tanda

    もし、Magicの内蔵変換機能の使い方がよく分からないということでしたら、下記の記事をご参照ください。有償サイトであるのが心苦しいですが、手順の詳細を事細かく解説しています。

    第3回 Pervasive.SQL のデータを SQL Server に移行する (2008年12月8日)
    第4回 Pervasive.SQL のデータを SQL Server に移行する(2) (2008年12月30日)

    ※記事では、PervasiveからSQLServerへの変換となっていますが、OracleからSQLServerへの変換であっても、要領はまったく同じです。

    URL: http://www.tandacomp.com/home/magic/columns/rensaiyokokumagicv10detsukuruibentodoribungatapuroguramu-1

  • nkmt

    じゃいあんへ。すごい名前ですね。

    私は英語苦手ですけど、

     Insert failed
     not all position key segments in magic data view

     挿入エラー
     キーを構成する項目はデータビューに定義してくれよ!

    なんでしょうね。

    Magic xpa2.3bのとあるシステムをOracleからSQL Serverに変えたんですね。

    土曜日なのにお疲れ様です。

    DBの変更及びシステムの改造が生じたシステムなんですね。

    私もSQL Serverを使っていますが、INSERT する場合
    主キー項目は、データビューに定義が必要だと思います。

    0だったり文字項目''だから定義せんでいいだろうと思うが
    実行時にエラーが出る感覚が身についている。
    おそらくそういうもんだと思います。

    定義しないでも済む回避策があれば知りたい。

    Oracleだと問題ないという訳ではなくて
    SQL Server化と同時に、項目追加になり、
    しかも主キーに組み込む項目だった
    という事なんでしょう。

     

    登録リンクだけ点検してもダメじゃないかな。

    書出リンクも点検しないといけないかも。

     

    ISHIJIMAさん
    > 私の場合はDB側の定義は一切修正できなかったのですべて項目を定義しました。
    意味理解します。
    データベースデフォルト値が全然入っていないとMagic側のデータビューで
    項目展開しないといけなかったような気がしますが、それは誤りもあるかもしれませんね。
    今のうちに謝っておきます。

    私も大して技術は無いのですが、質問者が何に困っているのか
    よく意図を汲み取って問題解消の手助けを心がけます。

  • nkmt

    本筋から逸れますが、台数多くなければ2.5bだったか忘れましたが最新版にあげるメリットがあればされては。
    台数次第なんでしょうけど。
    ジャイアンさんは、親機にのみMagic入れる派でしょうか?

  • Tanda

    じゃいあんさん

    データ変換の手順なのですが、外部ツール等を使って変換作業を行ったりしますと、その場では変換自体はうまくいっているように見えても、実際に新しいプログラムを追加したり、古いプログラムを修正していったりすると、「あれっ、こんなはずじゃなかったのに!」というような副作用があとからあとから出てくる場合があります。

    したがって、まずはMagicがデフォルトで持つデータ形式にMagic任せで自動変換させるというのが、将来の安心につながりますよ。ご成功をお祈りします。

  • Tanda

    簡単な例を挙げますと(あくまで1つの例ですが)、

    Magicの場合、カラム欄が空であれば数値型なら値として「0」が入り、文字型なら値として「''(空白)」が入りますが、たいていのDBの場合はデフォルトが「(Null)」になるかと思います。

    で、Magic側で「Null値」を許可しているかどうかによっても、データ構造にズレが生じますし、動きも変わってくるはずです。

    こういった設定は、プロパティだけでは確認できないこともありますので、落とし穴になりがちですね(Null値許可:ON/OFFは確認できますが)。

  • ISHIJIMAさま

    ご返答ありがとうございます。

    Magicの理解度を上げるためにも時間を作ってSQL Server マイグレーションツールとMAGICで変換した場合の違いを確認してみたいと思います。

    仰る通り完全にしたいと思いますのでMagic変換を試していこうと思います。

     

    tandaさま

    ご返答ありがとうごさいます。

    Magic変換とても便利ですね!「変換しますか?」という項目が出てきたとき、スキップしておりました。。。orz

    変換することでデータなどが消えてしまう可能性もあるのでデータ件数等の採取した上でMagic変換を試してみたいと思います。

    tandaさまが公開しているMagicのサイトがとても気になりますので

    機会がございましたら参考にさせていただきます!

     

    nkmtさま

    ご返答ありがとうござます。名前の突っ込みはよくされます笑

    仰った通り、登録リンク及び書込リンクについても確認していきたいと思います!

    質問の内容について情報が不足していた点について申し訳ございません。

    教えて頂く立場ということを踏まえできるだけわかりやすく情報を記述していきたいと思います!

     

     

     

     

  • Tanda

    Magic変換で「変換しますか?:はい」とすれば、そのあと必ず「バックアップしますか?」と聞いて来ます。

    ここで「はい」と答えれば元テーブルのバックアップが自動で作成されますのでたいていの場合は大丈夫なのですが、最初のうちはそのバックアップがどこに作られているのかで戸惑ってしまったりすることもありますので、やはり事前に明示的に、ご自分で分かりやすいようにバックアップを取っておくことをお勧めします。

    Magicの理念はここ30年変わらず、「すべての処理を簡単に自己完結で!」というところにありますので、なるべく外部ツール等に頼らずに、自前の機能で処理したほうが、安心で、安全で、楽ちんです。(^^)

  • nkmt
    Magic上で項目定義を完結させるという点では、考えは皆様と同じです。
    変更しますか? はい、いいえ が表示され
    ステータスバーには、「変換処理が必要です。」と表示される。
     
    ここで いいえ を選んでも、定義自体は変更されている。
     
    データの移行ですが
    ・開発時のデータ移行
    ・客先検証時のデータ移行
    ・本番直前のデータ移行
    など、データ移行は何度も何度も行うはずです。
     
    テーブルに追加する項目が複数有って、変更するテーブルがいくつもある。
     
    そんな場合、データリポジトリ上で定義を変更して
    物理変換などしてられません。
     
    開発環境で定義変更をし
    客先環境でも同様にデータリポジトリ上で定義変更。
    本数や項目数が多くなれば、間違いが起きる恐れも高くなりますし
    現場に張り付いていないといけない時間も多く要す事になります。
     
    よって、データリポジトリ上でデータソースの変更や項目追加などと同時に
    データの物理変換を行うという事は、私の場合は稀です。
     
    現実的には
    ・Oracleの定義のままの現レイアウトを別場所へ複写し
    ・本物DS#の項目追加したSQL Serverの新レイアウト
    と両方用意して
    ・SQL ServerのデータをDBDELして
    ・Oracle → SQL Serverへの登録リンク(テーブル CreateもMagic任せ)
    のデータ移行プログラムを作成するのが現実的な選択だと思います。
     
    先日、稼働中のシステムに項目追加をするというスレッドがありましたが、
    客先環境でデータリポジトリを直接触り、
    物理変換までそれで行うというのは
    私の場合、まずしません。
  • nkmt

    ISHIJIMAさん レスありがとうございます。

    客先に開発版もいれていないし、客先DBをまるごとこっちに持ってきて、

    こっちの開発版でデータ定義変換して、そこで物理変換もしたDBを客に

    戻すという事もあまりしませんので、データ変換PGは必ず作ってました。今までは。

     

    でも 先日教えて頂いた
    ALTER  TABLE  ○○テーブル

    ADD 追加項目 char(20) NOT NULL DEFAULT (' ')

    は便利なのでありがたいです。先日使いました。

     

  • nkmt

    じゃいあんへ

     

    私も同様にxpa3のシステムで、インデックスに項目の追加を行いました。

    インデックスを構成する追加項目を、書出リンクに定義しないまま

    W=書出リンクを行うと同様にエラーとなりました。

    「Microsoft SQL Server Gateway:Insert failed,not all position key segments in magic data view」

     

    インデックスを構成する追加項目をデータビューに定義したらエラーは出なくなりました。

    位置付け、代入などは不要なので、データベースデフォルト値の0のままで今回はokだったので

    定義のみ行いました。

    登録リンク、書出リンクともに、インデックスを構成する項目はデータビューに追加しないと

    いけないのでしょうね。

     

  • tandaさま

    ご返答ありがとうございます。

    仰ってた画面導線について一度試してみたいと思います。

     

    nkmtさま

    ご返答ありがとうございます。

    書き出しリンクについても同様にお答え頂きありがとうございます。

    客先DBの入れ替え時に物理変換は確かにできないですね。。中には300万件近くのデータが格納されているものも

    ありますので。

    >現実的には
    ・Oracleの定義のままの現レイアウトを別場所へ複写し
    ・本物DS#の項目追加したSQL Serverの新レイアウト
    と両方用意して
    ・SQL ServerのデータをDBDELして
    ・Oracle → SQL Serverへの登録リンク(テーブル CreateもMagic任せ)
    のデータ移行プログラムを作成するのが現実的な選択だと思います。
     
    上記で仰った通りの移行方法がMagicに依存した移行方法としては適切かと思いました。
    とても参考になりました。ありがとうございます。

     

  • Tanda

    > データ移行をどのようにするかによりますね・・・
    > 開発環境・実行環境(テスト・本番・・・)・・・

    ISHIJIMAさん、おっしゃる通りです。さすがに場数を踏んでいる現場のプロですね (^^)

サインインしてコメントを残してください。