I need to add a password for extracting PDF.
Dim FileName As String
Dim FilePath As String
FileName = Me.Full_Name & "_" & Me.ID
FilePath = "C:\Users\Desktop\" & Fil...
Private Sub タブ1_Change()
Select Case Me.タブ1.Value 'Value=表示されいるページ番号(0から始まる)
Case 1 '2ページ目
With Me.サブフォームコントロール1
If .SourceObject = "" Then .SourceObject = "サブフォーム1"
End With
Case 2 '3ページ目
With Me.サブフォームコントロール2
If .SourceObject = "" Then .SourceObject = "サブフォーム2"
End With
Case 3
'略
End Select
End Sub
hatenaさま ありがとうございます
勉強不足ですみませんでした
acReport, Me.Tag をそのまま使えばよかったのですね
難しく考えすぎていました OutputTo で対応いたします
本当にありがとうございました
F_PreViewChildMenu のTagプロパティにレポート名が格納されている仕様になってます。
よって下記のようなコードで共通に使えます。
レポートのレコードソースがテーブルかクエリなら、DoCmd.TransferSpreadsheet が使えます。
わさわざ質問のような面倒なコードを使う必要性はないです。
その場合も、レポート名は、Me.Tagで取得できます。
ただし、レポートを開く時にフィルターをかけていたり、並べ替えを設定していたりすると、それが反映されないので、それを反映させたい場合はまた、面倒なことになります。
hatenaさま お返事ありがとうございます
hatenaさまの「F_PreViewChildMenu」のフォームはありとあらゆるレポートの出力に利用させてもらっています
そのため OutputTo acReport ”レポート名” では 「F_PreViewChildMenu-1」 「F_PreViewChildMenu-2」といったように その特定のレポートごとにフォームを作らなくてはなりません、なので現在ひらいているレポートのレコードを取りたかったのです
りんごさま お返事ありがとうございます EXCELはACCESSで加工されたデータを、その時だけに必要な集計表や煩雑なレポートを作成するために利用しております
CurrentDb.QueryDefs(Me.RecordSource).SQL ありがとうございます フォーム上でのエクスポート設定を読んで勉強させていただきます
ありがとうございます
OutputToメソッドやTransferSpreadsheetメソッドでは駄目なのでしょうか？中には非推奨とするサイトもあるようですが、鵜呑みにせずに本当に駄目なのか慎重に判断でましょう。
コーディングの是非もありますが、Excelエクスポートの是非も気になります。そもそも、AccessとExcelの業務連携の必要性、何の為にAccessを導入しているのかと。
参考にするなら、下記サイトなんかはどうでしょう？
CurrentDb.QueryDefs(Me.RecordSource).SQL
ブログのコメント欄でも書きましたが、OutputToメソッドを使えば1行で済みますが、それではうまくいかなかったのでしょうか。
Q_案件 で一対多関係の多側のレコードのみ削除されて、一側のレコードは残っているということかも、と推測。
Q_案件 のSQLを提示してもらえますか。
hatenas様
解決しました。
ご助言いただきありがとうございます。
>> 9
>> 11
「選択クエリを直接開いて、レコードを1行手動で選択してDELETEした瞬間、一瞬画面がチラつき直ちに、削除したはずのレコードが復活した」という事ですが、「選択クエリを直接開いて、とあるレコードのフィールドを選択して値の変更を試した」結果は、どうなったのでしょう？慎重に確認するのであれば、クエリを直接開いてレコードを編集したら、テーブルも開いて確認します。
もうひとつ当て推量です。フォーム上に案件NO、売区、得意先IDなどのフィールドがあると思いますが、どれかに何かのイベントを設定していませんか？もし該当するものがあれば、フィールドに設定したイベントを全部offにしてみて下さい。
その上で、削除から一瞬で復活するか結果を教えて下さい。復活しなくなった場合、offにしたイベントのコードを保守義務に差し支えない範囲で、全部コピペして教えて下さい。
ググっていたら、こんなのがありました。下の方にスクロールすると、とある回答者がコード化したようです。内容の正しさまでは私にはわかりませんでした。他の人の意見も聞いて下さい。
一時的にONして確認しましたが、エラーは出てきませんでした。
もう少し詳しい情報が欲しいですね。
まず、データベースファイルはデータとそれ以外で分割していましたか。
データが丸ごと消えたとは、テーブルのデータ件数が0件になった、テーブルごと消えた、データベースファイルごと消えた、、、、どれでしょうか。
qd のパラメータを設定したのですから、qdをOpenRecordsetしてください。
参考になるか分かりませんがACCESS+SharePointの環境で
テーブルのレコードを選んで削除→消える
選択クエリ（結合なしで抽出条件だけ）のレコードを選んで削除→クエリ上では消える、テーブルでは消えず、クエリを開きなおすとデータが消えていない
というのは経験したことがあります
深く検証する状況になかったのでこれ以上のことはわかりませんが、基本に立ち戻って最小構成のテスト用DBからどの状況でその現象が発生するのか確認したらいいと思いますよ
ご回答ありがとうございます。
Q_案件にてレコード削除した際も同じ現象が起きました。
一度削除される（削除しますか？のポップアップ⇒はいで、レコードが見えなくなる）のあとに更新ボタンを押すと復活していました。
フォームのレコードソースに、Q_案件 というクエリが設定されいるということですか。
このQ_案件を直接開いてレコード削除したときは、削除できますか。
また、データの更新はできますか。
結合することで、削除したものが復活するということはありえません。
結合や主キーの設定が間違っていると更新できない（当然削除もできない）クエリになることはあります。
例えば、セルを編集してセにしたい。
セルのルを消したのに、うっかりESCキー押してしまい復活しちゃった。
これに近い事が起きていませんか？当て推量ですが、何某かのイベントが発動して、編集が確定されずにキャンセルされているとか。
エラーメッセージの表示設定を一時的にONにして、リレーションシップの連鎖削除が原因と出てくるか試してみましたか？(フォームで削除出来ないものが、テーブルで直接削除出来るとは考えにくいんですが、念のため確認して下さい。)
名前が変わってました…どんぐりず＝風（質問者）です。
この修正について社内で後回しにしており、改めての質問になり申し訳ありません。
リレーションシップで、T_案件が「一対多」の「多」側になっていることがあります。そこで連鎖削除等の３つのチェックボックス全てにチェックを入れているのが問題でしょうか…？勝手な推測で失礼いたします。
これで削除はできませんでした。（一旦できるのですが、更新すると復活する）
色々と入り組んでいてどこまで説明すれば良いのかわからないのですが
F_案件の元データがQ_案件で
キーとなる「案件NO」からQ_案件で
「T_案件リンク」と「Q_サブ保守」に結合しています。
その他キー以外の
「売区」から「T_売区」
「得意先ID」から「Q_得意先」に結合しています。
色んな所と繋がっているので、削除しても復活してしまうのかと考えています。
全体的にボリュームのあるデータなので全て説明するのが難しく
適当な情報をピックアップしてしまい申し訳ありません。
リレーションシップは昔組んでいたらうまく行かない所があって
中途半端に組んでしまっています。
全部のテーブルを入れて、きちんと組むべきでしょうか。
ご回答ありがとうございます。該当のチェックボックスにチェックは入っていません。
入れた方が良いということでしょうか？（別の場所で色々不要なメッセージが出て驚かせてしまうので外した記憶があります）
MSの公式ドキュメントだと、下記にそれらしき記述がありますね。
あと、Now() とか結果が固定されていない関数などは使えないことからも更新時に結果を保存していて、呼び出し時に再計算はしていないと推測できます。
最後のリンク先は知らなかったので非常に参考になりました。
ただ、リンク先でも言及されてますが、インデックスを設定できないので、メリットは大きく減少していると思います。
パフォーマンスアップに関してもリンク先では200万行で実験していますが、私自身はこのような大きなデータを扱うことはないので、たぶん使用することはないだろうと思います。
おお hatena 様、いらしてくれてありがとうございます。
どうもはっきりしないのですが、
https://hamachan.info/win7/access/data.html
>Access2010では、テーブルのデータ型に［集計］が追加され、テーブルに集計フィールドを作成できるようになりました。
>計算の結果は集計列に格納されます。
https://358dokari.com/access-datetype-kaisetu1#⑭_集計
>14 集計
>他の列の値を参照して式を作成し、その計算結果をテーブルに保存することができます。
それとこの英語サイトが table と query の場合でベンチマークをやって、
「結果の値を保存している」と判断しているようです。
https://codekabinett.com/rdumps.php?Lang=2&targetDoc=access-table-calculated-field-compute-quarter-date
hatena 様はどうお考えでしょうか。
「保存する」説のページのリンクをいくつか提示してもらえるとありがたいです。
すみません、自己レスです。
MS公式その他を読んでも分からなかったので質問させていただきましたが、
検索を続けると「保存する」が多数説で判明しました。
お騒がせしました。
表形式のレイアウトが適用されているか否かによるのではないかと。
レイアウトが適用されているのであれば、レイアウト内で横並びになっている
複数のテキストボックスを選択し、それらの[左スペース]プロパティの値と
[右スペース]プロパティの値の和が 0.5 cm になるよう、プロパティシートから
それぞれのプロパティの設定値を入力すればよいはず。
りんご様
前提をお話していませんでしたが、表示するだけではなく、60万件ほどの初期レコードに対し、
UI上に演算等をするコマンドボタンが10数個あり、レコードを追加、削除、演算をし、結果として、
集計結果（100万件）をクロス集計クエリを表示する仕様です。
hatena様
インデックスは早速試しました、体感レベルですが少なからずパフォーマンス改善したように思います。
SourceObjectを空にしておいて、タブの移動で計算させるというのは、パフォーマンス改善にかなり有効でした。
どうもありがとうございました。
お二人ともありがとうございます。
フィルタの方で成功しました。クエリの方もいくつかのパタンは試したのですが、ご教示いただいた内容も試してみたいと思います。
またよろしくお願いいたします。
特に問題ないと思いますが、気になるなら、仮のテーブルとクエリを作って試してみるのはどうでしょう？
全部のフィールドを選択して、プロパティシートの書式、右スペースを0.5にするとどうなります？
おおぅ、お見事です。
工夫すればいろいろ方法はあると思います。
例えば、
まずは、横1列のテキストボックスの間隔0になるようします。
現状、各テキストボックスが重なるように配置されているなら、すべてのテキストボックスを選択して、
[サイズ/間隔]-[左右の間隔を均等にする]をクリック。
間隔が空いているなら[サイズ/間隔]-[左右の間隔を狭くする]を間隔０になるまでクリック。
間隔0になったら、右端のテキストボックスを選択して、[左位置]の値を間隔×(テキストボックス数-1)分だけ増やします。
例えば、間隔5mmでテキストボックス数１0なら 0.5×９＝4.5cm増やします。
その後、すべてのテキストボックスを選択して、[サイズ/間隔]-[左右の間隔を均等にする]をクリックすると、5mmの間隔になります。
テキストボックスがどれだけ多くても左位置の設定は1回ですみますのでかなり楽できます。
5cmと3cmのフィールドなどバラバラのサイズで各5mm開ける、とかだと、フィールドの長さを考慮して地道に打ち込んでいくということですか？
フィールドの左端位置は数値でわかりますが、右端（終わりの場所）の情報がないようなので
やはり手動で計算していかないといけませんよね
配置しているフィールドもすべて手動で書き換える必要がありますか？
同じテーブルのデータを表示させるだけなのでフィールドはそのままでよいのでしょうか？
テーブルに適切なインデックスは設定されているでしょうか。
列見出しに設定するフィールド、抽出条件を設定するフィールド、並べ替えを設定するフィールドにインデックスを設定してみてください。
複数のテーブルを結合しているなら結合フィールドにもインデックスを設定してみてください。
フォームに関しては、デザインビューでは、タブの最初に表示されいるページのみにソースオブジェクトを設定しておいて、ページを変更したときにそのページのソースオブジェクトを設定するという方法が考えられます。
コード例
それはそうでしょう。詳しくないですが、Excel風に印刷したい時など、その場限りで使うものではないでしょうか。クロス集計結果をメイン画面に表示して普段使うならば、Excelでデータベースを組むでしょう。
時間と労力を費やしてその場凌ぎではどうにもならないと思います。個人の意見なので、解決策が他にあるかもしれませんが。
現在のフォームを作成した後、元のテーブルを編集し直したが、そのせいか？取り敢えず、もう１つテーブルもしくはクエリからフォームを作ってマクロを試してみると、どうなるでしょうか。
あと、マクロのWHERE条件式ですが、
[開くフォーム上のフィールド名]=[Forms]![フォーム名]![テキストボックス名]
というフォーマットになりますが、[F_詳細]のレコードソースに[ID]フィールドは存在してますか。
これはテキストボックス名ではないので注意してください。
バラメータのテキストボックスの標題は何が表示されてますか？
そこに表示されているフィールドまたはオブジェクトが見つからないということですので、それに間違いがないか、開いているか確認して下さい。
それ以外の原因はないです。
>りんごさん
ありがとうございます。再度確認しましたが、テキストボックスの名前は間違いありませんでした。
以前にテーブルでIDフィールドを作成し直していますが、その影響はありますでしょうか。両フォームでのテキストボックスのコントロールソースに間違はないです。