次の方法で共有

クエリのSQLビューでフィールド名に自動的に[](カッコ)がつく

Anonymous
2015-09-18T11:33:50+00:00

ACCESSでクエリを保存すると、特定のフィールドにカッコが勝手についてしまいます。

恐らくこれを原因とするエラーもあり、困っております。

■状況1

「REF」というテーブルに「テーマ」という[短いテキスト]型のフィールドがあります。

次の操作をします。

1.新規クエリを開き、次のSQL文でクエリを保存して一旦クエリを閉じます。

SELECT テーマ

FROM REF;

2.SQLビューで開き直すと次のSQL文になります。

SELECT [テーマ]

FROM REF;

これだけです。

他のフィールドではこのような事が起こらないのですが、何故かこのフィールドだけカッコが付いてしまいます。

カッコを削除して保存し直しても保存する際にまたカッコが付いてしまうようです。

上記はSQLビューから作成しましたが、デザインビューで作成しても同様です。

なお、フィールド名に含まれる長音「ー」の指定ミスでは無いです。コピペして確認しました。(シフトJIS:815B)

長音を使用する事自体があまり良くないそうですが(後で知った)、

他テーブルの長音を含むフィールドではこのようなことは起こりませんでした。

■状況2

これだけなら問題無いのですが、次の様にするとエラー発生します。

ポイントは次の2つを含むクエリ。(次の例では「クエリ2」)

これが重なるとエラーが生じるようです。

  • SELECT句で「強制カッコのフィールドを含むクエリ」のフィールドをワイルドカードで指定。
  • 複数値フィールドと結合。

テーブル1:REF

フィールド:テーマ(短いテキスト型)、必要資格(整数型)

テーブル2:従業員

フィールド:従業員ID(長整数型)、名前(短いテキスト型)、保有資格(整数型、複数値)

クエリ1:

SELECT [テーマ], 必要資格

FROM REF;

クエリ2:

SELECT [クエリ1].*

FROM クエリ1 LEFT JOIN 従業員 ON [クエリ1].必要資格 = 従業員.保有資格.Value

WHERE 従業員.従業員ID=[TempVars]![UserID];

上記クエリ2を開くとエラーダイアログが発生します。

「'[クエリ1].[REF].[[テーマ]' のかっこの使い方が正しくありません。」

 → エラーをよく見ると「テーマ」フィールドの前カッコが2重についています。

なお、クエリ2のWHERE句は無くてもエラーが発生します。

ファイル起動時に[TempVars]![UserID]に従業員IDを取得してあるので、

ユーザーが自分に関係するテーマを抽出する事ができます。

一応、回避策が2つあります。下記いずれかで回避します。

  • 「クエリ1」のSELECT句で「テーマ」フィールドを別名にする。例:「テーマ AS テーマ名」
  • 「クエリ2」のSELECT句でワイルドカードを使わない。

■質問

この強制カッコの原因または回避策はありますでしょうか。

Microsoft 365 と Office | アクセス | 家庭向け | Windows

ロックされた質問。 この質問は、Microsoft サポート コミュニティから移行されました。 役に立つかどうかに投票することはできますが、コメントの追加、質問への返信やフォローはできません。

0 件のコメント コメントはありません
質問作成者が受け入れた回答
  1. Anonymous
    2015-09-25T06:17:09+00:00

    こんにちは、ずっちです。

    カッコが勝手についてしまう件に関しては再現しました。

    しかし、問題のSQLのエラーに関しては特に何も起きませんでした。

    (Where 句を省いて実行しました)

    カッコの件は「必要資格」などでは起きず、

    「テーマ」、「ラーメン」、「te-ma」で発生しました。

    「ー」を記号(ハイフン?)と錯覚してカッコをつけてしまっているようですね。

    回避策ですが、

    2バイトでの命名をやめて、記号を極力利用しない

    ってのはどうでしょうか。

    少し古いですが以下のようなページもあります。

    https://support.microsoft.com/ja-jp/kb/826763

    あと、以下のように書かれている方もいました。

    http://amano41.hateblo.jp/entry/2012/12/11/195037

    変わったところだと「・」(中黒点)で問題が発生した経験もあります。

    ちなみにアンダースコア( _ )はバシバシ使って大丈夫です!

    とはいえ、既に作りこまれているものだと修正は非常に面倒かと思います。

    謎の現象で悩むより、確実に安全に利用できたほうが生産性も高まると思います。

    0 件のコメント コメントはありません

1 件の追加の回答

並べ替え方法: 最も役に立つ
  1. Anonymous
    2015-09-25T06:52:34+00:00

    返信ありがとうございます。

    カッコの件は「必要資格」などでは起きず、

    「テーマ」、「ラーメン」、「te-ma」で発生しました。

    「ー」を記号(ハイフン?)と錯覚してカッコをつけてしまっているようですね。

    再現したなら仕様なのかもしれないですね。

    ただこちらでは、同じく長音を含むフィールド名でもカッコの付かない場合もあり、もやっとしますが。

    回避策ですが、

    2バイトでの命名をやめて、記号を極力利用しない

    ってのはどうでしょうか。

    根本的な話をするのであれば、これはもう本当その通りだと思います。

    今の私の能力でゼロから作る場合はそうしたいです。

    実は紹介していただいた記事も以前から見ていて、

    コロンとかスラッシュとか「半角英数記号も存在する全角記号」には

    気を付けていたんですが、長音が記号だという認識が希薄でした。

    全角ハイフンを半角ハイフンとして認識するのは分かりますが、

    全角長音に対応する半角英数記号って無いですし。

    ひとまず仕様と考え、今後は気を付けていきます。

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

    1 人がこの回答が役に立ったと思いました。
    0 件のコメント コメントはありません