FC2ブログ

スポンサーサイト 


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

--/--/--

Category: スポンサー広告

TB: --  /  CM: --

top △

通知 


カテゴリを新設しました。
このカテゴリの記事が増えていくのかは、わかりません。
私としては増えない事を希望しますが・・・・

http://oshiete.goo.ne.jp/qa/8060564.html #4から最後2行引用

(それにしても、折角質問者の方が要点を絞っている状況で、
 なぜ最初から全文を書きたがるのか・・・)

これは、私を挑発・私にかまってもらいたい・・・ということになるのでしょうか?
質問者さんとキャッチボールしようと思っているので、邪魔しないでください。
私の解釈は違う・・・だから、回答自体、全然違うものになっているんじゃない?
自分の解釈・スタンスを、人に押しつけるメリットはどこにあるんだろうか・・・

私も過去に、似たような回答をした事があったような気がしますが、
その時には、「前の人の回答を受けて記述したものだから削除」されたような気がします。
質問者さんが聞いてもいない、他回答への補足(解説?)・・・・回答に分類されるのかな?
事務局の削除基準がどこにあるかわからないので、気をつけた方が良いかもよ・・・

通報はしませんよ・・・(人となりが垣間見える文・回答だと思うので・・・)


今回の記事で言いたいのは、こんなことではなく・・・・


今回の本文


なんでだろう?
気持ちよく回答していて・・・・ http://oshiete.goo.ne.jp/qa/6253578.html

1つも動かない回答してきた人から、いきなり「致命的」だと・・・
さらには、#2時点で質問を閉じられたらどうするつもりだったのか・・・・とか、訳の分からない事を・・・
少なくとも、納得できる回答をお持ちの方から言われたのなら、仕方がないかと・・・・

その回答で、何故、解決できるの?・・・
それが知りたいだけなのに、何故に提示するのを拒むの?・・・・

また・・・・、なぜ、いい加減な回答した人から「致命的」と言われなきゃいけないの?

※ http://oshiete.goo.ne.jp/qa/6253578.html を見てみよう・・・と思われている方へ
頭にきて記述した部分は、ポンポン削除されています。
その削除された物の抜粋は、過去記事「理不尽」中盤に載せているので、
それも合わせ見て頂ければ・・・・どれだけ頭に来ていたのか・・・わかって頂けると思います。


私はあなたに、何か悪いことした?・・・心当たりは全くない・・・
見ず知らずの人から、いきなり「致命的」・・・言われるだけのことを私は何かした?・・・・
だ・か・ら、いきなりの・・・訳の分からない・・・こういう事をされましたよ・・・・
それについて、私は、こう考えます・思いますよ・・・・
それを公表(記事に)したまでです。

過去記事「理不尽」で取り上げましたね・・・
そこでの削除通知、同時3連発の出来事も・・・・
・突っ込んで・・・言ってたから、突っ込んでみた・・・・他の部分も広範囲にわたって意味なく削除だとか・・・
・推奨の方法を知っている・普段からやっている・・・のなら、その方法を教えてあげればいいのに・・・
・何故、あの回答で解決できるの・・・・裏技・解釈、質問者さんもずっと待ってますよ・・・

上側2つであれば、誰の通報で・・・推測・想定できませんでしたが・・・
プロフィールに記述していたものまで削除・・・・
全てに共通するのは誰なの・・・・・
(真偽は不明です・・・コメントを頂いていないので、そのまま・・・)

いい加減な人から「致命的」だと言われた・・・・・・・未だに忘れる事が出来ません。
だから、私はあなたを良く思っていません。
いい加減ではない・・・・・証明してください。

あの SQL で、フォームでの裏技・解釈談義・・・これらを提示して、チャンチャンで済む事じゃないの?
その内容で、私が納得できるのか・・・・しかないと思っているんですけど・・・・


※ また、

納得できなければ、URL を記述し質問しろ・・・・今は削除された画像内で言ってましたね・・・
(また、画像内では、終始、指摘行為の正当化しか、してませんでしたね・・・)
納得できるはずもなく、言葉に従い、質問を立て・・・・
あの SQL の解釈について補足記述した途端、質問ごと削除・・・・・
後から知った事ですが、何を書こうが、そのような質問の仕方自体・・・規約違反だと・・・・

あなたに対する見方・・・・変わりました。


提示ある事を、期待しています。あなたが、いろいろな言動するのは自由だと思いますが、
元を正すのは、元を作ったあなたにしかできない・・・・違いますか?    いつ正すのか、今でしょ・・・

あの QA #1補足での SQL について、私の解釈を再度以下に示しておきますので、是非提示ください
 
あの SQL と表現するのも何なんで、
http://oshiete.goo.ne.jp/qa/6253578.html #1補足に記述されたものを以下に引用します。

SELECT _単品在庫リアル.自社コード AS JAN, _単品在庫リアル.店舗コード INTO T1_在庫保持
FROM _単品在庫リアル INNER JOIN _店舗マスタ
ON _単品在庫リアル.店舗コード = _店舗マスタ.店舗コード
WHERE (((_単品在庫リアル.自社コード) In ([Forms]![在庫所持店舗表作成]![JAN]))
AND ((_単品在庫リアル.理論在庫数量) Not In (0,Null))
AND ((_店舗マスタ.事業部コード)=0))
ORDER BY _単品在庫リアル.自社コード, _単品在庫リアル.店舗コード;

質問者さんは、1つ前の質問で DJOINもどきを教えてもらって、嬉しそうでしたね。
単品で出すことはできたけど、複数での一覧を作りたい・・・・これが質問の趣旨でしたね。
つまり、どこかで DJOINもどきを使用しているのでしょう・・・これは、容易に想像できますね。

質問者さんが記述されてますが、カンマが喪失・・・・どうやって確認されたのか・・・疑ってました。
カンマの喪失・・・フォーム(VBA)上で確認してみます。(ここは、最近での確認です)
書式:標準のテキストボックス「txt1」
書式:数値のテキストボックス「txt2」
書式:空欄のテキストボックス「txt3」
  Dim sS1 As String, sS2 As String, sS3 As String
  Dim i1 As Long, i2 As Long, i3 As Long

  sS1 = Nz(Me.txt1)
  i1 = InStr(sS1, ",")
  sS2 = Nz(Me.txt2)
  i2 = InStr(sS2, ",")
  sS3 = Nz(Me.txt3)
  i3 = InStr(sS3, ",")
  Debug.Print sS1, i1, sS2, i2, sS3, i3
入力「1,2,34」では
1234 0 1234 0 1,2,34 2
入力「1234567890123,2345678901234,3456789012345」では
1.23456789012323E+38 0 1.23456789012323E+38 0 1234567890123,2345678901234,3456789012345 14

もし、カンマが喪失して・・・エラーなら #9にも記述してますが

> 数値として解釈されたのなら比較相手が数値でないと・・・・テキスト型なのかな?
>(エラーを「抽出条件でデータ型が一致しません」と想像して解釈)(検証していません)

上記動作は、この発言の裏付けになる?もの?かな?
なお、カンマの喪失がない・・・
これを前提にすると、数値 対 文字の比較でエラーになるのかも?
(ただ、この時、自動変換は動かないんだろうか???)
例えば、VBAで以下を実行すると、エラーになる事もなく then 側を通るんですけどね。
  Dim sS As String
  Dim i As Long
  Dim d As Double

  sS = "12345"
  i = 12345
  If (i = sS) Then
    d = 0
  End If
  sS = "1.2345E+10"
  d = 12345000000#
  If (d = sS) Then
    i = 0
  End If
クエリでの動きは、VBAでの動きと違うのかもしれない・・・・
カンマの喪失は無い・・・・これを前提に #2 を回答し、遅いけど動いた・・・・と
複数抽出できたという事は、カンマは喪失していない?・・・・
(だからといって、テーブル内のものがテキスト型とは言い切れない・・・・か)
(Access さんがやる、クエリ内での動きが・・・わからん:たぶん In ( ) だと違うんだろう)

その後、#2の回答後、遅くても動いた・・・の補足があった後、いきなり「致命的」だと・・・
後からの発言では、#2で閉じられたらどうするつもりだったのか・・・とも

もう一度、言っておきますよ・・・
納得できる回答をお持ちの方から言われたのなら、仕方がないかと・・・・


まずは、あり得ないでしょう・・・・
補足された SQL が、どんな種類の SQL なのか・・・見てすぐわかると思うんですが・・・
テーブル作成クエリをフォームのレコードソースに設定する・・・・ どんな動きをするのでしょう???・・・
2つ目のものは C を B と間違った記述してましたが・・・・
なお、テキストボックスの書式は「空欄」で・・・・断り書きが必要なのかもね。
上記で確認したように、書式が「標準」「数値」なら、文字列作る時にカンマは消えるようですけど・・・

私の#4からの記述は、#2で複数抽出できたことから、
テキストボックスからカンマが喪失しない事が前提になっていきます。


なぜ、こんな、いい加減な回答した人から「致命的」と言われなきゃいけないの?

さらには、テーブル作成クエリを選択クエリに変更してフォーム表示すれば解決できるとか・・・
つまり、DJOINもどきは、前の段階で使われているの??
もしそうなら、 抽出条件( WHERE 部分 )で破綻をきたすと思うのですが??

単に表示して解決であれば、
テーブル「_単品在庫リアル」と「_店舗マスタ」は、「店舗コード」で内部結合されてますが、
この時、DJOINもどきにより 店舗の羅列になっているんでしょうね・・・・
抽出条件を見て見ると、
(_店舗マスタ.事業部コード)=0
っていうのがありますね。また、記述には触れませんでしたが
((_単品在庫リアル.理論在庫数量) Not In (0,Null))
っていう記述もあります。
普通に考えると、在庫を管理するには店舗ごとにどうなのか・・・・・
同様に、店舗ごとに事業部コードを決めておくものだと思います。

テーブルと仮定しましたが、DJOINもどきをした後・・・なら、
どちらかが、クエリ・・・・もしくは両方が・・・になりますね・・・
店舗コードが羅列で得られているものとすれば、A店、B店、C店 があったとして、最低でも
店舗コードは「A」「B」「C」「A,B」「A,C」「B,C」「A,B,C」のレコードが必要になるのでは?
(内部結合に使っている位だから)
それぞれの店舗コードの組合せで、在庫があるか・・・・
そんなことしますかね?
また、店舗コードの組み合わせで、事業部コードを決定しますかね?

そういう中で次に疑問になるのは、
在庫側で DJOINもどきを使っていたとします。
この時、普通は「在庫がある店舗」・・・・と言う事で店舗コードの羅列化すると思うのですが・・・・
在庫があるか?・・・っていう条件を、なぜ、後でやっているのだろうか・・・・
じゃ・・・在庫条件を付けずに、何を使って店舗コードを羅列化しているんだろう・・・
同様に、店舗マスタ側で DJOINもどきをしていたら、何を条件に羅列化??
そして、後判別で 事業部コード=0 ・・・・・
私には考え付かない・想定できない構成です。

当時の回答では、この???部分を
> ・抽出条件から、店舗コードは、1店舗と考えた方が良さそう
の1行にしてましたが・・・・・


解決できるという事なので、想定されたレコードの提示は容易なのでしょう。
是が非でも、想定されたレコード数件でも、提示いただきたいものです。

私が、やり方を知らないだけで、失礼な事を言っているんだと思いますよ・・・・


私の考えは既に提示してますね・・・・
> 今回のクエリで出来上がったテーブルを元に、前回質問されたものを組み込んだ結果で質問内容が書かれた

これを前提にすれば、
・フォーム表示にしただけでは望む結果とはならない・・・
・フォームに対して、DJOINもどきを組み込む裏技があるんだったら、教えて欲しい


後半のあなたは、終始、指摘行為の正当化しか記述されませんでしたよね
なぜ、あの時に提示してもらえなかったの?・・・提示あればチャンチャンで終わっていた事でしょうに・・・


私が頭にきている・怒っているのは、
いい加減なひとから「致命的」と言われた・・・・
見ず知らずの私に、いきなり「致命的」と指摘する程、回答に自信があるんですよね・・・


是非とも、以下を提示ください。
・テーブル作成クエリを選択クエリに変更してまでフォーム表示にこだわるのは?・・・・・なぜ解決できるのか
・また、提示 SQL は、こう解釈するのだ・・・(想定されたレコード数件もあわせ、提示ください)



余談)

そう、「通報」として記事にしたのは・・・あなたが、ここを訪問されているかもしれない・・・
であれば、後添付画像について私はこう思う・・・
それを伝えたかっただけです。(サイトの動きは無さそうなので)
これだけが、同席していなかったものになりますけど・・・(だって、回答はもう出ていたので・・・・)

また、その記事内で
> 根に持つ・・・これは、私には「あり」だと思いますが、逆は無いと思っています。
と言ったのには、上記経緯があったから・・・・で、わかるでしょうか
関連記事

2013/05/03

Category: 戯言

TB: --  /  CM: 0

top △

この記事に対するコメント

top △

コメントの投稿

Secret

top △


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。