事例紹介のトピです。もちろん、コメントも大歓迎です。
例えばあるフィールドデータが「りんごでない」レコードを抽出する場合なら、抽出条件 (Criteria) として、そのフィールド名称を入力したセルの直下にその条件である「<>りんご」と記述します。これは一般的な事例として、Ｗｅｂ上でもよく見かける内容です。
でも、ある局面では単純にその類推だけからでは、必要とする結果を得られない事例がありました。Win版の2010での出来事です。
数字だけの８文字から構成されているコードが入力されているフィールドがあったとします。その数字は『数値』としてではなく、『文字列』として定義されております。
「00012345でない」レコードを抽出しようとして、「<>00012345」と条件を書きました。抽出結果は、「00012345でない」データは除外されず、もとからのリストにあったレコードの全てが、相も変わらずそのまま表示されてしまいました。
いろいろ考えていろいろ試して、それでもうまくいかず、ワイルドカードを加えてみたらどうなるか、というアイデアが思い浮かび、「<>*00012345」または「<>00012345*」としてみました。すると目指していた結果を得ることができました。
例えばあるフィールドデータが「りんごでない」レコードを抽出する場合なら、抽出条件 (Criteria) として、そのフィールド名称を入力したセルの直下にその条件である「<>りんご」と記述します。これは一般的な事例として、Ｗｅｂ上でもよく見かける内容です。
でも、ある局面では単純にその類推だけからでは、必要とする結果を得られない事例がありました。Win版の2010での出来事です。
数字だけの８文字から構成されているコードが入力されているフィールドがあったとします。その数字は『数値』としてではなく、『文字列』として定義されております。
「00012345でない」レコードを抽出しようとして、「<>00012345」と条件を書きました。抽出結果は、「00012345でない」データは除外されず、もとからのリストにあったレコードの全てが、相も変わらずそのまま表示されてしまいました。
いろいろ考えていろいろ試して、それでもうまくいかず、ワイルドカードを加えてみたらどうなるか、というアイデアが思い浮かび、「<>*00012345」または「<>00012345*」としてみました。すると目指していた結果を得ることができました。
|
|
|
|
コメント(5)
Excelはデータ型について厳密ではないようです。いまさらですが。
厳密でないといって、SQL-Serverも似たようなもので。黙示的なキャストが
助けてくれてますので、intとsmallintをjoinするなど、同列に扱っても害はない
ので、甘えていますｗ
仰せのフィルタの現象は。「MSそこまで気が回らなかった」の系だと思います。
「と等しい」は、数値に限ったことで、文字列についてはフィルタ機能に
黙示的なキャストが働いていません。
お示しのケースは文字列ですので「を含まない」とすると、ヒットしますよ。
アリタリスクを前後につけて、文字列でございと明示的にフィルタに宣言したら
ちゃんと正しい結果が返ってきたのは、その証拠だと思います。
厳密でないといって、SQL-Serverも似たようなもので。黙示的なキャストが
助けてくれてますので、intとsmallintをjoinするなど、同列に扱っても害はない
ので、甘えていますｗ
仰せのフィルタの現象は。「MSそこまで気が回らなかった」の系だと思います。
「と等しい」は、数値に限ったことで、文字列についてはフィルタ機能に
黙示的なキャストが働いていません。
お示しのケースは文字列ですので「を含まない」とすると、ヒットしますよ。
アリタリスクを前後につけて、文字列でございと明示的にフィルタに宣言したら
ちゃんと正しい結果が返ってきたのは、その証拠だと思います。
３のまじんさん
>う〜ん、[2]のコメントは、内容的には、参考にしないほうが良さそうですねぇ。
参考にできるところとできそうにはないところ、その両方があると、率直なところそう感じております。
２では
>Excelはデータ型について厳密ではないようです。
とおっしゃっておられますが、厳密ではないとは一概に断言しきれないと思います。
データの型で言うならば、数字を一度文字列であると定義したデータなら、それをコピーし、貼り付け先せるでも、恐らく同じように文字列として扱われていると思います。この点において、データの型は一定の厳密性を以て維持されていると思います。
ちなみにこのわたしも以前、コピー元での文字列での属性が、貼り付け先では維持できていないのではないかと感じたことがあり、それをまじんさんからそうではないと指摘してもらったことがあります。そのあと自分でいろいろ試してみたら、やはりそのご指摘通りでした。
>文字列でございと明示的にフィルタに宣言したら
これはその通りだと思います。ワイルドカードとは要すれば文字列のひとつのことでしょうから、そのワイルドカードが、数字だけの並びである「00012345」に加わわることで、「00012345」が、数値ではなく明示的に文字列だと扱われた。自然にそのように解釈できると思います。
>黙示的なキャストが
との表現がありますが、今のわたしの知識では、その意味するところがちんぷんかんぷんなので、あえてここにはコメントする資格はないとおもいます。
また、３でのまじんさんの投げかけに、
>オートフィルターでもフィルターオプションでも、どちらでもかまわないのですが、
とあります。
これもエクセルのフィルタ機能に対する抽出条件設定の仕方のことですから、恐らくはデータの抽出条件の設定のやり方において、どこかで厳密さが欠けるところがあるのでは、という気がします。
ちなみにデータベース関数と分類されているDSum関数。
同じように「00012345でない」レコードに含まれる別のフィールドの値だけを合計させようとして、抽出条件に「<>00012345」と記述したところ、全く同等の現象が発生しました。
そして最後に、３にある
>元のコードに、「01」「001」「010」「011」という種類があったとして、「『01』ではない」データだけを表示させたい場合
これ以外にも、エクセルでは「'」で始まる数字は数値としてではなく、文字列として扱われます。また、例えばIf関数で「条件式,満たす場合"0",満たさないい場合...」とした「"0"」も文字列で扱われます。それと同じことが抽出条件の書き方でも言えるのかどうか、これも自分の目で試してみたいところです。
>う〜ん、[2]のコメントは、内容的には、参考にしないほうが良さそうですねぇ。
参考にできるところとできそうにはないところ、その両方があると、率直なところそう感じております。
２では
>Excelはデータ型について厳密ではないようです。
とおっしゃっておられますが、厳密ではないとは一概に断言しきれないと思います。
データの型で言うならば、数字を一度文字列であると定義したデータなら、それをコピーし、貼り付け先せるでも、恐らく同じように文字列として扱われていると思います。この点において、データの型は一定の厳密性を以て維持されていると思います。
ちなみにこのわたしも以前、コピー元での文字列での属性が、貼り付け先では維持できていないのではないかと感じたことがあり、それをまじんさんからそうではないと指摘してもらったことがあります。そのあと自分でいろいろ試してみたら、やはりそのご指摘通りでした。
>文字列でございと明示的にフィルタに宣言したら
これはその通りだと思います。ワイルドカードとは要すれば文字列のひとつのことでしょうから、そのワイルドカードが、数字だけの並びである「00012345」に加わわることで、「00012345」が、数値ではなく明示的に文字列だと扱われた。自然にそのように解釈できると思います。
>黙示的なキャストが
との表現がありますが、今のわたしの知識では、その意味するところがちんぷんかんぷんなので、あえてここにはコメントする資格はないとおもいます。
また、３でのまじんさんの投げかけに、
>オートフィルターでもフィルターオプションでも、どちらでもかまわないのですが、
とあります。
これもエクセルのフィルタ機能に対する抽出条件設定の仕方のことですから、恐らくはデータの抽出条件の設定のやり方において、どこかで厳密さが欠けるところがあるのでは、という気がします。
ちなみにデータベース関数と分類されているDSum関数。
同じように「00012345でない」レコードに含まれる別のフィールドの値だけを合計させようとして、抽出条件に「<>00012345」と記述したところ、全く同等の現象が発生しました。
そして最後に、３にある
>元のコードに、「01」「001」「010」「011」という種類があったとして、「『01』ではない」データだけを表示させたい場合
これ以外にも、エクセルでは「'」で始まる数字は数値としてではなく、文字列として扱われます。また、例えばIf関数で「条件式,満たす場合"0",満たさないい場合...」とした「"0"」も文字列で扱われます。それと同じことが抽出条件の書き方でも言えるのかどうか、これも自分の目で試してみたいところです。
> 八神さん
[2]のコメントの印象は、私と逆のような印象です。
>Excelはデータ型について厳密ではないようです
これは、私もそう思います。Excelでは、データベースのように、厳密にデータ型を宣言して、データ入力しないですからね。ゼロ始まりの品番などを入力するために、先頭にアポストロフィをつけたり、あらかじめ表示形式を「文字列」にしておくというのは、Excelでは例外的な処理と言えるでしょう。なので、動作的に不安なｔころが出てきます。今回の件も、そのケースの1つです。
>「と等しい」は、数値に限ったことで
とありますが、これを文字面通りに受け取るなら、明らかな間違いです。
Excel 2007以降、文字列が入力されたフィールドに対して、オートフィルターでは、「テキストフィルター」として、条件指定できますが、「指定の値に等しい」と「指定の値に等しくない」というオプションが用意されています。「等しい」という日本語が適切なのかどうかはともかく、文字列の条件指定でも使います。
>お示しのケースは文字列ですので「を含まない」とすると、ヒットしますよ。
「を含まない」は、「と等しくない」と同義ではないですよね。この場合、「を含まない」としても、ヒットするのは、「たまたま」です。
八神さんの条件指定は、「前方一致」か「後方一致」ですよね。それと「を含まない」は、「と等しくない」とは違いますよね。
それを試してみられるのが、先に示したデータ群の例です。
なお、「オートフィルタでもフィルターオプションでもかまわない」としたのは、目的の結果が得られるなら、どんな方法でもかまわないということです。
ちなみに、オートフィルタで、「指定の値に等しい」として「01」などと指定すると、きちんと動作しますが、「指定の値に等しくない」として「01」などとしても、正しく機能しません。もう一度、同じ条件を実行しようとしてみると、そのナゾがわかると思いますので、ぜひ、お試しください。
[2]のコメントの印象は、私と逆のような印象です。
>Excelはデータ型について厳密ではないようです
これは、私もそう思います。Excelでは、データベースのように、厳密にデータ型を宣言して、データ入力しないですからね。ゼロ始まりの品番などを入力するために、先頭にアポストロフィをつけたり、あらかじめ表示形式を「文字列」にしておくというのは、Excelでは例外的な処理と言えるでしょう。なので、動作的に不安なｔころが出てきます。今回の件も、そのケースの1つです。
>「と等しい」は、数値に限ったことで
とありますが、これを文字面通りに受け取るなら、明らかな間違いです。
Excel 2007以降、文字列が入力されたフィールドに対して、オートフィルターでは、「テキストフィルター」として、条件指定できますが、「指定の値に等しい」と「指定の値に等しくない」というオプションが用意されています。「等しい」という日本語が適切なのかどうかはともかく、文字列の条件指定でも使います。
>お示しのケースは文字列ですので「を含まない」とすると、ヒットしますよ。
「を含まない」は、「と等しくない」と同義ではないですよね。この場合、「を含まない」としても、ヒットするのは、「たまたま」です。
八神さんの条件指定は、「前方一致」か「後方一致」ですよね。それと「を含まない」は、「と等しくない」とは違いますよね。
それを試してみられるのが、先に示したデータ群の例です。
なお、「オートフィルタでもフィルターオプションでもかまわない」としたのは、目的の結果が得られるなら、どんな方法でもかまわないということです。
ちなみに、オートフィルタで、「指定の値に等しい」として「01」などと指定すると、きちんと動作しますが、「指定の値に等しくない」として「01」などとしても、正しく機能しません。もう一度、同じ条件を実行しようとしてみると、そのナゾがわかると思いますので、ぜひ、お試しください。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
