Microsoft Access 掲示板

お世話になります。気づかず申し訳ありません。

SELECT 基本情報.苗字
FROM 基本情報, 基本情報 AS 基本情報_1
WHERE (((基本情報.苗字カナ) Like [Forms]![基本情報1]![抽出用カナ]));

このようになっています。

上記はボタンに適してテキストボックスに表示され、同時にクエリの内容も同じものが表示されていました。

すみません。質問文にはった画像が間違っておりました。正しくはこのようにしたいです

日付は重複は表示しない設定にして、それぞれの日毎に複数の従業員名が表示されます
重複しない日付は空欄になるので、そのあまったスペースに営業目標を表示させたいです
従業員のレコード数が少ない場合は、営業目標2のように、したいです
営業目標を重複なしで日付の下にはって印刷時縮小にしてみましたが、透明なレコードが存在しているという
扱いのようで、従業員のレコードのたびに営業目標分のスペースが空くことになってしまいました

画像を貼り間違えご迷惑をおかけしました

>> 8
明日、来週、来月、来年、いつか振り返った時のためにメモさせて下さい。

じっとみているうちに、思い出してきただろうか？

きっと、見えない、忘れた、気づかないんだと思う。

　‘頭2文字IDと下2桁の組み合わせが重複する事を禁止する。(分類の重複も禁止される)
　‘単独主キーが他のテーブルから参照されている場合、頭2文字IDと下2桁の変更を禁止する。(分類の変更も禁止される)
　‘NULL禁止

テクニックを使ってアレンジするのは、大変。パッと見てもわからないし、オリジナルの事を忘れるし、そもそも気づかれない。

こういう登録が許容されるテーブルを使うのはどうかと思うんですよね

分類名の重複は、データの登録前後ともに、集計クエリ・DCountのような定義域集計関数で
誤りをチェックできるため、設計上問題ないという見解です。
　

質問上だと、「フラグ」というカラムにしたいということなので
この形でサロゲートキーな分類CDを使うならわかるんだけどという感じです

私とhirotonさんで質問文の解釈に違いがありそうです。

mabeeさんは、( おそらく )便宜上「フラグ」と表現されましたけど
通常、フラグという言葉は、立つ・折るという
二者択一に近い条件分岐や選択で用いられます。

分類を文字列だけでなく、数値でも表現したい とご希望なのは
並び替えの基準となる「識別子」が必要とお考えになったのではないか
と推測しました。

したがって、私は{ フラグ ＝ 識別子 }と解釈し、識別子を主キーとしています。
( 分類CD, 分類名, フラグ の3列構成にしない理由にもなっています )

また、余談にはなりますけど
分類をキーとした場合は、差別化を図るかどうかは別として
AA, Aa, aA, aa ＡＡ それぞれを異なる値として扱えません。
( バイナリ比較が必要になり、カラムも GUI では作成不可 )
( 差別化を図る場合は>> 3の回答自体が無効という盛大なブーメランですね )

数値型フィールドを識別子とすれば、全角半角大文字小文字を
同一の値で扱うことも差別化も容易で、高度なスキルも必要ありません。

常時バイナリ比較になり、経験の浅いDBAでも扱いが容易なことから
値の識別となる大小比較や結合・並び替えは、できる限り文字列より数値で実施するべき
というのが私のポリシーですので
>> 3でのSELECT文も、苦肉の策に近く、ベストプラクティスではない
というのが本音にはなりますね。

用途が不明ですが、完ぺきな対応関係（ZZ=676）なら26進数から10進数への変換なんで

フラグ: (asc(Left([分類],1))-65)*26+asc(mid([分類],2,1))-65+1

で表せますね

んー、質問の内容に対応する場合と、新規で構築する場合とで話も変わってくるとは思うんですが>> 3の段階の話だと

こういう登録が許容されるテーブルを使うのはどうかと思うんですよね

改めて構築するということだと分類CDがどこまでサロゲートキーとして有効かというのもあって、可能性の話なら

もあり得るんじゃないでしょうか。質問上だと、「フラグ」というカラムにしたいということなので

この形でサロゲートキーな分類CDを使うならわかるんだけどという感じです

hirotonさん、ご質問ありがとうございます。
分類CDをPRIMARY KEYとする理由を3つほど述べますね。

[理由1.]
PRIMARY KEY はソートに利用することが多いから、です。
文字列ですと、全行パディングされていない限りソートが難しくなります。

また、列数が２つのテーブルに
PRIMARY KEY と INDEX 両方を付与するのは
DBの容量増加、UPSERTの遅延、INDEX破損率の上昇
といったリスクを抱えることになりますので
列数の少ないマスタテーブルでは、設計上の理由から回避したいです。
( 経験則上、テーブルの破損 ＝ INDEXの破損 が圧倒的に多いです )
　
　
[理由2.]
( あくまで可能性として )分類の再編が発生して

サロゲートキーを利用する一因として
理由２.のように、主キーの体系が変化した場合などの影響が
ナチュラルキーに比べて( サロゲートキーのほうが )少なくなります。

mayuさんに質問なんですが、なぜ分類CDがPRIMARY KEYなんでしょう？
文字に対して番号を割り当てるなら分類名側をPRIMARY KEYとしたほうがそれっぽいと思うのですが

クエリの結果が望んだものにならない問題について

起きている現象から想像すると、クエリの元データとして使うテーブルを余計に読み込んでいる可能性が考えられます

確認すべき点はりんごさんが指摘している通りです
クエリの作りはテキストで確認することができるので、その内容をコピペしてください
確認方法については次のサイトが参考になります

SQLビューでSELECT文を使ったSQLを入力する（Accessの使い方さん）

クエリの内容でコンボボックスに見られるような異常が起きないのであれば、改めてボタンをクリックしたときの動作を確認してください。

「あ」のボタンを押す
→「抽出用カナ」テキストボックスに「[ア-オ]*」と入力される
→クエリ「Q従業員抽出」を開いて内容を確認する
→コンボボックスをクリックしてクエリの内容と同じものが表示されるか確認する

「か」のボタン「さ」のボタンでも同様の確認をする

ひとまずこれでフォームの作り、マクロの設定に異常がないか確認できます

クエリの結果が望んだ内容になっていないことは少し問題がずれるのでこのツリーからは外して改めて回答しなおします

>> 7
こんな感じになるのでしょうか？
親テーブル:英字分類No、英字分類、(英字分類Noで決まる)分類名
　　　　　　単独主キー　　　　AAとABなど、頭文字がAで始まるが、特に意味はない。
子テーブル:英字分類No、数字分類、(英字分類Noと数字分類で決まる)分類名
　　　　　　　　複合主キー　　AA01とAB01など、下2桁の行番号に、特別な意味はない。
分類フィールドは、導き出せるので、基本的にテーブルに保管しなくていいと思います。

　この回答は、お遊びですので、軽く流して下さい。

テーブル1:フィールド1(短いテキスト型)
テーブル2:フィールド1(短いテキスト型)・・・テーブル1をコピペして下さい。

クエリ1(テーブル作成クエリ)

　
　テーブル作成クエリを実行したら、1列目にオートナンバー型のフィールド「カラム」を挿入して下さい。データシートビューに切り替えると、オートナンバリングが実行されます。

英字分類のテーブル

　同じ要領で、数字分類(短いテキスト型)のテーブルを作ります。

数字分類のテーブル

※最初のレコード、00は削除して下さい。

　最後に、英字分類テーブルをテーブル1、数字分類テーブルをテーブル2に見立て、同じ要領で進めて下さい。

クエリの途中経過

クエリを　Like "[ア-オ]"　"[カ-コ]"等に書き換えた場合、名字のカタカナが表示されたり、データがない、ということはありませんでした。
さらに、Like [Forms]![基本情報1]![抽出用カナ]に戻して、「抽出用カナ」テキストボックスに[ア-オ]*と入れてクエリを開くと、同じように太田・岡田・安西・石川・伊藤・太田・岡田・安西・石川・伊藤・太田・岡田・安西・石川・伊藤・・・・と繰り返されて出てきます。

もとのテーブルでは、従業員コードを重複なしにしており、実際のテーブルのデータも同姓は一部おりますが、「あ」のボタンを押したときにはフォームには正しい人数で抽出されており、クエリの結果だけが何十回も繰り返されている状況です。

mayuさんとがぶっちゃいました。
かつ、mayuさんの方が完璧かつ詳細な回答でした。
mayuさんの回答を参考にしてください。

下記のようなテーブルを作成します。

テーブル名　T_フラグ

( 続き ) 理想は

CREATE TABLE t_分類マスタ
(
      分類CD INT           NOT NULL PRIMARY KEY
    , 分類名 VARCHAR( 50 ) NOT NULL
);

      入力ID     COUNTER  NOT NULL PRIMARY KEY
    , 分類CD     INT      NOT NULL
    , 分類別番号  INT
);

| 入力ID | 分類CD | 分類別番号 |
|-------:|-------:|-----------:|
| 1      | 1      | 1          |
| 2      | 2      | 1          |
| 3      | 2      | 2          |
| 4      | 1      | 2          |
| 5      | 1      | 3          |
| 6      | 3      | 1          |
| 7      | 2      | 3          |
| 8      | 1      | 4          |
| 9      | 2      | 4          |
| 10     | 2      | 5          |
　

SELECT y.入力ID
     , y.分類CD
     , y.分類別番号
     , x.分類名 & Format$( y.分類別番号, '-00' ) As 分類
FROM       t_分類マスタ x
INNER JOIN t_分類トラン y
        ON x.分類CD = y.分類CD
ORDER BY 1 ;

| 入力ID | 分類CD | 分類別番号 | 分類  |
|--------|--------|------------|-------|
| 1      | 1      | 1          | AA-01 |
| 2      | 2      | 1          | AB-01 |
| 3      | 2      | 2          | AB-02 |
| 4      | 1      | 2          | AA-02 |
| 5      | 1      | 3          | AA-03 |
| 6      | 3      | 1          | AC-01 |
| 7      | 2      | 3          | AB-03 |
| 8      | 1      | 4          | AA-04 |
| 9      | 2      | 4          | AB-04 |
| 10     | 2      | 5          | AB-05 |

ある属性X( 1 )を決めると、他の属性Y( AA )の値が一意に決まる
ある属性X( 2 )を決めると、他の属性Y( AB )の値が一意に決まる
ある属性X( 3 )を決めると、他の属性Y( AC )の値が一意に決まる
...
場合、「 Y は X に関数従属している 」といいます。
Y の種類が少数の場合は
IIf関数やSwitch関数を使って X を定義するのもいいでしょうけど
Y の種類が多い場合や、今後、Y の種類が増えることが想定される場合は
テーブル設計を見直したほうがいいでしょう。

CREATE TABLE t_分類マスタ
(
      分類CD INT           NOT NULL PRIMARY KEY
    , 分類名 VARCHAR( 50 ) NOT NULL
);

      入力ID  COUNTER  NOT NULL PRIMARY KEY
    , 分類    VARCHAR( 50 ) NOT NULL
);

| 入力ID |  分類 |
|--------|:-----:|
| 1      | AA-01 |
| 2      | AB-01 |
| 3      | AB-02 |
| 4      | AA-02 |
| 5      | AA-03 |
| 6      | AC-01 |
| 7      | AB-03 |
| 8      | AA-04 |
| 9      | AB-04 |
| 10     | AB-05 |
　
だとすると

SELECT y.入力ID
     , y.分類
     , x.分類CD
FROM t_分類マスタ x
   , t_分類トラン y
WHERE x.分類名 = Left$( y.分類, 2 )
ORDER BY 1 ;

| 入力ID | 分類  | 分類CD |
|--------|-------|--------|
| 1      | AA-01 | 1      |
| 2      | AB-01 | 2      |
| 3      | AB-02 | 2      |
| 4      | AA-02 | 1      |
| 5      | AA-03 | 1      |
| 6      | AC-01 | 3      |
| 7      | AB-03 | 2      |
| 8      | AA-04 | 1      |
| 9      | AB-04 | 2      |
| 10     | AB-05 | 2      |

hiroton 様
ご教示いただきまして誠にありがとうございます。

ご指摘いただきました「*」を半角にした上で、それ以外の細かい修正も行い以下コードで期待する動作ができるようになりました。お陰さまで本当に助かりました。これからも、今回教えていただきました内容を踏まえまして引き続き勉強させていただきます。

If Not IsNull(Me.総合検索) Then
    strFilter = strFilter & “ AND “ & BuildCriteria(“[質問]＆[回答]&[種別]”, dbText, _
   “(＊” & Replace(StrConv(Me.総合検索, vbWide), “ “, “ ＊ OR ＊") & "＊)")
End If

りんご様

返信ありがとうございます。
switch関数で動くことは確認できたのですが、場合分けの数を増やしていったところ、16個ほどの条件で、指揮が複雑すぎます、というエラーが出るようになりました。
他に手法はないのでしょうか？(そもそもaccessはそういうツールではないし、Excelでやればどうにかなるのですが…)
ご教授いただけますと幸いです。
よろしくお願いいたします。

修正後のコードが実際のコード（実際に動かしたコードをコピペしたもの）であるならうまく動いてないんじゃないですか？

抽出条件に使うワイルドカードは半角の記号である必要があります。以下に変数部分を適当に置き換えてイミディエイトウィンドウでテストした結果を提示します

// ＊が全角の場合
?BuildCriteria("abc" , dbtext,"(＊" & Replace (StrConv("a b c", vbwide), " ", "＊ OR ＊") &"＊)")
(abc="＊ａ＊" Or abc="＊ｂ＊" Or abc="＊ｃ＊")

// *が半角の場合
?BuildCriteria("abc" , dbtext,"(*" & Replace (StrConv("a b c", vbwide), " ", "* OR *") &"*)")
(abc Like "*ａ*" Or abc Like "*ｂ*" Or abc Like "*ｃ*")

本当に全角の「＊」で挟んだ形で完全一致判定をしたいのであれば提示のコードですが多分そうじゃないですよね？

下記、どうでしょうか？
Switch関数 - もう一度学ぶMS-Access

早速のご教示をいただきましてありがとうございました。

私ではコードの修正が難しかったため、詳しい方にもご協力いただきまして、
「or」対象の「Case 1」のコードを以下で確認してみたいと思います
。もし、お気づきの点などございましたらご指摘いただけましたら幸いです。

If Not IsNull(Me.総合検索) Then
            strFilter = strFilter & " and " & BuildCriteria("[質問]＆[回
答]&[種別]" , dbtext,
            "(＊" & Replace (StrConv(Me.総合検索, vbwide), " ", "＊ OR ＊") &
"＊)")
        End If

ありがとうございました。
できました。

無限ループですね。

Accessのテーブルを更新する場合、レコードセットを利用する方法と、更新クエリを利用する方法があります。

rsという変数がレコードセットの意味だとしたら、上記の異なる方法の解説サイトを理解せずに適当にくっつけた感じのコードですね。

とりあえず下記でどうでしょうか。

     Dim i As Long
     i = 2

     Do Until Cells(i, 1) = ""
         ’下のSQLがおかしかったので修正
         strSQL = "UPDATE MT_社員 SET 身長=" & Cells(i, 3) & " WHERE ID=" & Cells(i, 1).Value
         adoCn.Execute strSQL 'SQLを実行 1行ずつ実行する必要あり
         i = i + 1 '次の行に進める これがないと無限ループ
    Loop

    adoCn.Close
    Set adoCn = Nothing

End Sub

あるいは、営業目標の高さを、従業員数に関係なく一定にしたいということなら、
日付と営業目標をメインレポートにして、従業員をサブレポートして埋め込めばいいでしょう。

レコードソースのフィールド構成等、詳細が不明なのですが、
とりあえず下記が参考になりませんか。

グループ項目を垂直方向にセンタリングする

レポートで、大項目の「重複データ非表示」を「はい」にするとき、グループの一番上に表示されますが、垂直方向の真ん中に表示したい。 AccessClubの初級者掲示板の レポートで表示位置を調整したい であった質問です。 Excelでは、セル結合させて、垂直方向のセンタリングで簡単に実現できます。Accessではプロパティ設定等で簡単に実現するわけにはいきません。 VBAでワークテーブルに書き出してとか、Excelに出力...

fc2

上記で分からない場合は、現状のレポートのレコードソースのフィールド構成、レポートのグループ化/並べ替えの設定をを提示してもらえますか。

ご提示いただいたコードでできました。
ありがとうございました。

• 順位１位 ～ 順位７位中 いずれかのレコード でフラグが立っている
• 順位８位以下 全てのレコード でフラグが立っていない
  ( ８位以下が存在しないグループも含む )

両方の条件を満たしているグループを抽出したい
という解釈でいいでしょうか。

SELECT * FROM テーブル1
WHERE 部署 IN 
(
    SELECT 部署 FROM テーブル1
    GROUP BY 部署
    HAVING Sum( IIf( 順位 Between 1 And 7 AND フラグ Is Not Null, 1, 0 ) ) > 0
       AND Sum( IIf( 順位 > 7             AND フラグ Is Not Null, 1, 0 ) ) = 0
);

デフォルトでは非表示で、表示させる方法があるのですか？

そうですね

「ACCESS　レポート　グループフッター」とかで検索すると画像付きで解説しているサイトが見つかるので探してみてください

ほぼ同じ質問があり解説がありました
https://zawazawa.jp/ms-access/topic/183

日付でグループをつくると
日付ヘッダーができますが、日付フッターがありません
デフォルトでは非表示で、表示させる方法があるのですか？

グループ化なしでご指摘の方法でできました

仕切り線についてですが、詳細の一番下に引いておくと、各レコードごとにでてしまします
最初の質問の画像のように、仕切り線を日付ごとに引くことはできないのでしょうか？

次回、クエリをSQLビューにして、表示されるSQL文をコピーしてここに貼り付けてもらえますか？

コンボボックスで起きているそのほかの不具合「苗字カナの内容（カタカナ）が表示される」「データがない」等は起きていないということでいいですか？
たとえば、「か」のボタンを押したと想定して"[ア-オ]*"を"[カ-コ]*"に変えてみたり、さらに"[サ-ソ]*"に変えてみたり等、試してみてください

この、手で書き換えている操作を、フォーム上の値を使って自動で書き換えようというのが

Like [Forms]![基本情報1]![抽出用カナ]

の目的です。抽出条件を再度Like [Forms]![基本情報1]![抽出用カナ]に設定して、今度はフォーム上の「抽出用カナ」テキストボックスに手入力で"[ア-オ]*"と入力してクエリを開いてみてください。抽出条件を手入力したとき（Like "[ア-オ]*"と入力したとき）と同じ内容が表示されてますか？

同じ方の名前が何度も(100回以上)繰り返されています。

クエリの元データにはどのようなデータ（テーブルorクエリ）を使っているんでしょうか？>> 15で説明していますがクエリのもとにしているデータに複数登録されていれば何度も出てきて当然になります。データベース運用から考えれば「同一人物の重複登録を許さないデータ（テーブル）」があるものと思います。きちんと指定できていますか？

>> 18
画像1の上部分、写ってませんが、クエリに使用しているテーブルが表示されるエリアがあると思います。どんなテーブルが表示されていますか？

コードはコピペしましょう。また、コードブロックを使うと読みやすくなります

フィルタのAND/ORには優先順位があります。次の二つでは結果が変わります

A and B or C and D
A and ( B or C ) and D

不具合の時のStrFilterの内容をみて条件式が間違ってないか確認してみてください

ありがとうございます、できました。
大変勉強になりました。

書き換えてみました。クエリの結果は、漢字で、あ行ではありますが、
太田・岡田・安西・石川・伊藤・太田・岡田・安西・石川・伊藤・太田・岡田・安西・石川・伊藤・・・・というふうに、同じ方の名前が何度も(100回以上)繰り返されています。

データを残す必要がある（テーブルに値を書き込む）ならVBAで組むのが楽でしょう
クエリでやるなら
空きのない順位（DENSE_RANK）をつける（もう一度学ぶMS-Accessさん）

部署ごと、かつ、率の降順になるように集会クエリで加工済みのものをテーブルに書き出しています。そのテーブルに対してNoをふりたいと思っています。

ですので、部署が同じものの中で、AutoNo
の昇順で、率の降順に振りたいのですが、率が同率のものはダブらせいと思っています。

すみません、仕様の全てをお伝えしておらず、お聞きしたいエッセンスのみををお伝えするため、かなり簡略化しています。