| 過去の桐井戸端ＢＢＳ （桐ver.９） |
| 27331 | 桐ｖ９で６０万件ほどのデータをサーバーにおいてクライアントで扱うことはできますか | ニューヨーク | 2004/08/10-20:21 |
|
桐ｖ9-2004を使っています。 60万件ほどの顧客データがあるのですが これをファイルサーバーにおいて 複数のクライアントで検索処理等をおこないたいのですが 桐で絶えうることができるでしょうか？ ご指導ください。 | |||
| 27332 | Re:６０万件のデータを扱えますか | 佐田 守弘 | 2004/08/11-00:34 |
| 記事番号27331へのコメント ニューヨークさん まず、何人のユーザが同時に使うのか、ネットワークの容量はどの程度あるのか、 検索対象と検索の内容はどの様なものか、また検索に要する時間としてどの程度を 許容しているのかによっても答が変わると思います。 ですから実際にそれが堪えうるのかどうかは、使用する環境で試してみないと何とも言えないと思います。 従いまして、一般論的なコメントになります。 表ファイルをサーバに置いて共有で使う場合には、索引が使えません。 （共有状態でもユーザーが一人なら索引は使われるとの事） また桐の場合サーバにあるデータをクライアント側で受けながら、検索などの処理を行うので、 ネットワークの負荷が大きくなる課題があります。 ネットワークの負荷を軽減する方法としては、桐forTSE（ターミナルサーバエディション）を使う方が良いかも知れません。 佐田守弘(KS-00119) | |||
| 27333 | Re:６０万件のデータを扱えますか | ニューヨーク | 2004/08/11-07:57 |
| 記事番号27332へのコメント 佐田 守弘さん ありがとうございました。 桐forTSEで試します。 | |||
| 27335 | Re:６０万件のデータを扱えますか | 宮城 | 2004/08/11-09:04 |
| 記事番号27333へのコメント >桐forTSEで試します。 60万件というかたにはいらぬお節介とは思いますが、気軽に試そうかというお値段ではないですよ （あるところで、ab \260K）。念のため。 | |||
| 27345 | Re:６０万件のデータを扱えますか | 小松亀一 | 2004/08/12-12:54 |
| 記事番号27335へのコメント 宮城さん,お久しぶりです。 >>桐forTSEで試します。 > >60万件というかたにはいらぬお節介とは思いますが、気軽に試そうか >というお値段ではないですよ（あるところで、ab \260K）。念のため。 実は、出張先でノートパソコンから直接事務所サーバーの桐データにアクセスしてファイルを開いて、 事務所にいると同様に桐データを扱うことが可能になると言うことで、 桐forTSE10クライアント版にシトリックス(これが高価です)更にTSE桐用サーバー機等100万円近い金額を 費やして設置しました。 結論は当事務所のような文書作成データベースとしての使用の場合、役に立たないと言うことでした。 大量の60万件の顧客データ等大量データ処理のスピードアップ化には役立つとは推測していますが。 当事務所は各種通知文書、訴状、各種申立書、準備書面等全ての文書を 桐表化して、共有使用フォームで編集し、レポートプレビューでで印刷内容を 確認した上で印刷するというスタイルです。 ある事務員がクライアントパソコンからTSE桐ファイルを使用して、 プレビューをかけると他のクライアントパソコンで使用しているTSE桐の処理速度が極端に落ち、 極端な場合、「きり」と入力して「桐」と変換される時間が、５秒以上かかるなど、 実務使用に耐えられなくなる状態が続きました。 この現象について管理工学に問い合わせた回答は概ね以下の通りです。 （回答始め） 印刷プレビューでは、出来るだけ速やかにプレビュー画面を表示するため 仕様として可能な限りTSE桐の置いてあるサーバー機のＣＰＵに負荷を掛けて実行する。 そのためプレビュー期間中、ＣＰＵの余力が無くなり、他のクライアントパソコンからの使用について、 処理速度が落ちる等の支障が出る。 従って、この現象を避けるためにはプレビュー使用を避けるしか方法はない。 （回答終了） しかし、文書作成の場合、プレビューで印刷内容を確かめないで、印刷することは出来ません。 プレビューするなと言うことは使うなと言うことと同じで、結局、大枚をはたいて導入した桐forTSE及び関連のシトリックス 或いはTSE桐専用サーバー機は、埃をかぶって眠ったままです。 私は印刷プレビューすると使えなくなるような商品は致命的とも言える欠陥であり、 欠陥商品として、製作販売会社に対して商品の瑕疵を理由に損害賠償請求の訴え提起準備中です。 −−−−−なんて全くの冗談です(^^)。 桐には大変なお世話になっていますのでとても出来ません。 しかし、新しいものが出たからと直ぐ飛びつくのは危険との大きな教訓でした。 | |||
| 27352 | Re:６０万件のデータを扱えますか | 尾形 | 2004/08/12-17:02 |
| 記事番号27345へのコメント 小松亀一さん、 とても貴重な情報ありがとうございます 非常に残念ですね TSEの使用感を他にも色々お聞きしてみたいです プレビュー以外はいいのですか？ >プレビューで印刷内容を確かめないで、印刷することは出来ません。 プレビュだけであれば、逃げ道はありそうに思います PDF化するとか | |||
| 27355 | Re:６０万件のデータを扱えますか | 宮城 | 2004/08/12-19:20 |
| 記事番号27352へのコメント 小松さん、尾形さん、こんにちは。 普通の共有なら、クライアントがプレビューかけて影響が出たなんて 意識したことないですが、TSE+Citrixでそんなことが起きるのですか？ そして、K3の回答があれだけ？ ちょっとアンビリーバブルです。 もしそうなら、プレビュー用のフォーム作るか（めんどくさそうだ！） TSE+Citrixがどんなもんかわかってないんで想像になりますが、 メインはノーマル桐で TSE+Citrix系は事務所外アクセス用のコピーみたいなものを置くといういささか 「情けない！！！」構成で考えてみることになろうかと思います。 いっそ、都度必要ファイルだけ送らせてモバイルパソコン内に擬似事務所環境作るか、 アウトプット専用データ作らせてそれを送らせるか、 追加出費限りなく「ゼロ」プランのほうが実用的かも。 # さあ他の方の感想はいかがなもんでしょうか？ | |||
| 27357 | Re:６０万件のデータを扱えますか | 小松亀一 | 2004/08/12-20:27 |
| 記事番号27352へのコメント 尾形さん、おばんでございます（宮城県の”こんばんは”です）。 >TSEの使用感を他にも色々お聞きしてみたいです >プレビュー以外はいいのですか？ プレビューでつまずき余り使用していないのですが、処理速度がアップすることは間違いありません。 師匠【多遊】さんに「デジカメde同時プリント」の向こうをはった「桐de同時プリント」なる 画像データベースシステムを作って頂き、訴訟の証拠となる写真撮影報告書等を桐で作っていますが、 １枚1.2Mもの画像ファイルを１０数行に貼り付けたフォームでのレコード移動或いはレポートのプレビューは、 モターっとした感じで結構時間がかかるところ、TSE桐の場合はピタピタと動きます。 当事務所のデータは全てサーバーパソコンに置き、各ライアンとパソコンからアクセスしますが、 画像データをクライアント側に一旦に運ぶのに時間がかかります。 しかし、TSE桐の場合は、画像データをサーバーに置いたままで処理しますので、 自分のパソコンに置いたまま処理するのと同じ感覚ですね。 データが大きくなる程、処理速度の差が大きくなり,TSE桐の威力を発揮してくれます。 >>プレビューで印刷内容を確かめないで、印刷することは出来ません。 >プレビュだけであれば、逃げ道はありそうに思います >PDF化するとか うーーん、いちいちPDF化するのも面倒そうですね。 当事務所の印刷確認コマンドボタンは、 当該必要レコードを絞り込み、 必要レポートをレポート印刷 絞り込み解除 ３行だけの単純なモノですが、この中にPDF化コマンドを手続き実行コマンドでかませると言うことでしょうか。 ただPDF化作業にCPUが加重負担にならなければ良いのですが。 | |||
| 27360 | Re:６０万件のデータを扱えますか | 小松亀一 | 2004/08/12-20:49 |
| 記事番号27355へのコメント 宮城さん、おばんです。 >普通の共有なら、クライアントがプレビューかけて影響が出たなんて >意識したことないですが、TSE+Citrixでそんなことが起きるのですか？ そうなんです。 まさか、こんなことになるとは予想もしておりませんでした。 私の理解が間違っているかも知れませんが、TSE桐の構造は、 各クライアントパソコンは、単なるキーボードになるだけで、桐の立ち上げ 及びファイルを開き、編集等の作業は、全てサーバーパソコンで行います。 そのためサーバーパソコンのＣＰＵにかかる負担が大きくなるところ、 特にプレビューは、出来るだけ速やかにプレビュー画面を表示するため、 仕様として可能な限りＣＰＵに負荷を掛けて実行するとのことです。 そのためそれでなくても負担の大きいサーバーパソコンのＣＰＵの負担が 誰かのプレビューにより益々大きくなり、他のクライアントでは、 動きが鈍くなるとのことです。 >そして、K3の回答があれだけ？ >ちょっとアンビリーバブルです。 真面目な話し、一応、法律専門家の端くれとして申し上げますと、 このような症状を全く知らせないで販売した場合、 商品の瑕疵（その物が当然有すべき性質を有しないこと、取引上普通に要求される品質が欠けていることなど、 不完全な状態）を理由に損害賠償請求が認められる可能性が高いと思います。 しかし、宮城さんなど名人各位にご指導頂き、今や桐無くしての事務処理は 全く考えられない程桐から大きな恩恵を受けており、こんな便利なソフトを 作ってくれた会社を訴えるなんてことは到底出来ません。 >もしそうなら、プレビュー用のフォーム作るか（めんどくさそうだ！） これは私も考えましたが、とても面倒でやれそうもありません。 >TSE+Citrixがどんなもんかわかってないんで想像になりますが、メイ >ンはノーマル桐で TSE+Citrix系は事務所外アクセス用のコピーみた >いなものを置くといういささか「情けない！！！」構成で考えてみる >ことになろうかと思います。 実は桐とスターファックスを組み合わせた使い方もして、ＦＡＸ送付は 殆どこれでやっているのですが、これはTSE桐では使えないことが判明し、 これもTSE桐使用を諦めた理由の一つです。 せめて管理工学さんでプレビューの問題を解決してくれれば、 使いたいところですが。 | |||
| 27361 | Re:６０万件のデータを扱えますか | 小松亀一 | 2004/08/12-21:21 |
| 記事番号27355へのコメント 宮城さん、おばんです。 >そして、K3の回答があれだけ？ >ちょっとアンビリーバブルです。 済みません、管理工学の名誉のため補足します。 以下のようなアドバイスは頂きました。 （引用開始） Ｑ．何かアドバイスはありませんか？ Ａ．印刷プレビューに時間が掛かる場合の要因となるポイントを記します。 これらの条件が多く含まれていれば、遅いのも当然と云うことになります ので、運用やデータの持たせかたに工夫を加えるなどしてください。 文章中に「遅くなる」と記しますが、体感でその差が感じられるかどうか は不明です。1/100秒単位で「速いか遅いか」差を厳密に述べていますの で、対処してみても結果が感じられないことも予想されます。 できるだけ数多くのポイントを当たってみてください。 【ポイント】 ・桐が利用しているメモリに余裕が無い。 →ファイルサイズやデータ量が大きい表を扱っていませんか？ オペレータ２人のときと３人のときとで差が出たりしませんか？ ・表を共有している場合は専有のときより遅くなります。 →他のオペレータの手を休めてからプレビューをするのとしないのとで 実行時間に差が出るか？、確かめてみてください。 ・利用するフォントの数が多いと遅くなります。 →ＭＳ明朝やＭＳゴシックなど１種類だけに絞ってみてください。 ・単票レポートより複合レポートのほうが時間が掛かります。 →定義内容に因りますが、同じページ内に複数の表データを印刷するよ うな複合レポートは性質上どうしても時間が掛かります。 ・＃表引きを使ったオブジェクトを多用すると遅くなります。 →同時に扱う表が増えるので同然なのですが...。さらに表引きする表の ファイルサイズが大きかったり、共有で開かれていたりすると、より 遅くなります。 ・図形やバーコードオブジェクトを多用すると遅くなります。 →イメージファイルを読み込んだり、読み込んだイメージを画面に表示 するため拡大縮小したりしますので、どうしても時間が掛かります。 イメージファイルが大きいほど顕著に現れます。 ・罫線を多用すると遅くなります。 →実線以外の飾り罫線を多用すると遅くなります。 ・明細ページ以外にマスターページなどを利用していると遅くなります。 （引用終了） 当事務所使用レポートは、ポイントとして述べられたこと殆ど全てにあてはまります。 例えば複数表からの表引きを多用しており、当然、表引き対象表は、共有で開かれています。 又債権者一覧表等の表モノは、全て罫線が多用されています。 頁数表示のため、マスターページも多用しています。 しかし、これらは全て便利に使うために必要不可欠で、今更使用を止めることは不可能です。 何よりもノーマル桐で問題なく使えていたモノが、TSE桐では使えないとなったら、正に「使い物にならない」商品です。 ここのところは、管理工学においては、キッチリ自覚して頂かないと困ります。 と繰り返し、執拗に、厳しい意見を述べてしまいました(^^;)。 | |||
| 27364 | プレビューの代りに | 佐田 守弘 | 2004/08/12-23:29 |
| 記事番号27357へのコメント 小松亀一先生 お久し振りです。 富士ゼロックス社の製品で、DocWorksというソフトがあります。 簡単に言えば、イメージ形式で文書管理を行うソフトです。イメージ形式と言っても、 全てグラフィックスデータに変換するのではなくて、pdfと同じ様に、文字を埋め込んだイメージ形式の文書です。 このプリンタドライバに印刷出力すると、ビジブルなイメージ文書ができます。 私はこのプリンタドライバを通常使うプリンタにしてあり、全てひとまずここに印刷します。 全頁を画面上で確認してから、このイメージ文書をプリンタに 出力すれば、プレビュー以上に間違いのない確認ができます。 イメージ文書の作成は、pdf出力よりも速いと思います。 CPUの負荷がないという事にはなりませんが、桐からのpdf出力や、 acrobatでのpdf出力よりは軽い様です。 ●桐からのpdf出力 桐からのpdf出力が可能ではあるのですが、写真を入れたレポートをpdf出力すると、 写真の原画のファイルをそのままpdfに埋め込んでしまう様ですね。 私も1枚1.2MBの写真を数十枚貼り込んだ写真帳を使っていますが、 これをpdf出力した所、pdfが数十MBものサイズになってしまいました。 多分、小松先生のもA4に１ページに３枚の写真と説明文章が付いたような形かと思います。 この程度のサイズの写真であれば、原画は原画として残しておくとして、 桐で印刷するデータには、必要充分なピクセル数にリサイズしたものを使った方が軽くなります。 多分横幅で、1024〜1280ピクセル程度で充分かと思います。 更に付け加えれば、説明文を書き込むためにフォームを使っているのではないかと思いますが、 フォームに表示する写真は更にリサイズして小さくしたものを使うと、スクロールが軽くなります。 私は320×240ピクセル程度のサムネイルを作って、入力フォームの表示に使っています。 佐田守弘(KS-00119) | |||
| 27371 | Re:６０万件のデータを扱えますか | アックン | 2004/08/13-12:18 |
| 記事番号27360へのコメント 小松亀一さん、こんにちは。お久しぶりです。 >実は桐とスターファックスを組み合わせた使い方もして、ＦＡＸ送付は >殆どこれでやっているのですが、これはTSE桐では使えないことが判明し、 STARFAXのイントラネット型があるみたいですが、これは役に立ちませんか。 http://www.megasoft.co.jp/wsf/index.html 関係なかったら、すみません。流してください。 アックン(=^・^=) | |||
| 27384 | Re:６０万件のデータを扱えますか | 小松亀一 | 2004/08/14-05:46 |
| 記事番号27371へのコメント アックンさん、おはようございます。 いつぞやは関数問題等で大変お世話になりました。 >>実は桐とスターファックスを組み合わせた使い方もして、ＦＡＸ送付は >>殆どこれでやっているのですが、これはTSE桐では使えないことが判明し、 > >STARFAXのイントラネット型があるみたいですが、これは役に立ちませんか。 >http://www.megasoft.co.jp/wsf/index.html 早速、当事務所システム保守業者に調査して貰います。 保守業者の話では、スターファックスとの関係は、シトリックス経由では 使えないとのことでしたので、何となくこれで使えそうな感じもします。 ただこれで仮にスターファックスが使えるようになっても、 プレビュー問題が解決しないとどうにもなりませんが。 情報提供有り難うございました。 | |||
| 27385 | Re:プレビューの代りに | 小松亀一 | 2004/08/14-06:19 |
| 記事番号27364へのコメント 佐田先生、おはようございます。 >富士ゼロックス社の製品で、DocWorksというソフトがあります。 >簡単に言えば、イメージ形式で文書管理を行うソフトです。イメージ形式と >言っても、全てグラフィックスデータに変換するのではなくて、pdfと同じ >様に、文字を埋め込んだイメージ形式の文書です。 >このプリンタドライバに印刷出力すると、ビジブルなイメージ文書ができます。 DocWorksは以前購入を検討していましたが、うやむやになり、結局、最近、 リコーのコピー・プリンタ・ＦＡＸ兼用機購入に当たり、同社がDocWorksに対抗して出している リドックスとか言うソフトも導入しました。 ＦＡＸ文書が画像ファイルで入ってくるので、いちいち印刷されず良いものだと思って購入したのですが、 必要ファイルはいちいち印刷しなければならないのも面倒なものだという感想です(^^;)。 これと桐をどのようにリンクさせるかが今後の課題です。 例えば裁判で相手方からＦＡＸで送付される準備書面等をテキスト化して、 当方の準備書面.tblに取り込んでデータベース化を予定しています。 >●桐からのpdf出力 >この程度のサイズの写真であれば、原画は原画として残しておくとして、桐 >で印刷するデータには、必要充分なピクセル数にリサイズしたものを使った >方が軽くなります。 >多分横幅で、1024〜1280ピクセル程度で充分かと思います。 裁判で使用する写真撮影報告書は元々は銀塩写真を貼り付けて作っていたのですが、 桐化してからは、原則、ピクセル数は忘れましたが、画素数３Ｍで１枚1,2Ｍ程度を使用しています。 この程度でないと銀塩写真に代わる印刷使用には耐えられないからです。 >更に付け加えれば、説明文を書き込むためにフォームを使っているのではない >かと思いますが、フォームに表示する写真は更にリサイズして小さくしたもの >を使うと、スクロールが軽くなります。 >私は320×240ピクセル程度のサムネイルを作って、入力フォームの表示に使っ >ています。 写真の桐tblへの取込用にはサムネイル版を使用しておりますが、 上述の通り印刷は銀塩写真に代わる精細画が必要で1.2M程度の画像を使っており、 これをプレビューする必要があり、結構時間がかかります。 色々情報提供有り難うございました。 | |||
| 27386 | Re:プレビューの代りに | 原山 正洋 | 2004/08/14-10:06 |
| 記事番号27385へのコメント 小松亀一さん おはようございます。 >印刷は銀塩写真に代わる精細画が必要で1.2M程度の画像を使っており、これを >プレビューする必要があり、結構時間がかかります。 レポートをコピーして、画像部分だけサムネールを指定する。 そしてこちらをプレビューするだけでも相当短縮できるのでは？ だんだん主題から離れていきますが・・・ | |||
| 27388 | Re:プレビューせずにプリントアウトは問題ないのでしょうか？ | HERB | 2004/08/14-14:00 |
| 記事番号27345へのコメント 小松亀一さん、HERBです。 >>しかし、文書作成の場合、プレビューで印刷内容を確かめないで、印刷する >ことは出来ません。 >プレビューするなと言うことは使うなと言うことと同じで、結局、大枚を >はたいて導入した桐forTSE及び関連のシトリックス或いはTSE桐専用サーバー >機は、埃をかぶって眠ったままです。 > プレビューせずにレポートを直接プリントアウトすれば問題なく行えるのでしょうか？ 以下、シェアウェアソフト、体験版もございますので一度試してみて下さい。 http://www.nsd.co.jp/share/fineprint/function.html > FinePrintの機能、特色 > Windowsプリンタドライバとして動作 > 縮小印刷機能 > まとめ印刷 > 印刷プレビュー > 印刷ジョブのファイルへの保存 などなど。 TSE桐には興味があります、レポートのプレビューでこんな問題が出るとは思ってもみませんでした。 上記、シェアウェアソフトの負荷がどれくらい掛かるか判りませんがよろしければ結果をお知らせ下さい。 | |||
| 27398 | Re:６０万件のデータを扱えますか | hidetake | 2004/08/16-00:18 |
| 記事番号27345へのコメント CPU の使用率について、ちょっだけ調べてみましたが 桐はレポートの方はともかく、一覧表の方は何か問題を抱えているかも知れませんね！？ シトリックス環境は無いので、Windows Server 2003 のリモートメンテナンスモードではどうであろうかと 見てみましたが、レポート環境はでは一瞬なので、それほどでは無いなぁ〜と思ったのですが、 一覧表で表示させた場合は、状況によっては 100% 近くを保持する状態が続いたので、 ローカル環境でも調べてみたのですが、一覧表のプレビューを表示した状態で、 例えば「次のページ」を表示させてマウスをそのままにしていると 1CPU 環境では 98%前後を 2CPU 環境では50% 前後を維持し使用率が落ちない状態になります。 どうも、一覧表でプレビューを行っている状態で ツールチップが表示されるような状態(ツールバー アイコン上にマウスカーソルがある状態)ですと何故か CPU をフルに使い切ってしまうようです。 なお、レポートのプレビューではこのような現象は 発生しないようです。 ひょっとしたら、TSE 環境に関わらず、何か問題を 抱えているのかも知れないですけど、TSE 環境でこれが 顕著に現れるのかも？知れません。 あと、メタフレームのセットアップはちゃんとした 専門家に頼むと相当な金額が取られてしまうようですが、 チューンナップもそれなりの知識が必要なのかも知れません。 その辺のノウハウを K3 が持っているのかどうかまではわかりませんが？・・・ それと、取りあえず次のような情報もありますので 参考まで！ ターミナル・サービスでアプリケーションが正しく動かない http://www.atmarkit.co.jp/fwin2k/win2ktips/458ts2003err/ts2003err.html > ターミナル・サービス・セッションに割り当てられる > デフォルトのメモリ領域を増やすには、レジストリの値を変更すればよい。 > > 変更するのは、以下のサブ・キーにある、下表のエントリである。 > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management 確かに、ローカル環境では 40MB 以上使うような同じ 表を開いてプレビューを行っても、リモートメンテナンスメードでも15MB とか 20MB 程度までしか メモリは使わないで Windows Server 2003 は処理していました。 細かいチューニングもいろいろあるのでしょうね・・・ # 一覧表のプレビューでの CPU 使用率の件は一般ユーザ # も直してもらった方が良いですね！ | |||
| 27399 | Re:６０万件のデータを扱えますか | hidetake | 2004/08/16-06:53 |
| 記事番号27398へのコメント >CPU の使用率について、ちょっだけ調べてみましたが >桐はレポートの方はともかく、一覧表の方は何か問題 >を抱えているかも知れませんね！？ 更にわかったおもしろい現象です。 これも Windows Server 2003 のリモートメンテナンスモードの事なので、アプリケーションモードや、 シトリックス環境とも違いますし、レポートの話では無く 一覧表印刷時のプレビューの状態の事です。 Windows Server 2003 のリモートメンテナンスモードは、 そのままで２ユーザまでは同時ログオンできるようになっているのですが、 １ユーザが「桐9-2004」で表を開き一覧表でプレビューを行っている状態(CPUの使用率は落ちている状態)で、 別のパソコンからターミナルサーバにログオンすると、今まで下がっていた CPU の使用率が一挙に上がり 「桐9-2004」が一挙に CPU を独占状態で使うようになってしまうようです。 単に桐を使おうとか関係なく、別のユーザがログオンしただけ(他のアプリケーションも何も 起動もさせていない状態)で、今まで下がっていた「桐9-2004」の CPU 使用率が跳ね上がります！ (-_-; そして、最初にログオンしていた方の桐のプレビューを 何か操作すると、あがっていた CPU 使用率は通常の値におちます。 なので１ユーザ目がただプレビューした状態で操作を放っておくと、他のユーザは迷惑してしまうようです。 この現象は一覧表印刷のプレビューだけなのかなぁ〜？ 他にも同じ症状が発生するとつらいですね！ (;_;) ただ、これも K3 の使用条件に無い Windows Server 2003の事なので、 Windows 2000 Server やメタフレーム環境でどうなるかまではわかりません。 (^^ゞ それと、ノーマルな「桐9-2004」を Windows Server 2003 のリモートメンテナンスモードで ログオンして使うと２番目のユーザの桐を立ち上げようとすると --------------------------- 桐 --------------------------- 既にターミナルサービスクライアントかターミナルサーバ上で桐が実行されています. この桐はターミナルサービス環境での複数実行をサポートしていません. 桐の起動を中止します. --------------------------- OK --------------------------- と表示されて起動できないようになっていますね！ (^^; １つログオンした状態では、そのデスクトップ上では複数の「桐」を立ち上げる事は一応可能なようです。 なので、１クライアントだったら複数「桐」起動方式で 無理矢理プレビューを使うシステムも一応は実行可能なのかな？ | |||
| 27411 | TSE桐のプレビュー | 小松亀一 | 2004/08/16-21:30 |
| 記事番号27398へのコメント hidetakeさん、原山さん、HERBさん、おばんでございます。 TSE桐のプレビュー問題について色々貴重なご提言有り難うございます。 前の投稿は誤って送ったものですので、幅田さんにおかれましては、 削除して頂ければ幸いです。 当事務所の文書印刷は殆どレポートを利用しており、そのレポートには 複数表のデータを条件選択関数と表引き関数を相当程度入り組んで利用して作っております。 一覧表印刷は、会話処理以外では全く利用しておりません。 そのためTSE桐利用中には一覧表印刷プレビューをかける機会はなく、 レポートプレビューの時に問題が発生しました。 恐縮ながらレポートプレビューの場合のCPUの使用率を調べて頂ければ幸いでした。 素人考えでは、一覧表印刷でもレポートでも同じ結果ではないかと思っております。 hidetakeさんには、スターファックス利用等でも貴重なご提言を頂いておりますが、 恐縮ながら、ＯＳ、システム等の素人である私には理解不能な記述も多く、 当事務所保守業者にこの一連の記述を読んで貰って対策の余地があるかどうか検討致します。 HERBさんご提案についても業者に検討して貰います。 原山さん、ご提案はおそらく画像付レポートの迅速化には役立つと思います。 ただ、画像付でない一般文書が圧倒的に多く、これが解決出来ないと TSE桐の実用化は出来ないと思っているところです。 何れにしても貴重なご提言に感謝申し上げます。 | |||
| 27412 | Re:TSE桐のプレビュー | 原山 正洋 | 2004/08/16-22:36 |
| 記事番号27411へのコメント 小松亀一さんこんばんわ >ただ、画像付でない一般文書が圧倒的に多く、これが解決出来ないとTSE桐 >の実用化は出来ないと思っているところです。 これは多分初耳でしょう。 これなら、それこそ文章の正確なことを確認したい だけのことだと思いますが、何故、それをプレビューで確認しなければならないのでしょうか？ かなり改善の余地は潜んでいるようにお見受けします・・・ | |||
| 27413 | Re:TSE桐のプレビュー | hidetake | 2004/08/17-03:12 |
| 記事番号27411へのコメント >恐縮ながらレポートプレビューの場合のCPUの使用率を調べて >頂ければ幸いでした。 >素人考えでは、一覧表印刷でもレポートでも同じ結果ではないか >と思っております。 これは > レポート環境はでは一瞬なので、それほどでは無いなぁ〜 > と思ったのですが、 と書いたとおり、私のところのふつうの桐では特に問題あるような CPU を食うような現象は確認できませんでした。 テーブルを開いたり、他の重たい処理を行うのと同じぐらいの時間しか CPU の使用率を食うような事は残念ながら確認できませんでした。 ただ、一覧表のプレビューに関してはふつうの桐でもバグらしき現象は確認できました。 それと、ktree からの回答のうち >・桐が利用しているメモリに余裕が無い。 と言う問題に関しては、チューニングを行わない限りどんなにメモリを積んでいても 一定限度のメモリしか使わないような仕組みにターミナルサーバの仕組みがなっているようなので、 その辺の問題であれば、サーバの調整や、あるいはメタフレーにもいろいろなチューニングの箇所はあるのでしょうから、 それを調整する必要があるのかも知れないという、 検討の余地が先のリンクを見ると見られたので書きました。 いずれにせよ、私のところにはメタフレームも、それに対応した「桐」も無いのですが、 最終的にはそれで確認するしか無いと思います。 業者さんと実際の使用率やメモリの使用状況、それに簡単な 軽いファイルでのプレビューではどのような現象になるのか 調べて kthree にプッシュして行く事も必要だと思います。 # スターファックスに関しては TIFF ファイルさえ作れば # 良いのですよねぇ！ とか、それこそ PDF に落としてし # まったらそのまま送信すれば良いのですよね・・・ と # 思いながら・・・ (^^ゞ | |||
| 27414 | Re:TSE桐のプレビュー | hidetake | 2004/08/17-03:31 |
| 記事番号27413へのコメント それと、「桐 for TSE(-2004)」がちょっとした重い処理など、 CPU を食う作業で、そんなに他のユーザに大きな影響が出るのならば、 ターミナルサービスで複数のユーザが使うには無理があるのかも知れませんね！？ 桐はイベント内で遅延コマンドが使えないので kthree 提供のサンプルなどにも単純ループの 一番 CPU を食うような 仕組みで無理矢理 遅延を行っている場面も見かけます。 そんな処理を含んだシステムだと、一発で複数ユーザでの使用では問題が出るという事になります。(よね！) このような問題を 無理矢理 ハード的な性能で補おうとしたら、 いくら CPU パワーを上げてもダメで、CPU の個数を増やすのが一番なのかも知れません？ Dual CPU とか、もっとそれ以上の CPU を積めるサーバとか・・・ | |||
| 27415 | Re:TSE桐のプレビュー | 小松亀一 | 2004/08/17-08:07 |
| 記事番号27412へのコメント 原山正洋さん,おはようございます。 >これなら、それこそ文章の正確なことを確認したい >だけのことだと思いますが、何故、それをプレビュ >ーで確認しなければならないのでしょうか？ 実は、「自称桐大好き人間」の私の事務所の文章作成は殆ど全てと言って良い程桐で行い、 いわば桐をワープロソフト代わりとしても使用しています。 メールを除けば当事務所作成文書の９９％は桐です。 「一文書一ファイルから一レコードへ」の標語で、Ａ４版１枚で済む通知書の類から時に数万字に及ぶ 裁判での準備書面等全て桐でデータベース化しながら作成しております。 尚、一レコード４０００文字の制限は、定義位置と高さを自由にした一覧表レポートで簡単に解決できました。 >かなり改善の余地は潜んでいるようにお見受けします・・・ 上記の通りワープロ代わりにも使っているものですから、印刷状態の確認が必須です。 フォームとレポートによる印刷状態とは全く無関係に作っているため、 フォームだけでは、印刷状態が全く不明です。 そこで、小見出しや、改行の位置や場所等が、印刷する場合、どの辺にくるか確認する必要があります。 宮城さん仰るようにレポートと同じ形式でフォームを作る方法もあるでしょうが、 パソコンによって、又、２０００とＸＰでも解像度が異なるため、 あるパソコンでは、同じようになっても他のパソコンだとずれる場合も生じ、 これらも考慮したレポート同形式フォーム作成は大変です。 等々の事情でプレビューが不可欠な状態です。 ノーマル桐では、テンクライアントでファイルを共有使用しており、 プレビューをかけても全く問題がないのに、TSE桐だとダメになると言う点が問題でした。 | |||
| 27416 | Re:TSE桐のプレビュー | 小松亀一 | 2004/08/17-08:11 |
| 記事番号27414へのコメント hidetakeさん、おはようございます。 >このような問題を 無理矢理 ハード的な性能で補おうとした >ら、いくら CPU パワーを上げてもダメで、CPU の個数を >増やすのが一番なのかも知れません？ >Dual CPU とか、もっとそれ以上の CPU を積めるサーバとか・・・ 大変、有益な情報有り難うございました。 hidetakeさんの一連の書込を当事務所システム保守業者に見て貰い、 更に研究して貰おうと思っております。 大変恐縮ですが、島さんという方が当事務所保守をしており、TSE桐、 シトリックス設定等をやって貰いましたが、 質問が行くかも知れませんので宜しくお願い申し上げます。 | |||
| 27418 | Re:TSE桐のプレビュー | hidetake | 2004/08/17-16:51 |
| 記事番号27416へのコメント >大変恐縮ですが、島さんという方が当事務所保守をしており、TSE桐、 >シトリックス設定等をやって貰いましたが、質問が行くかも知れませんので >宜しくお願い申し上げます。 う〜む、細かい話になるとシトリックスとか見た事もさわった事も無いですしね・・・ シトリックスの自体の設定(チューンナップ)もいろいろあるだろうし、 サーバ自体の設定で言えば、まずはログオンしているユーザは 同じユーザ(名)で複数ログオンしていないかとか、違うユーザ(名) でログオンした方がバッティングは出ないらしいとか、Windows Server も まさか Active Directory とか有効にしていないですよね！ とか(Active Directoryを有効にすればディスクキャッシュが強制的に無効になるので、 そのディスク上のファイルに関してはパフォーマンスが出なくなる)とか、いろいろあるだろうけれど、 そんな話は桐とはかけ離れてしまいますし・・・ # 知り合いの印刷屋さんが、VB + SQL Server で組まれたシステム # で、電話回線を通じ遠隔地から本社への接続を行っていたけれど # 結局パフォーマンスが得られず、メタフレームの方が効率よく # 処理できるだろうと、それを勧められたけど(元々 VB のシス # テムはメタフレーム対応をうたっていた)、２クライアントで # 結局、サーバ込みで NEC からは 300万円での見積もりでした。 # もう１社は２百数十万円ぐらい。 # あまりに高いので私のところに相談されたのですけれど・・・ # 私自身メタフレームの事を知っているわけでも無いですけど # 知り合いという事でですね。 # # 結局、システムのサポートの関係もあって、それを導入したのだ # けれど・・・ と言う話もメタフレームの XP が出る直前ぐらい # にありましたかね！？ # まぁ〜私にはメタフレームは高いし設定料もすごい金額だなぁ〜 # って言う意識はあります。 # (チューニングも難しいのだろうかとか？) # # それでもシステム側は特別なものではないし、一般のアプリケー # ションも使えるわけだし・・・ # でも、桐ってそれに対応した特別なバージョンが必要なのです # よね！？ メタフレームは高いし桐自体も高い特別なバージョン # が必要なのですよね！ 何故！？ # それでパフォーマンスまで得られないと最悪ですね！？って # 感じです。 # # メタフレームに関してはそのぐらいの知識しかないんです。 # | |||
| 27419 | Re:TSE桐のプレビュー | 小松亀一 | 2004/08/17-20:36 |
| 記事番号27418へのコメント hidetakeさん,おばんでございます。 >う〜む、細かい話になるとシトリックスとか見た事もさわった事も >無いですしね・・・ すみません、島さんは今日までお盆休みで、夕方仙台に帰ってから この一連の書込を読んで驚いたと報告電話がありましたので、 質問がここに上がるかも知れません。 ># でも、桐ってそれに対応した特別なバージョンが必要なのです ># よね！？ メタフレームは高いし桐自体も高い特別なバージョン ># が必要なのですよね！ 何故！？ ># それでパフォーマンスまで得られないと最悪ですね！？って 正に私の言いたいことをピッタシ正確に言って頂き、有り難うございます(^^)。 挙げ句に、プレビューが上手くいかないのは貴方のレポートの構成が悪いからだとしか取りようがない 指摘をされると益々頭に来ます。 幅田さん、この私の書込は、愚痴ばっかりで全然ためにならない話しで申し訳ございません(^^;)。 | |||
| 27421 | Re:TSE桐のプレビュー | hidetake | 2004/08/17-21:21 |
| 記事番号27419へのコメント >># それでパフォーマンスまで得られないと最悪ですね！？って さて本題に戻って？ 印刷レビューの負荷で他のユーザの操作に 多大な影響を及ぼすのなら(この原因がプレビュー操作における データ操作の負荷だとして)、６０万件のデータを扱った場合に 索引の使えないような検索であれば、結構な CPU パワーも必要としますよね！ そのような状況では他のユーザにどうのような影響を及ぼすのでしょうか？ プレビューの影響が何かバグっていてこのような状況が発生するなら、 それを改善すれば、ユーザ数がある程度あっても使い物になるのかも知れないけど、 重い処理を行った場合に、それを適度に分散して、 複数のユーザでも効率よく使用できるような仕組み作りができていないとすれば、 ちょっと重たい仕事をするだけで 「桐 for TSE(-2004)」は複数ユーザでの同時使用は使い物にならない！ と言う事にはならないのでしょうか？ kthree の方、もしくは VAR業者さんや公認SE の方教えて下さい。 | |||
| 27422 | Re:TSE桐のプレビュー | hidetake | 2004/08/17-22:10 |
| 記事番号27421へのコメント もう少しだけ書いておきます。 :-) 「桐」の根本的な問題も含んでいるような気もします。 メタフレームを使うような環境やユーザのところでは 大きなデータやファイルを扱うようなシステムとして データベースがあると思うが、このような環境では 「桐」のようなデスクトップデータベースのような クライアントとデータベースエンジン、それにファイルのファイルの置き場所が一緒というような使い方は 多くの場合されておらず、フツーにはクライアント・サーバ方式で、クライアントとデータベースサーバ (エンジンを含む)が別になっているはずである。 従って、この部分の負荷はターミナルサーバから切り離され、 この部分の負荷の影響は免れる。 データベースサーバは効率よくクライアントからの 負荷を分散させ処理してくれる仕組みをも包含してくれる事になる。 逆に「桐 for TSE(-2004)」はこれを一緒に置く事に よりネットワークの負荷が減らされるという事を うたい文句にセールスしている(しなければならない ような桐の作りのため)。 これが一番の敗因では無かろうか！ これは「ファイルメーカーPro」が普通のバージョンのもので、 MetaFrame & ターミナルサービスでの使用をサポートしているにも関わらず、 ピアツーピアでの使用方法をサポートから外し、 サーバを置いて使う事を前提としているのは、この辺の悪影響を考慮しているからでは無かろうか？ # 某所の VB + SQL Server のシステムでもデータベース # サーバと MetaFrame サーバは別のサーバとして独立 # していて一緒に稼働させるような構成にはなっていな # かった。 「桐 for TSE(-2004)」の場合、CPU 負荷とネットワーク負荷のせめぎ合いで、 逆に CPU 負荷の影響をもろに受けるような悪影響のあるシステムとなっているのでは無いだろうか？ と・・・ | |||