リモート デスクトップ サービス利用方法

WindowsServer2008R2のリモート デスクトップ サービスを
使用してuniPaaSを利用したいのですが

注意事項等がありましたら教えて頂きたいと思い投稿致しました。

また、Pervasiveはログインユーザとターミナル番号で
フォルダを分けて
ワークファイルとしての利用を想定していますが
リモート デスクトップ サービスを利用する場合は
Pervasive PSQL V10sp3 Server for Windows (64-bit) は
必要になるのでしょうか？

よろしくお願い致します。

■動作環境
　拠点数：2(内訳：本社・工場)
　本社にアプリケーションとデータベースサーバを設置
　本社内のパソコンからはC/S環境で
　システムを利用。20名程度
　工場のパソコンからはリモート デスクトップで
　システムを利用。10名程度

　・アプリケーションサーバ
　　OS
　　　Windows Server 2008 R2 Enterprise Edition
　　　リモート デスクトップ サービス
　　Magic 製品バージョン：
　　　Magic uniPaaS V1Plus （Ver1.9g2）
　　DBMSなどの周辺ソフトウェア：
　　　Oracle 11gR2 Client (32-bit)
　　　Pervasive PSQL v10 Workgroup(uniPaaSのバンドル)
　　
　・データベースサーバ
　　OS
　　　Windows Server 2008 R2 Enterprise Edition
　　DBMSなどの周辺ソフトウェア：
　　　Oracle 11gR2 Standard Edition (64-bit)

はじめまして。

似たような環境でuniPaaSを使おうとしていて、
現在、以下の環境で動作検証がとれています。

■動作環境
　アプリケーション兼データベースサーバを設置。
　データベースサーバ２にORACLEデータベースを配置。
　現行はＰＣから上記アプリケーション兼データベースサーバ
　にC/S形式でアクセス。

　今回新たに、
　擬似クライアント機を設置して、
　タブレット端末からリモートデスクトップで
　擬似クライアント機にアクセスする環境を構築

　・アプリケーションサーバ兼データベースサーバ
　　OS
　　　Windows Server 2008 Enterprise Edition(32-bit)
　　Magic 製品バージョン：
　　　Magic uniPaaS V1Plus （Ver1.8 SP1b）
　　DBMSなどの周辺ソフトウェア：
　　　Oracle 10g Client (32-bit)
　　　Pervasive PSQL V10sp3 Server for Windows (32-bit)

　・データベースサーバ２
　　　Oracle 10g Standard Edition (32-bit)

　・擬似クライアント機
　　※これが0673983様のアプリケーションサーバに該当すると思います。
　　OS
　　　Windows Server 2008 R2 Datacenter Edition (64-bit)
　　Magic 製品バージョン：
　　　Magic uniPaaS V1Plus （Ver1.8 SP1b）
　　DBMSなどの周辺ソフトウェア：
　　　Oracle 10g Client (32-bit)
　　　Pervasive PSQL v10 Workgroup(uniPaaSのバンドル)
　
擬似クライアント機にPervasiveのサーバー版は、不要でした。

PervasiveのWorkgroupエンジンは５ユーザーまでという制限がありますが、Workgroupが入っているマシンに対して違うIPからアクセスした場合、制限にひっかかるようです。（いわゆるC/S形式でアクセスした場合）

リモートデスクトップでの接続は、同一マシン上で複数Workgroupエンジンが立ち上がるので、１ユーザーとみなされるようです。
（６ユーザーまで検証がとれたので、Workgroupエンジンで対応可能と判断しました）

こちらも、まだ試行錯誤中なので、どこかに落とし穴があるかもしれませんが、ご参考まで。

NAKAZATO様
情報提供ありがとうございます。

参考としてお聞きしたいのですが
Pervasive PSQL v10 Workgroup(uniPaaSのバンドル)
のインストール形式ですがアプリケーションとして実行と
サービスとして実行とありますがどちらで行ったのでしょうか

よろしくお願い致します。

横レスになりますが、
Pervasiveをワークファイル用にしか使わないのであれば
Pervasiveは止めて、メモリにするのも有りなのかなと
思います。

以下で運用しています。
Windows Server 2008 R2 Standarad
MSSQL 2008 R2 Workgroup
uniPaaS V1 Plus実行版（10ユーザー）
これをデータベースサーバー兼
　リモートAPPサーバー（リモートクライアントは6台）
で利用しています。
リモートクライアントとは別に、
クラサバでクライアントが4台。

ワークファイルはメモリにしています。
このユーザーではPervasiveは一切無しにしました。

こんにちは。

インストールする時に特に意識していなかったので、アプリケーションとして実行（デフォルト）しています。

こちらを選択したのに深い意味はないので、どちらが良いのかはわかりません。

NAKAZATO様

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

こちらでも評価してみます。

nkmt様

情報ありがとうございます。

確かにメモリにすると良いと思います。

経緯としてMAGIC V7→MAGIC V9 →uniPaaSとマイグレーション
を実施しており従来からワークファイルはPervasiveで運用してました。
また以前まではC/S環境なのでワークファイルがPervasiveで
問題なく運用してましたが
今回ターミナルサービスでの運用を考慮する必要があり
投稿いたしました。

自己レスになります。

ターミナルサービスでの評価しているのですが
Pervasiveのライセンスが消費されていく結果となり
6ユーザ(6ログイン：6個のリモート接続を実施)でファイルマネージャ#161が表示
されてしまいました。

NAKAZATO様の内容ですと
>リモートデスクトップでの接続は、同一マシン上で複数Workgroupエンジンが立ち上がるので、１ユーザーとみなされるようです。
>（６ユーザーまで検証がとれたので、Workgroupエンジンで対応可能と判断しました）
となっておりこのような設定で動作させたいのですが
大変恐縮なのですがご教授願えないでしょか？

よろしくお願いいたします

0673983 さん、こんにちは。

メインが Oracle であれば、nkmt さんが言われるようにワークは Magic
の「メモリ」にしてしまったほうが手軽ですよ。

費用も掛かりませんし、メンテがはるかに楽です。

Tandaさん、こんにちは。

MAGIC V7時代に作成したシステムで
ジャーナル系のファイルはOracle
ワークはBtrieveを使用しました。

ワークはユーザログイン&ターミナル番号で分けて
作成するようにしロックを回避しています。

ワークの位置づけですが
しばらくデータを保留しておかなければならない処理が
あるのでメモリだとMAGIC終了後削除されてしまうので
ワークはBtrieveを使用した経緯があります。

その後MAGIC V9Plusにマイグレーションを実施しています。

以前までは、本社・拠点と別々にサーバを設置してましたが
サーバを本社に統合するとのことで
本社はＣ／Ｓで良いのですが
拠点をＣ／Ｓで起動した際にレスポンスの問題があり
今回リモートデスクトップサービスの導入を検討しております。

別の案件で
MAGIC V9・Pervasive PSQLでターミナルサービスの導入を
行った事があるのですが
MAGIC V9　バンドルのPervasive PSQLをサーバ上でサービス起動し
ファイルが共有されていなければ問題なく運用できていました。

その知識のまま、今回最新の環境で行った際に
Pervasive PSQL V10をリモートデスクトップサービスで使用する場合は
セッション数ごとのライセンスが必要とのことなので
Pervasive PSQL v10 Server for Windows 64-bitの購入を検討しています。

長文になり申し訳ありません。

0673983 さん、こんにちは。

あ、そういう事情があったんですね。日にちを跨いで保存しておく
必要のあるワークでしたらメモリでは駄目ですね。了解しました。

でも考えてみたら、そのような用途であれば、あえて Btrieve に
しなくても、Oracle でいいような気もしますが。

Tandaさん、にんにちは。


>でも考えてみたら、そのような用途であれば、あえて Btrieve に
>しなくても、Oracle でいいような気もしますが。
→
ご指摘の通りだと思います。
今から新規開発を行うのであれば、Pervasiveでのワークは
ないと思います。

また、マイグレーションの際にそこまで手間をかけていないのが
現状です。

MAGICv7とOracle7の開発時の知識が乏しかったと思います。
Oracle7の使い勝手も今ほど良くないですし・・・

当時はBtrieveの使い勝手が良かったと記憶しています。
NULLとか型とかそれほど意識しなくてもBtrieveは簡単に
できましたし