SQLServerについて
皆様、あけましておめでとうございます。
昔よりV8（たまにUniPaas）で開発を行っていた者ですが、今回Xpa4の開発でMSSQLServer（Express）のDBでPGを作成しようかと思っております。
PC（サーバ）にはMSSQL2022Expressをインストールし、MagicXpa4をインストールしたのですが（インストール時にMSSQLを選択）
その後の設定は必要でしょうか？
Iniファイルにサーバ名又はインスタンス名の記載？
データリポジトリにサーバ名又はインスタンス名の記載？
ちなみに開発したPGを他クライアントPCでも実行版にて起動しサーバのデータを読み書きする予定です。
（クライアントにはMSSQLやPVSはインストールされていません）
事前に行った作業として
・MSSQLのファイヤーウォール関連は解除しています。
・MSSQLのネットワーク構成で「TCP/IP」プロトコルは有効になっています。
・MSSQLサービスのビルトインアカウントは「LocalSystem」になっています。
・Xpaのデータベースで「DefaultDatabase」のDBMSは「MicrosoftSQLServer」になっています。
・データリポジトリ作成後「APG」で開こうとすると「MicrosoftSQLServarGateway:Connection to database failed - No database name giben」と表示されます。
・作成したPGを複数台のPCに環境を作りデータはサーバで共有をかけます。
・PGの作成にはSQL文は使用しません。（たまにズーム参照の為にRMモードを使用します）
以上長文になりましたがMSSQLを使っての開発は初めての為ご教授の程宜しくお願い致します。
-
k-katsuさん、
次の2点を確認してみてください。
1. SQLServer側には新しいデータベースは作成してありますか？
2. DefaultDatabaseの特性でSQLServerへのパスは切ってありますか？SQLServerの設定はPervasive等に比べてずっと楽ですので、慣れれば簡単ですよ。
-
追伸です。
SQLServer側で登録したデータベース名は、Magicのデータベーステーブルで「DB名」の欄に記述する必要があります。
-
tanda様
ご回答ありがとうございました。
ご教授頂いた通り設定を行いましたが、下記エラーが表示されてしまいます。
------
DBError
ServerPC\SQLEXPRESS:Sys.serversでサーバ '作成したDB名' が見つかりませんでした。
正しいサーバ名を指定したかどうか確認してください。
必要であればストアドプロシージャsp_addlinkedserverを実行し、サーバをsys.serversに追加してください。
-----
マネージメントでDBを作成し
DefaultDatabaseの特性で
サーバ名：ServerPC\SQLEXPRESS
ユーザ名：sa
パスワード：Password
接続文字列：記載なし
を入力し、
DefaultDatabaseの「DB名」のところにManagementで作成したデータベース名を入力しました。
ちなみに、MAGICのデータベースのところでDefaultDatabaseのDBMSが「MicrosoftSQLServer」になっており、その下にあるMSSQLのDBMSも同じようになっています。（DB名はそれぞれ違っています）
これが原因の対象でしょうか？
何度も申し訳ありません、ご教授の程宜しくお願い致します。
-
追記です。
あれからいろいろ調べて、エラーは解決されDBは開くようになりました。
ちなみになのですが、
①テーブルリポジトリの「データソース名」のところで論理ファイルの場所を定義しているのですが、実際に出来上がる場所はSQLServer内になるのでしょうか？（IniFileで設定しているファイルの場所％●●％は不要になるのでしょうか？）
②BTIやPVSの場合は上記論理ﾌｫﾙﾀﾞ内をコピーしてバックアップ＆復元していたのですが、SQLServerを使用する場合はインポートとエクスポートでコマンドをたたかないといけないのでしょうか？
宜しくお願い致します。
-
k-katsuさん、
「データソース名」で論理名を使う場合は、それを展開したときの値がSQLSercerが認識できる文字列でないと駄目ですね。データソースが生成される場所は、SQLServerが管理するフォルダなります。
バックアップや復元は、SQLServerのManagement Studioからデータベースを右クリックして、メニューの「タスク」⇨「バックアップ・復元」でできますよ。
あるいは、SQLServerのサービス自体を止めれば、ファイルのコピーだけでバックアップを取ることもできます。
-
tada様、お世話になっております。
MSSQLサーバを使うときに使用する文字はいろいろ制限があるのですね。
今まではIniファイルに論理名を記載し、データソース名に「%DATA%File.Dat」と記載すれば、そのフォルダに物理的に作成され、コピーや削除が容易にできたのですがMSSQLServerの場合はそういう訳にはいかないのですね。
その場合、PC毎に作成するワークファイルは共有フォルダではなく自分の任意のフォルダを指定していたのですがそれができないということでしょうか？（ワークファイルは全てMemoryにする？）
なにか良い方法をご教授お願い致します。
-
データソース定義の「データベース名」欄で使用する論理名は、BtrieveやPervasiveの頃の下位互換として残されているような機能なんでしょうね。SQLで論理名を使うというのはあまり聞いたことがないです。
また、BtrieveやPervasiveの時代に使用されていたワークファイルという手法は、トランザクションの概念が薄かった頃のソリューションですから、今ではMagic xpaで提供されている「遅延トランザクション」の機能を使用するのが最も効率的だと思います。
SQLは人間が作ったものとは思えないような機能を有していますので、使い慣れるともう二度とISAMデータベースには戻れないですよ。
頑張ってください。
-
補足です。
マジック社が提供している「RIAトレーニング」を受講されると、SQLと遅延トランザクションの概念について多くを学ぶことができますよ。お勧めです。
-
tandaさんの意見とは少々異なりますが。
私もv8の頃に、Btrieve からMS SQL に切り替えを行いました。
私もワークファイルどうしようかなと思い。結局遅延トランザクションではなく、SQL Server上にBtrieveと同様に「ワークファイル」を設けて移行しました。
Btrieve の場合は各ローカル環境に”ワークファイル”を設けて、DBDELなどで 消していたのですが、SQL Serverに切り替え、DBDELすると、SQL Server内のテーブルも 消えて しまいます。
なので、ワークファイルは共有テーブルにして、キー情報として「Term()」で求められる端末番号を使用してみました。
で、削除は、Magicの削除タスク、もしくはダイレクトSQL文でDELETE文を発行しています。
本当はSQLの遅延に切り替えた方が良いのは重々承知していますが、事Btrieve環境からの移行の際には、この方法が個人的には、わかりやすかったです。
-
私はuniPaaS V1 Plus 以降は、ワークファイルは全て メモリ へ変更しています。
ワークファイルに、BtrieveやPervasive、Actianの頃は
各クライアント上にワークファイルを作ったり、
あるいはサーバー上に Term()を付加した名前にするなどしておりましたが、
メモリにした場合それら命名なども全て廃止しました。 -
補足です。
「遅延トランザクション」は物理トランザクションと違って、トランザクションを入れ子構造にすることができますので、ツリー構造のタスクにおいてタスクごとにトランザクションを独立させることができますから、使ってみると驚くほど便利なことが分かりますよ。
これまでに、「遅延トランザクションを使ってみて、涙が出るほど感激した」という人を多く見てきました（笑
-
こんにちはPuです。
私もnkmtさんと同じくワークファイルは全てメモリーにしてます。
ここからは間違っていたらごめんなさい（指摘してください、自分の認識なので）
それと「遅延トランザクション」ってトランクションが入れ子になる機能ではなく
トランザクションが一番最後に掛かる＝asp.netで言うところのデータセットと同じ仕組みだと
思っています。
トランザクションの概念では、そもそも入れ子などできず、一番外側がstart trunとend trunだと理解してます。
ですので「遅延トランザクション」はトランザクションロックが掛かる時間が一番短く
楽観的ロックを簡単に実現出来る機能だと理解しているのですが
でわ～でわ～ -
Ｐｕさん、
遅延トランザクションと物理トランザクションは別物と考えたほうが理解しやすいですよ。
物理トランザクションはDBがもともと持つ機能をMagicからコールしているだけでして、これに対して遅延トランザクションは、物理トランザクションに欠けている機能をMagic社が追加して補った、Magicオリジナルの機能です。
ですので、実行形態としては、遅延トランザクションがコミットされると、それに続いて物理トランザクションが一瞬のうちに実行されて、処理がDBに反映されます。遅延トランザクションだけで処理が完結するということはありません。ただし、アボートの時はDBへの更新は不要ですので、物理トランザクションは起動しません。
タスクごとに入れ子構造にしてそれぞれを独立したトランザクションにできるというのは、これらの機能を利用しているからです。つまり、子タスクで処理をコミットするなりアボートするなりして親タスクに戻った時、親タスクでは親タスク独自にコミットなりアボートしたりすることができるわけです。
DBがもつ物理トランザクションは、Puさんが言われるようにトランザクションの開始と終了しかありませんので、入れ子構造どころか、タスクごとの独立したトランザクションなどもあり得ないわけです。
元々にない機能は何でも自前で作ってしまえというのが、Magicに30年以上も続いている哲学なんでしょうね。
-
こんにちはPuです。
そのような機能なら、親タスクで伝票headを更新し子タスクで伝票itemを更新するタスクがあった場合
子タスクでロールバックしても親タスクでコミットできるので伝票headは更新されると言う認識で
良いのでしょうか？
（そもそもロールバックポイントは一つしか作成されないはず）
どうもトランザクションの一貫性という考え方から思考が抜けないもので
このスレッドに質問して申し訳ありません('_')
でわ～でわ～ -
Ｐｕさん、
> 子タスクでロールバックしても親タスクでコミットできるので伝票headは更新されると言う認識で
> 良いのでしょうか？はい、そうです。そのときは、子タスクのタスク特性では、「W=有効な遅延トランザアクション内」の設定ではなく、「N=新規のトランザクション」の設定にしてやる必要があります。
その設定でトランザクションを入れ子にすることが可能となります。
-
丹田さん、ｒｅｓありがとうござます
目から鱗です。
でわ～でわ～ -
皆さんお世話になっております。
皆さんの知識はすごいですね。私は頭が固くて(^-^;
私は今までのBTIやPVSのようなやり方でメモリーにしようかと思います。
ちなみにメモリーを使用する場合、各クライアントのメモリを使用するのですよね？
貴重なご意見有難うございました。
-
k-katsuさん、
「Memory」はコンテキストの一部として扱われますので、サーバ上で管理されます。
-
私は売上伝票入力をして、各売上明細の売上数量で拠点別＋商品コード別＋年月別の売上数量や在庫数を管理するデータも更新するようなシステムは、売上伝票をごっそりWF（メモリワーク）へ持ってきて、後で一括して反映させる作りを未だにやっております。
１レコード完結のメンテナンスでは、場合によっては遅延トランザクションも使っています。
でもtandaさんはPuさんのようには使いこなせていないです。
先程の売上伝票入力処理を、並行実行で複数起動しても、メモリＷＦは互いに影響受けませんし、WFは今はもうメモリばかり使用しております。 -
nkmtさん、
> 先程の売上伝票入力処理を、並行実行で複数起動しても、メモリＷＦは互いに影響受けませんし、WFは
> 今はもうメモリばかり使用しております。「Memory」はコンテキストで管理されますので、他のコンテキストの影響を受けることはありません。
ちなみに、コンテキストとして管理されるものは、次の3つです。
1. Memory
2. メインプログラムで定義したグローバル変数
3. すべてのトランザクション処理マジック社のRIAのトレーニングを受講されると、詳しく解説してもらえますよ。
-
贅沢な不満として、並行実行で動かしたメモリＷＦは、データリポジトリでＡＰＧで中身を見られない事です。^^
-
nkmtさん、
データリポジトリを開いた時点で、すでにコンテキストは消滅していますので、当然のことながら中身も消滅します。
あと、並行実行で開いたMemoryは、別コンテキストとしての扱いになります。
-
そういう事ですね。ありがとうございました。
> データリポジトリを開いた時点で、すでにコンテキストは消滅していますので、当然のことながら中身も消滅します。
並行実行PGのMemoyのデータの中身を見たい時は、並行実行を解除して実験するようにしております。 -
nkmtさん、
「並行実行」って、これのことですよ。
-
並行実行は私もそれを指してます。
-
自分自身のMemoryの中身を見たいときは、並行実行は無関係ですよ。並行実行されているMemoryの中身は、そのコンテキストの所有者しか見ることができません。
-
並行実行のPGでメモリWFを作成し、そのPGの実行を終了し、
データリポジトリで、そのメモリWFの中身がどうなってるかなー？と見ようと思っても
消滅済で見られないので・・・・
並行実行を解除してから再度同様の実験をしています。 -
ひとりの人が操作していても、別コンテキストは別コンテキストとして扱われますので、そのコンテキストを終了すると、別のコンテキストからは見ることができません。
それが、Magicのコンテキスト処理のたいへん優れたところです。プログラム作りがとても簡潔になります。セッション管理を手動で行おうとすると、たいへんなプログラム作りが必要となります。
サインインしてコメントを残してください。
コメント
28件のコメント