2017-11-12 6 views
0

私が取り組んでいるクエリは、今までデバッグできなかったかなり面白い動作を示しています。それを取得する前に これは、クエリでバギー:0は、条件を適用した後にMS Access totalalsクエリ(w。COUNT)を返します。

#01542 | Open | 5 | Call | English | Tier1 | Complain | 01/01/2017 
#01542 | Closed | 2 | Call | English | Tier2 | ProdInfo | 01/01/2017 
#01542 | Open | 7 | Mail | English | Tier1 | ProdInfo | 08/01/2017 
etc... 

でもやっにおける実際の問題として:

SELECT EmpId, [Open/Close], Count([Open/Close]) AS Occurences, Attribute1, Market, Tier, Attribute2, MtSWeek 
FROM qrySource 
WHERE (Venue="NewYork") AND (Type="TypeA") 
GROUP BY EmpId, [Open/Close], Attribute1, Market, Tier, Attribute2, MtSWeek; 

は、クエリは正確に私はそれを期待する結果が得られます

QryCount次のステップで必要以上に多くのレコードを提供し、それによってデカルトを作成します。

qrySource。[開く/閉じる]は、可能性のある属性を(あなたが推測した) "open"、 "Closed"およびnullの文字列型フィールドであり、qrySourceの作成段階で実際にマッピングテーブルによって提供されます、しかしこれはおそらく助けになる)。

ここで、qryCountをOpen/Close = "Open"のレコードのみに制限しようとすると、エラーが発生します。 WHEREHAVINGの両方を使用してみました。クエリは0レコードになりますが、これは私が見たいものではありません。 "オープン"は予約語なので、ソーステーブルの "D_open"に変更しても問題は解決しなかったと考えました。 もまだ0のレコードが見つかった、その後のクエリ

SELECT * 
FROM QryCount 
WHERE [Open/Close] ="D_Open" 

しかし、何で目的のレコードをフィルタリングしてみました。

私は、COUNT機能のいくつかの固有の所有権と何らかの形で関係している可能性がありますが、わかりません。どんな助けもありがとう。

+1

予約語はデータ値に影響しません。これは、テーブル名や列名などの識別子の問題にすぎません。オリジナルのテーブルレコードやクエリ* qrySource *などの問題を再現できるように、再現可能なサンプルを設定できますか? – Parfait

+1

"qrySource"という名前のベーステーブルを使用して問題を再現できません。 @Parfaitには、問題を説明できる[mcve]を作成する必要があることに同意します。 –

+1

あなたのselectステートメントは正しいですか? WHERE [Open/Close] = "D_Open" 'read' WHERE [Open/Close] = "Open"? – Rene

答えて

0

参加したすべての人に、不十分/混乱のある情報を提供していただき、ありがとうございます。私は質問がより良い起草された可能性があることを偵察する。

いずれにせよ、この問題は明らかにオープン/クローズドフィールド名の「/」が原因であることがわかりました。元のマッピングテーブルのフィールド名から削除すると、クエリは期待通りに実行されました。

関連する問題