InfoPath Dev

ご質問の中に「～でしょうか？」があまりに多くて、何を本当に聞きたいのか、何が 本当の問題なのかがちょっと把握しきれないので、直接の情報提供にならないかも しれませんが、InfoPath の発行、利用から「キャッシュ」の話につながると思うので 長くなっちゃいましたが、紹介させてください。  InfoPath の本来の使い方を理解していただくと、フォーム入力とキャッシュの関係が クリアになると思いますよ。 InfoPath には2つの機能がありますよね。 1) フォームをデザインする機能 2) ...

セキュリティ レベルは「自動的にセキュリティ レベルに設定する」を選んだ結果の「セキュリティ レベル」が何になっているかが重要で、たぶん「ドメイン」になっていると思います。 それは SQL データベースへのデータ接続を追加して、データ受信を行うようなセカンダリ データベースをフォームに組み込んだのではないかと思います。   このセキュリティ レベルは SharePoint にフォームを発行した直後の発行ウィザードで確認する ことができます。 「このフォームを開けません。このフォームはドメインのアクセス許可レベルが必要であり、、」の メッセージは、実は見たことがなかったのですが、もしやと思い、ドメインに参加していない PC から InfoPath ...

最初に、これだけの情報では何が発生しているかわかりませんし、たぶん、これ以上の情報を このフォーラムでもらっても有益な解決につながる情報をお渡しすることはかなり難しいと思います。 SharePoint が IE に表示するエラーメッセージはかなりおおざっぱ過ぎて、それだけだとなかなか 原因にたどりつくのが難しい場合がありますよね。 InfoPath の問題と SharePoint の問題（SQL なども含めたサーバー全体）の両方から問題の 切り分けをやっていくことになるのでしょうね。 サーバー側の SharePoint, IIS, SQL Server, Windows Server のエラーログ、イベントビューワー から手がかりがあるかもしれません。SharePoint ...

やはり、基本はタブで移動だと思うので、ヒントが表示されつづけることは ないので、だいじょうぶだとおもいます。 他のスレッドの話は時間があるときにそちらで。 でも、わからないものや、経験したことのないものにはコメントできません。 その点はご留意ください。 ご気分を悪くされると申し訳ないですが、あくまで時間のあるとき というのが、このようなフォーラムの基本です。ですので、ご自身のプロジェクトの 進行状況などで利用する場所、サービスを適切に選択してくださいね。 クリエ・イルミネート 沼口（講師ではありません・・・）

こんにちは。 ちょっと確認してみましたが、消し方はないみたいですね。 その「必須」と表示されるのは「なぜ必須なのか、何をいれなくてはならないのか」の ヘルプを表示するためのものです。それをコントロールのプロパティの [ユーザー補助] の [ヒント] で設定するのです。その内容がマウスオーバーでコントロールの 「ヒント」 として 表示されます。 必須のコントロールの場合 [ヒント] に何も入ってないと[必須]が表示され、もし、そこに 空白をいれても、今度は何も文字のないヒント（薄い黄色の四角い吹き出し）が表示 されます。 ちなみに [必須] でないコントロールでも [ヒント] にテキストを入力するとマウスオーバーで 表示できるようになります。 この [ヒント] ...

なんとか先がみえてきたようでなによりです。  まずは view1.xsl は参考として参照されたほうがいいと思います。実際に不要な <tr><td>...を 削除するには、InfoPath の[このフォームのデザイン]でレイアウト表が見えるわけですから、 そこで隣り合っている不要な複数のセル（＝テーブル）をドラッグして選択し、ツールバーの [セルの結合] をクリックして 1 つのテーブルにするだけで、かなりの数の不要なセル(テーブル)を 削除することができます。 その上で、再発行をかけるわけです。 なので、まずは標準の機能を使いこなすことを考えたほうがよろしいかと思います。

フォームの作成だけに絞った話になっていますが、フォームのデザインだけでなく 以下のようなこともありますので、ご参考までに。 http://technet.microsoft.com/ja-jp/library/cc261832.aspx ただ、1PCのクライアントからのテストの段階なので、まずはフォームのデザイン のような気がしますが、Forms Services/IIS が利用できるメモリなどもパフォーマンス に大きな影響を与えます。言い換えれば、1PC で解決してもサーバーの構成次第では 複数 PC の利用でパフォーマンスの問題が発生する可能性がある、ということです。 あと、フォームのデザインですが、ビューの中のフィールド（＝コントロール）の数だけ ではなく、MSDN ...

あくまで局所的な話なので、これがすべてではないでしょう、というのを前提にすると、 弊社の講師陣が受けた相談の中でパフォーマンストラブルの原因でよくあるのは 「一つのフォームにコントロールを張り付けすぎている」と聞いております。 解決策は「ビューでフォームをわける」ということであり、上記のテスト１で行われて いる「（初期ロードのための）空白のビューを追加する」ではないんです。 ブラウザは HTML で送られたテキストを解釈してレンダリングするわけです。レンダ リングする量が多ければその分そのフォームを表示するまで時間がかかります。 電子フォームソリューションとしての InfoPath + SharePoint ...

すでに参照済みかもしれませんが、以下などを参考にしてはいかがでしょうか。 InfoPath 2007 フォームのパフォーマンスの改善 (Microsoft MSDN サイト) http://www.microsoft.com/japan/msdn/office/2007/bb380251.aspx パフォーマンスについては本当にさまざまな要因があるので、この MSDN の 情報を元にひとつひとつチェックしていくことになるでしょうね。  システムにおいては使い勝手（もしくは開発の容易さ）とパフォーマンスは裏と表の ような関係になっている場合があります。InfoPath の Forms Services はまるで Web アプリケーションを Visual Studio ...

奥村さん、ありがとうございます。 WSSP を扱うに至った背景は、結局のところ InfoPath のトレーニングを提供している過程で、 汎用 クエリ Web サービスがあればずっと楽なのに、、、ということから、QDABRA 社と 提携を組ませていただきました。データ受信に関する制限（特にフィルタ）に関して言えば、 弊社のトレーニング コースの中ではこれまで以下の4つの解決方法を提示していました。 1) 部門（利用者）単位でのフォーム テンプレート カスタマイズ 部門・利用者により、データの絞り込みを行いたい場合、あらかじめその部門、利用者用の テンプレートを作ります。既定値にその部門名や利用者名をいれておくことで、データ接続 ウィザードで [SQL 編集] により where ...