遠隔地からクライアント実行版で直つなぎ

本社にはリモートAPPサーバーを配置して、
本社PCはクラサバ実行版、営業所はリモートAPP
でMagic上で動く販売管理システムを
利用して頂いております。

２ケ月程前の話ですが、お客様のリモートAPPサーバーが
壊れた為、本社はWin7を親機にしてピアツピアで販売管理を
使用し、営業所は、本社のクライアントPCへ遠隔VPNながら
ピアツピア接続で２週間程臨時で販売管理を動かした事が
あります。

お互い光回線だったと思います。

データベースはSQLサーバー。

あまり工夫していないプログラムは遅かったです。

遠隔地のクライアント実行版から、このように使用した方は
おられますか？

普段は遠隔地の場合、リモートAPPで使う事がほとんです。

このように遠隔地から直つなぎをする事は初めてでした。

リスクはあるでしょうね。

nkmtさん
こんにちは

2.4ですが、県内の遠隔地で使用しています。
本店にSQLサーバーとGISサーバがあり、３拠点がクライアント実行で運用しています。
VPNで接続しています。
クライアントは全部で約３０台です。

当初はふつうのフレッツVPNで使用しておりました。
オンライン入力は遅かったと思われます。（少しクレーム有り）
今はギガVPNで使用しています。
それでも、そこそこ遅いですが、皆さん文句も言わずに入力しています。

リモートAPPは使用しておりません。
クラサバで使用しています。

オンライン系は、少し遅いかなとは感じます。
バッチ処理は、たまに帰ってこない時があります。


リスクは、
バッチ処理で失敗する(固まる)場合があります。
その場合は、強制終了し再度実行して解決しています。
もし、SQLサーバーへの接続が残っている場合には、ユーザーがMAGICを使用して切断できるようにしています。

fjksudou様　こんにちは。
レス大変ありがとうございます。

私が作った伝票一覧画面などは、初期設定で日付範囲絞り
もしていなければ、社内LANで100MbpsLAN、メモリ1GB
といった環境では使い物にならないぐらい遅かったのですが

最近の伝票だけを初期表示するなど、少しの改善でマシになりました。

余計なデータ読み込みをせぬようチープな環境でテストを
する事も大事なのかなと思ったりもします。

先日急遽私のそのお客様は拠点間直読みを行い、
遅いながらも動いたので自分でも驚きました。

GISサーバは、fjksudou様のシステムには必要な物なのでしょうね。
今日知った言葉でした。

そう言えばこちらはxpa3の部屋ですが、客先はuniPaaS V1 Plusでした。

請求書を印刷する時など、売上明細をWFへ書いたりするので
大量データが行き来するのでしょうね。バッチは遅いのが想像
できます。

また別のお客様ですが、今は本社でピアツピア３台で
営業所に１台設置する予定がありまして
直つなぎにするか、DB兼リモートAPPサーバーを設置するか
考え中です。

Pervasive時代はMonitorで接続が残っているか把握しており
ましたが、SQL Serverではそのような把握方法を知りません。

切断はDbDiscntをお使いなのでしょうか？

私はクラサバMagicからAzureのSQL Serverを
読み書きするのは実験レベルで終わりました。

クラサバMagicでAzureのSQLを読み書きする
実運用事例をお持ちの方もおられるようですね。

> クラサバMagicでAzureのSQLを読み書きする
> 実運用事例をお持ちの方もおられるようですね。

そうですね、今までは自前で本社にSQLServerを立ち上げて、各支店、営業所のクライアントMagicからそこにアクセスするというのが普通でしたが、これからはAzure SQLやAmazon RDSのデータベースサービスを利用するという方式がメジャーになっていくでしょうね。

自前でSQLServerを管理するより、コスト的にも労力的にも、はるかにメリットがありますね。

小規模ユーザーも多いので、いつまで無料で使えるのか
わかりませんがピアツピアSQL Server Expressでの実運用
のお客様もおられますし、
SQL Server Standardのお客様もおられます。
Workgroup版が無くなって、少々高額になった印象です。

xpa4.6はAzureに対応するのでしたかね？
忘れました。

> xpa4.6はAzureに対応するのでしたかね？

Azure対応とかは考える必要はありませんよ。データベーステーブルのデータベース特性で、データベースサービス先のURLを指定するだけです。どこのサービスのSQLServerでも構いません。

Azureは知りませんが、Amazon RDSなら社内のSQLServerと遜色ないくらいの速度で動作しますよ。言われなければ気が付かないくらいです。私の連載でもご案内した通りです。

過去の連載を掘り起こしてみました。もう、3年も前の記事になりますね。

第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日）

こんにちは　Ｐｕです

５拠点３０台前後をクラウド側はSQLserverとmcfとiniを配置し
Ｃ／Ｓ環境で１ケ月程運用してもらいましが
オンラインタスクは満足いくレベルでしたが
どうしても間にのバッチ処理が入るとレスポンスが遅くなり
色々チューニングしたりしましたが
（技術者的には結構満足しましたが）
やはり現場の方が以前（オンプレのＣ／Ｓ）より遅いと言われ
（当然ですが）
結局クラウド側にRDPサーバーを配置しました
でわ〜でわ〜

クラウド側にmcfを置くと負荷がサーバに集中しますから、遅くなりますよ。バッチもそこで動いているんですよね？

私は、mcfは各クライアントごとに配置することを推奨しています。導入時のSEの作業は大変でしょうけど。サーバへの負荷が全然、違いますよ。

ecfをサーバーに置く、クライアントに置くの話ですが
タスク特性 → タスク常駐YESで、何度も呼ばれる子タスク等は
少し効果はあるのでしょうね。

ecfを各クライアントへ配置の件は、PC側で最新ecfを取りに行く
BAT処理なり組み込むのもありなんでしょうね。

ecfを各PCに置く事は１度も経験がありません。
置いたら早いのでしょうね。

今回、営業所を新設する件ですが、営業サイドより
サーバーを設置してのリモートAPP、
サーバーを設置せずに、営業所子機から本社PCへ直つなぎの
両方をお客様に提示する事になりそうです。

Amazon EC2サービスとAmazon RDSサービスがごっちゃになってしまうといけませんので、ちょっと補足しておきます。

Amazon AWSには100を超えるサービスが存在していまして、Amazon EC2サービスとAmazon RDSサービスは全く別のサービスです。

EC2サービスにはWindowsインスタンスやLinuxインスタンスを配備することができますが、RDSサービスはOSに依存しないところでデータベースサービスだけ（例としてSQLServer）を提供しているサービスです。ですので、そのデータベースがどのOS上で動いているかは、まったく意識する必要はありません。クライアントからはどのOSからでもアクセスができ、アドレスとしてURLを指定するだけです。

接続は本当に簡単で、拍子抜けしてしまうくらいです。

富士通クラウドも、去年の暮れあたりからAmazon RDSのようなデータベースサービスを始めたようですが、今のところPostgreSQLだけみたいです。Windowsユーザが増えてくれば、SQLServerも立ち上がるかもしれませんね。

あ、富士通さんのマニュアルの日付が去年の暮れになっていたのでそう思っただけですが、サービス自体はもっと早くから始まっていたかもしれません。

こんにちはＰｕです

mcfではなくecfでした(^^
ただクライアントは１回目のアクセスでメモリキャシュにecfがloadされるのでサーバーに置こうが、クライアントに置こうがload後は
関係ありません。
バッチが遅くなるのはクライアントとサーバー間のトラフィック量の問題なので、ecfの配置場所とは関係ありません。
出来るだけバッチは埋め込みSQLで済ます工夫はしていますが
メモリーワークに一旦データをinsertしてその後DBに戻す処理とかがオンプレに比べて遅いと現場から言われたので
（当然なんですが）その微妙な速度にクレームがついたので
クラウド側にもRDPサーバーを立てた訳です。
riaだったらそんな事しなくて済むのですがね。

edpを変更した後ecfの配置は１ケ所で済むのでデプロイ忘れがないのでバージョン違いのトラブルはないですね。
なので私もecfを各クライアントに配置した事ないです。
でわ〜でわ〜

クラウドのデータベースサービスを利用する場合は、ecfをどこに置くという概念はありませんので、関係ないです。

そもそも、クラウドのデータベースサービスにはファイルを置くという場所がありませんので。

もっと簡単に言うと、データベースサービスを利用する場合は、ecfファイルを置くためだけのWindows Serverすら自前で用意する必要がありません。

PCにクライアント実行版があり、そのPCにecfが格納されていて
クラウド上のDBを読み書きする、という感じであれば
ecfファイルを置く為のWindowsサーバーは不要という事ですかね。

MGLOCK.DATを使ったレコードロック、テーブル排他は
裏技等で実現できますかね？想像がつきません。

私は売上伝票入力処理などは、自前で伝票排他処理を
作っています。

こんにちはＰｕです

ecfの配置の話と
rdsの話(Paas)と
cloud上でvm立てて自前でサービスを設定する(IaaS)と
分けて整理して考えた方が良いですよ
でわ〜でわ〜

引用：
そうでしょうね。ありがとうございました。
今の所、RDS　リモート　データベースサービス？？？で
実運用する計画はありません。
IaaSは検討したようです。

mglock.datは、30年前にdbMAGIC V4がBtrieveを使用していた頃からの下位互換のロック方式です。今では余程のことがない限り、それを使う必要はないと思います。

現在のMagicはDBが持つ純正の排他制御に対応していますので、mglock.datを置くためのパスを設定する必要がないです。詳細は下記の記事で解説していますので、よろしければ参照してみてください。

第114回 RDSでMagicクラサバの悲観的ロックを試す （2017年8月31日）

学術用語で区別するより、逆に適材適所の環境を具体的に比較していったほうが分かりやすいですね。

それに、専門用語はとかく翻訳が間違っているケースが多いです。「Variable」→「変数」なんていい例ですね。数学用語の訳がそのままIT用語の訳になっちゃって誤解を生んでます（笑

以下のSQLで表示して、session_idをkillしています。

SELECT es.session_id,es.host_name,es.login_time,
CASE WHEN er.sql_handle IS NULL
THEN ec_text.text ELSE er_text.text
END AS text,es.login_name,es.client_version
FROM sys.dm_exec_sessions es
LEFT JOIN sys.dm_exec_requests er
ON es.session_id = er.session_id
LEFT JOIN
(SELECT * FROM sys.dm_exec_connections
　　　WHERE　most_recent_sql_handle <> 0x0) AS ec
ON es.session_id = ec.session_id
OUTER APPLY sys.dm_exec_sql_text(er.sql_handle) AS er_text
OUTER APPLY sys.dm_exec_sql_text(ec.most_recent_sql_handle) AS ec_text
WHERE es.session_id <> @@SPID
AND es.program_name = 'Magic xpa'
AND DB_NAME(DB_ID()) =データベース名
AND es.host_name=コンピュータ名
ORDER BY es.host_name ASC

二重投稿になったようなので削除しました。

※二重投稿になったようなので削除しました。

実験として
INIファイルもedpファイルも２本用意し
INIファイル上の mglock.dat を両者で
分けてみました。（フォルダ指定して）

uniPaaS V1 Plus開発版を２本実行。

入力時ロック、ロック時トランザクション開始の
オンラインタスクをそれぞれ実行。

片方で項目を編集し、
もう片方で同一レコードを編集しようとしたら
レコードロックがかかりました。

※普段INIファイルのmglock.datをフォルダ指定などは
　しておりません。デフォルトのままにしております。



次にテーブル排他の実験をしました。
データをＷＲＮで開くPGを実行。
もう片方で同じデータをＷＷＮで開くPGを実行しても
何のエラーも出ずに起動できました。

その後、mglock.datのパス指定を解除すると
テーブル排他は効きました。

Magic uniPaaS V1 Plus　＋　SQL Serverの場合、
・レコードロックは、mglock.dat は使わない。
・テーブル排他は、mglock.dat を使う。
という実験結果になりました。

※間違えてましたらすみません。

mglock.datを利用した排他制御のテストは、開発版2台ではなく実行版2台で行ったほうがいいですよ。そうしないと正しい結果が期待できないです。できれば、ロックの当事者同志の2台と、その時の第3者からのアクセスのテストも兼ねて、実行版3台での検証が望ましいです。

それと、Magicロックを使用する場合は、データベース特性での設定を確認する必要があります。ただし、Magicロックを使用していても、DBが独自のロック機能を保有している場合は、そちらが優先されます。

補足ですが、Magicロックを使用すると、遅延トランザクションでも悲観的ロックが実現できます（物理的に同じmglock.datを共有していないと駄目ですが）。ただし、これはクラサバのみです。よく質問されるのですが、RIAでは駄目です。

なお、今後は世の中の流れとして、遅延トランザクション+楽観的ロックが中心になっていき、従来の物理トランザクション＋悲観的ロックは、利用範囲がローカルネットワークだけに限られてくるかと思います。

排他制御の学習に関しては、MSJ主催のRIAトレーニングに参加されるといいですよ。このセミナーはRIAのお話しだけでなく、クラサバにも役に立つ排他制御の話しが多いです。ぜひお勧めします。

ありがとうございます。
RIAはモバイルで参照系のみしか提供しておらず
PC RIA等で入力、保存、変更するようなシステムを提供して
おらず、RIA等で排他等を使う機会がありません。

遅延トランザクションの場合、今から変更します！の情報を
別途用意する場合もあるのかなと思っています。
同時に編集呼び出しをして、データ確定時に
保存はできませんでした！とはしたくないなと思う為です。

と書きましたが私も誤った理解があるかもしれません。
すみません。

Pervasiveの頃はレコード単位の排他しかできませんでしたので、従来のやり方のままだと、せっかくSQLServerを使っていても、そんな動きにしかなりません。

これに対して、SQLはカラム単位の排他ができますので、それを意識しながらプログラムを作ると、驚くほどきめ細かな定義が可能です。

MSJ公式のRIAトレーニングコースを受講すると、クラサバにも役立つ貴重な情報が得られますよ。