Laboratory of Mobile Agricultural Chemicals Searcher
携帯農薬検索実験室

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
40 / 54 ﾍﾟｰｼﾞ <前へ | 次へ>
〔283〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/15 1:30)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　おっしゃるとおり、前提条件は違うように感じます。私にとってSQL直打ちは、利用者からの緊急要望にバージョンアップで対応できない場合、開発者（あるいは上級者）がSQLを提示して暫定的に解決するというイメージです。そのSQL文を継続的に使いたい場合はボタンに覚えさせれば便利という程度で、あまりその機能にはこだわりません。上級者が試行錯誤する際の労力軽減のためにウイザードやボタン積み上げ機能は望ましいと思います。
　ということなら、同じですね。[#274] はあくまでも「簡易 SQL エディタ」に関する提案であり、通常の使い方に関しては [#276] の
>私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
が希望です。[#275] を読んだ時は、ユーザが SQL タブを使用することを前提として、それを如何に簡単に使えるようするかという提案のように感じたもので(^_^;)。

>　繰り返しになりますが、私の提案はどちらかというと個人のスキルに依存しないACFinderの機能追加ですね。
　何故か誤解されているような…。私の主張は上記のとおりで、s_kobayashi さんの提案と全く同じですよね？

　ただ、新しい機能が作られるたびに kabe さんはタブを増設しなければならず、ユーザは増設してもらうまで使えません。これを解決するために、下記のような機能にしてはどうかなと考えています。言葉では分かりづらいと思うので、現在サンプルを作成中です。
　ユーザは kabe さんが専用タブを増設してくれるまでこちらを利用し、kabe さんは要望の多いところから暇を見て専用タブを増設することができます。

１　ユーザインタフェース
(1) タブに「定型処理」を追加する
(2) 定型処理タブ内には、次のような機能を設置する
　a 処理内容選択機能
　b 一般的に検索条件として使われるであろう「作物名／病害虫名／用途／農薬の種類」を選択するため機能(汎用インタフェース)
２　使用方法
　ユーザは処理内容と検索条件を選択するだけで使える。
３　備考
　処理内容は検索条件を変数のようなモノに置き換えた SQL テンプレートを用意し、ユーザが選択した条件に基づいてその部分をシステムが自動的に書き換えて検索を実行する。
・ツリー全体表示
〔282〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 0:28)
引用なし
   ＞Hidemi Oyaさん

>　s_kobayashi さんと私の意図する機能が大きく違うのは、前提条件が異なっているからだと思います。私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。

　おっしゃるとおり、前提条件は違うように感じます。私にとってSQL直打ちは、利用者からの緊急要望にバージョンアップで対応できない場合、開発者（あるいは上級者）がSQLを提示して暫定的に解決するというイメージです。そのSQL文を継続的に使いたい場合はボタンに覚えさせれば便利という程度で、あまりその機能にはこだわりません。上級者が試行錯誤する際の労力軽減のためにウイザードやボタン積み上げ機能は望ましいと思います。

　うちの県の場合、個々の普及指導員やＪＡ営農指導員がSQLを操って技術資料の根拠にするというのはごくわずかだと思います。もともとSQLを使用した経験がほとんど無いですし、そんな慣れない作業をするくらいならs_kobayashiに相談するか、ACFinderの既存機能でエクセルファイルを出力して切り貼りするでしょう。

>　なるほど、よく使うクエリを複数のボタンに保存しておくということですね。その程度なら実装は難しくないと思います。が、現在の読み込みボタンで選択するのでも大差なく、ファイル名で選べる分選択も分かりやすいような気もします。

　繰り返しになりますが、私の提案はどちらかというと個人のスキルに依存しないACFinderの機能追加ですね。
　DBエンジンやテーブル名などの仕様が共通ですので、遠く離れた人同士が掲示板形式で意見交換したり、よりよいSQLの表現を検討したり出来ます。それはこの掲示板で行われていたこととよく似ていると思います。掲示板から自分のACFinderにデバッグ済みのSQLをコピー貼り付けして望む機能を追加する提案は多くの利用者に受け入れやすいでしょう。

>　それと、Excel で印刷までは難しいでしょうね。印刷用のフォントサイズやセル幅の設定については手動でやるしかないと思います。このツリーの中でも Excel 入れてないという人が２人いますし、用紙幅内で印刷するくらいで良いなら、反って HTML の方が向いているかな…。

　それでもいいですね。
・ツリー全体表示
〔281〕Re:日本語フィールドが使えないのは sqlit...
 Hidemi Oya WEB  (06/06/13 20:34)
引用なし
   >フィールド名は UTF-8 であっても大文字／小文字変換をしてしまっているというのが、文字化けの原因だと考えられます。
　ってことは、フィールド名をケース依存にする
PRAGAM case_sensitive_column_name = 1;
なんてプラグマがあれば簡単に対応できるなと思ったんですが、残念ながらありませんでした(;_;)。やはり、Delphi 側で処理するしかなさそうです。
・ツリー全体表示
〔280〕日本語フィールドが使えないのは sqlite3....
 Hidemi Oya WEB  (06/06/13 2:27)
引用なし
   >　'病' の後ろに '病1' のように何か文字を付けるとエラーが出なくなります。どんな文字を付加しても、列表示は '?E' となります。やはり、ShiftJIS -> UTF-8 変換の際に化けているようです。
　違いますね。AnsiToUTF8 変換の際に問題があれば、検索語としての「べと病」でも問題が出なければなりません。したがって、AnsiToUTF8 及び Delphi 側の問題ではないということになります。
　ということは、残るは SQLite エンジンである sqlite3.dll ですね。ステートメント、関数、フィールド等はケース非依存なので、エンジン内で大文字か小文字に変換されているはずです。この際、フィールド名は UTF-8 であっても大文字／小文字変換をしてしまっているというのが、文字化けの原因だと考えられます。
　UTF-8 文字列を URL エンコードすると、%xx の中に英小文字が散見されるので、恐らく sqlite3.dll はフィールド名を大文字に変換しちゃってるんでしょうね。

　ってことで、これを回避するには、
(1) 日本語フィールド名を使う場合は、ユーザはフィールド名の先頭に 'JP_' などの識別子を付ける。
(2) ACFinder は、識別子直後の文字列を 16 進文字列などにエンコードして SQLite に渡す
(3) SQLite からの結果を受け取った際に、ACFinder は識別子直後のエンコード文字列をデコードして表示する
といった作業が必要ですね。
・ツリー全体表示
〔279〕Re:ACFinder 060611版
 Hidemi Oya WEB  (06/06/12 23:02)
引用なし
   >　'病' が入ると 'misuse of aggregate' になるので、集約関数の一部として認識されてしまっているということですかねえ？
　'病' の後ろに '病1' のように何か文字を付けるとエラーが出なくなります。どんな文字を付加しても、列表示は '?E' となります。やはり、ShiftJIS -> UTF-8 変換の際に化けているようです。
・ツリー全体表示
〔278〕Re:ACFinder 060611版
 Hidemi Oya WEB  (06/06/12 22:51)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>まだ不完全でした。データベースが開けない場合があり、その後制御不能になります。(;_;
>おそらくアクセス制限のかかっている共有フォルダの場合ではないかと思いますが、どう対応したらよいのかわかりません。(^^;
　アクセス制限って、使用するユーザがフルコントロールになっていないということでしょうか？ という話であれば、everyone フルコントロールのフォルダを使ってくださいと謳っておくしかなさそうです。

>説明不足でした。データベース更新時に屋号を抜きながら tsusho フィールドを作成しますので、１回手動で更新してもらわないと直りません。
　そうですよね。追加フィールドの中にデータ持ってんですもんね。ついつい、macs for acis のつもりで試してしまいました(^_^;)。
　ということで、手動更新したら、判明している屋号についてはきれいに取れていることが判明しました。

>ちょっと、ここは原因不明です。
>グリッドに表示する前に Utf8ToAnsi しているのですが、AS の後の文字列によっては SQL エラーとなることもあり、それ以前の問題かもしれません。
　'病' が入ると 'misuse of aggregate' になるので、集約関数の一部として認識されてしまっているということですかねえ？ いずれにしても、表示する際の UTF8 -> ShiftJIS 変換ではなく、クエリを SQLite に渡す際の ShiftJIS -> UTF8 変換の際に問題が発生している可能性が高いと思われます。現在は、クエリを丸ごと変換してるんですよね？ だとすると、文字コード変換ライブラリのバグかな？
　ちなみに、[#259] の集約関数のエリアスを下記のようにするとちゃんと列に表示されます。'か', 'ビ', 'う', '菌' が入っているとダメですね。これらの文字が入ると、たいていは列が表示されなくなるだけですが、'うど' と続くと列表示は 'ぁEi' と化けます。ひらがなは、'ぁ' (SJIS:829F)から 'た' (SJIS:82BD)まではダメぽいです。'病' と同じ症状になる文字は見つけられませんでした。

max(case byochu when "べと病" then "●" else "" end) as べと,
max(case byochu when "灰色かび病" then "●" else "" end) as 灰色カび,
max(case byochu when "うどんこ病" then "●" else "" end) as ウどんこ,
max(case byochu when "斑点細菌病" then "●" else "" end) as 斑点細キン,
max(case byochu when "褐斑病" then "●" else "" end) as 褐斑,
max(case byochu when "菌核病" then "●" else "" end) as キン核
・ツリー全体表示
〔277〕Re:ACFinder 060611版
 kabe WEB  (06/06/12 19:59)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>>一応 LAN内の共有フォルダに置いた場合も検索できるようですが、パフォーマンスは不明です。
>　これは、後日試してみます。
まだ不完全でした。データベースが開けない場合があり、その後制御不能になります。(;_;
おそらくアクセス制限のかかっている共有フォルダの場合ではないかと思いますが、どう対応したらよいのかわかりません。(^^;

>>作物名を自動変換して欲しくない場合にはダブルクオーツで囲って入力してください。
>　ダブルクォートなしだと「%４倍体品種」が「%4倍体品種%」になり、ダブルクォートで括った場合は「%４倍体品種」が全く変換されませんでした。シングルクォートも同様の動作にしてもらった方が使いやすいかもしれません。
了解しました。

>>屋号について昨日から指摘のあったものを修正しました。
>>（したつもり）
>　う〜ん、直ってないようです。下記のような SQL で、条件を変えてチェックしています。
説明不足でした。データベース更新時に屋号を抜きながら tsusho フィールドを作成しますので、１回手動で更新してもらわないと直りません。

>>CSV保存時に列名も付けるようにしました。
>　ありがとうございます。列名が付くようになりました。自宅マシンには Excel を入れてないので試してませんが、「Excel 出力」でも同様でしょうか？
のはずですが…

>>フィールドエリアスに日本語を使ってもエラーにならなくなりましたが
>と書きましたが、'病' という文字が入るとエラーになりますね。「べと」だとちゃんと列名が表示されたりしますので、ShiftJIS -> UTF-8 変換がうまく動作していないのかも？
ちょっと、ここは原因不明です。
グリッドに表示する前に Utf8ToAnsi しているのですが、AS の後の文字列によっては SQL エラーとなることもあり、それ以前の問題かもしれません。

>SQL エラーを表示する際に、エラーメッセージを UTF-8 -> ShiftJIS 変換していただけるとうれしいです。
ここは修正します。
・ツリー全体表示
〔276〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/12 13:34)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　ボタン操作でコマンドを積み上げていくようなイメージでしょうか。
　というよりは、フィールド選択や条件設定の際に、いちいち覚えていなくてもソフトウェア側でアシストしてくれるというイメージです。

>私のイメージとしては、ウイザードで「テーブル選択」「フィールド選択」「絞り込み条件」「ソート条件」くらいの４段階の指示でとりあえず動くSQLを吐き出してくれればもう十分かなと思います。
　SQL を使いたくなるのは、基本的に非定型処理だと思います。他の項目はウィザードで処理してくれても、非定型処理の絞り込み条件をウィザードで設定できるようにウィザードを設計するのは至難の技でしょう。さらに、ウィザードで SQL の骨格を作ってくれたとしても、それを改良する際に上記のようなアシスト機能がないと難しいです。
　また、定型処理用 SQL を使うような場合も、誰かが作った骨格を自分の用途に合わせて修正するのが一般的な使い方ではないでしょうか？ だとすれば、SQL に詳しくなくてもサンプルをいかに楽に修正できるかをベースに付加機能を考えた方が多くの方が幸せになれると思います。
　が、皆が幸せになれるシステムを開発するためにはプログラマは地獄を見なければならないので、妥協点が提案したような方式だということです。

　s_kobayashi さんと私の意図する機能が大きく違うのは、前提条件が異なっているからだと思います。私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
　ただし、この機能で [#264] のように「なす」と「なす（露地栽培）」をひとまとめにするような設定まで作り込むのはかなり面倒です。タブ内で使えるのは、「なす」と「なす（露地栽培）」は別作物として作表する機能までという感じで良いと思います。で、「なす」と「なす（露地栽培）」をひとまとめにしたければ、このタブで作成されたクエリを SQL タブにコピーして手動修正するというような使い方ができれば楽だなというところです。
　現在は各タブが自動生成するクエリをログペインからコピーするしかないですが、できればボタン一発で SQL テキストボックスにクエリを貼り付けられると良いなあとは思います。

>　たとえば、ボタン１から「デラウエア登録農薬SQL」を呼び出して、エクセル印刷ボタンを押せばデラウエアに登録のある農薬（対象作物が落葉果樹、ぶどう、少粒種ぶどう、ぶどう（デラウエア）…のもの、但し県使用自粛農薬を除外）を検索し、結果をエクセルファイルに書き出し、印刷もしてくれるというような機能です。
　なるほど、よく使うクエリを複数のボタンに保存しておくということですね。その程度なら実装は難しくないと思います。が、現在の読み込みボタンで選択するのでも大差なく、ファイル名で選べる分選択も分かりやすいような気もします。
　それと、Excel で印刷までは難しいでしょうね。印刷用のフォントサイズやセル幅の設定については手動でやるしかないと思います。このツリーの中でも Excel 入れてないという人が２人いますし、用紙幅内で印刷するくらいで良いなら、反って HTML の方が向いているかな…。
・ツリー全体表示
〔275〕Re:ACFinder 060610版
 s_kobayashi  (06/06/12 0:18)
引用なし
   ＞Hidemi Oyaさん、abeさん

>select meisho from tekiyo where sakumotsu = '移植水稲'
>のように検索条件が入ります。
>　言葉ではイメージがつかみづらいかもしれませんが、これくらいなら比較的簡単に実装できると思いますし、SQL の作成は飛躍的に楽になると思います。

　ボタン操作でコマンドを積み上げていくようなイメージでしょうか。私のイメージとしては、ウイザードで「テーブル選択」「フィールド選択」「絞り込み条件」「ソート条件」くらいの４段階の指示でとりあえず動くSQLを吐き出してくれればもう十分かなと思います。

　付け加えていえば、適正な検索結果を出力できたSQL文を丸ごと覚えてくれる特殊ボタンがいくつかあるとうれしいです。私が作っている農薬検索CGIは個別ユーザー向けのカスタマイズが非常に難しいのですが、ACFinderのようなローカル完結型なら、SQL＋マクロ動作みたいな自動化が成り立つと思います。

　たとえば、ボタン１から「デラウエア登録農薬SQL」を呼び出して、エクセル印刷ボタンを押せばデラウエアに登録のある農薬（対象作物が落葉果樹、ぶどう、少粒種ぶどう、ぶどう（デラウエア）…のもの、但し県使用自粛農薬を除外）を検索し、結果をエクセルファイルに書き出し、印刷もしてくれるというような機能です。

　ま、このあたりは単なるアイデアですので、あんまり気にしないでください。(^^ゞ
・ツリー全体表示
〔274〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 23:28)
引用なし
   kabe さん、s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>ここまでは無理としても、将来的に簡易なSQLエディタ的なものは付けたいと思います。
　ちょっと考えていたことがあります。設定パネルに、テーブル選択コンボボックス(選択のみ)と追加ボタン、フィールド選択コンボボックス(選択のみ)と追加／条件ボタンを配置しておきます。で、テーブルを選択して追加ボタンをクリックすると、テキストボックスに
select　from tekiyo where
のように基本フレームが入ります。select　from の間にキャレットを置き、フィールドを選択して追加ボタンをクリックすると、
select meisho from tekiyo where
のようフィールド名が追加されます。where の後ろにキャレットを置き、フィールドを選択して条件ボタンをクリックすると、比較演算子選択コンボボックスとフィールド内容リストボックスで構成されたダイアログボックスが表示され、比較演算子と条件として使用する値を選択(比較演算子が IN の場合は複数選択)すると
select meisho from tekiyo where sakumotsu = '移植水稲'
のように検索条件が入ります。
　言葉ではイメージがつかみづらいかもしれませんが、これくらいなら比較的簡単に実装できると思いますし、SQL の作成は飛躍的に楽になると思います。

>現状では入力ボックスが小さすぎるので、別窓で入力するか、あるいはグリッドごと別タブにしようかなと思います。
　たしかに、現在はちょっと狭くて不便です。別窓と別タブなら、別タブに１票。SQL タブと結果タブがあるというイメージです。

>これも含めて現状では検索結果を表示するグリッドが１個しかないので、タブ切り替えブラウザみたいに複数の検索結果を表示できるようにしたいと考えています。
　どの検索条件とどの検索結果がリンクしているかを分かるように作るのは、なかなか難しいかもしれません。
　現在は、「作物・病害虫」「薬剤」「SQL」のページコントロールがツールバーに入っていて、結果表示用のストリンググリッドとリンクしていません。このページコントロールをツールバーから出してクライアント領域全体に置き、それぞれのタブの中に設定パネルとストリンググリッドを持つようにするってのはどうでしょう？(ログペインも共用型じゃなくてタブごとに独立してる方が良いかな？)
　これなら、それほど大きな変更なしに、少なくとも３項目の結果を独立して見ることができます。
・ツリー全体表示
〔273〕Re:ACFinder 060611版
 Hidemi Oya WEB  (06/06/11 22:45)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。
連日のアップデートご苦労様です。

>一応 LAN内の共有フォルダに置いた場合も検索できるようですが、パフォーマンスは不明です。
　これは、後日試してみます。

>が、一部そうでないものがあるかもしれません。
>（道路とか公園とか？）
　道路とか公園も大丈夫でした。

>作物名を自動変換して欲しくない場合にはダブルクオーツで囲って入力してください。
　ダブルクォートなしだと「%４倍体品種」が「%4倍体品種%」になり、ダブルクォートで括った場合は「%４倍体品種」が全く変換されませんでした。シングルクォートも同様の動作にしてもらった方が使いやすいかもしれません。

>屋号について昨日から指摘のあったものを修正しました。
>（したつもり）
　う〜ん、直ってないようです。下記のような SQL で、条件を変えてチェックしています。
select meisho, tsusho from tekiyo where tsusho like "%ｻｲｱﾅﾐｯﾄﾞ%" group by meisho
select meisho, tsusho from tekiyo where meisho like "%ｼﾝｼﾞｪﾝﾀ%" group by meisho

>CSV保存時に列名も付けるようにしました。
　ありがとうございます。列名が付くようになりました。自宅マシンには Excel を入れてないので試してませんが、「Excel 出力」でも同様でしょうか？

　[#255] で、
>フィールドエリアスに日本語を使ってもエラーにならなくなりましたが
と書きましたが、'病' という文字が入るとエラーになりますね。「べと」だとちゃんと列名が表示されたりしますので、ShiftJIS -> UTF-8 変換がうまく動作していないのかも？

　それと、前から書こうと思ってていつも忘れてた(^_^;)んですが、SQL エラーを表示する際に、エラーメッセージを UTF-8 -> ShiftJIS 変換していただけるとうれしいです。
・ツリー全体表示
〔272〕Re:ACFinder 060610版
 kabe WEB  (06/06/11 21:19)
引用なし
   ＞Hidemi Oyaさん
＞s_kobayashi さん

kabe です。

>>（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。
>　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ
ここまでは無理としても、将来的に簡易なSQLエディタ的なものは付けたいと思います。現状では入力ボックスが小さすぎるので、別窓で入力するか、あるいはグリッドごと別タブにしようかなと思います。

これも含めて現状では検索結果を表示するグリッドが１個しかないので、タブ切り替えブラウザみたいに複数の検索結果を表示できるようにしたいと考えています。
（今のところ構想だけですが）
・ツリー全体表示
〔271〕Re:ACFinder 060611版
 kabe WEB  (06/06/11 21:09)
引用なし
   kabe です

CSV保存時に列名も付けるようにしました。
・ツリー全体表示
〔270〕ACFinder 060611版
 kabe WEB  (06/06/11 21:07)
引用なし
   kabe です

060611版です。
http://acfinder.kabe.info/

>#260
データベースファイルの設置場所を自由に設定できるようにしてみました。
ただ。全く初めての起動の場合には少しダイアログが多くてとまどうかもしれません。
一応 LAN内の共有フォルダに置いた場合も検索できるようですが、パフォーマンスは不明です。

>#262
>ワイルドカードの自動付与は一律末尾のみにし、頭に付けたい場合はユーザが自分で付けるってのでどうでしょう？
に対応しました。
が、一部そうでないものがあるかもしれません。
（道路とか公園とか？）

作物名を自動変換して欲しくない場合にはダブルクオーツで囲って入力してください。

屋号について昨日から指摘のあったものを修正しました。
（したつもり）

フィールド名は
テーブル tekiyo
bango,yoto,shurui,meisho,tsusho,ryakusho,sakumotsu,basho,byochu,mokuteki,
baisu,ekiryo,jiki,kaisu,hoho,jikan,ondo,dojo,chitai,tekiyaku,kongo,
kaisu1,kaisu2,kaisu3,kaisu4,kaisu5
です。
noyaku を tekiyaku に変更しました。
・ツリー全体表示
〔269〕Re:屋号
 Hidemi Oya WEB  (06/06/11 20:40)
引用なし
   >kabe さん、こん＊＊は。Hidemi Oya です。

>　Delphi だと、
>(1) 屋号前後の「」〔〕［］を削除
>(2) 屋号直後の接尾語を削除
>って感じで処理できるのでは？
　'」〕］'の後ろに '・−印の　' が付くことはないでしょうから、
(1) 屋号直前の '「〔［' を削除
(2) 屋号直後の '」〕］・−印の　' を削除
の方がプログラムは楽かもしれませんね。
・ツリー全体表示
〔268〕Re:ACFinder 060610版
 s_kobayashi  (06/06/11 19:50)
引用なし
   ＞Hidemi Oyaさん

>　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ(^_^;)。

　そこまで便利にするのは難しいかもしれませんが、テーブル名、フィールド名、SQLの方言などがぱっと参照できればかなり生産性が高まると思います。SQLに堪能な人でもこれらの情報が示されていないとほとんど何も出来ません。いずれも設計時点で決まっていますし、一度インストールしたACFinderの内部構造は使っている間に変更されることもありませんから、単純な定型文表示でもいいと思います。

>>「家庭園芸用」という言葉の扱いをどうするか。削除？
>　このほか、「園芸用」「園芸」「産業」がありますが、一般的な同じ通称の農薬とは適用が異なることがあるので、削除せずに別通称とした方が良いと思います。ACFinder では、通称で表示された適用がどの名称の農薬のモノであるかを確認できませんから。
>　macs for acis では削除して同一通称としていますが、これは携帯電話の小さな画面ではこれらを別表示にすると使いづらくなることと、表示する適用があくまでも個々の名称の農薬のモノであることが明確だからです。

　了解しました。

>>（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）
>　各レコードにですか？ どのような用途を想定しているのでしょう？

　いろいろ考えてみましたが、各レコードに置くほどのことはないですね。where節やサブクエリで十分対応できそうです。
・ツリー全体表示
〔267〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 17:51)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。
　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ(^_^;)。

>「家庭園芸用」という言葉の扱いをどうするか。削除？
　このほか、「園芸用」「園芸」「産業」がありますが、一般的な同じ通称の農薬とは適用が異なることがあるので、削除せずに別通称とした方が良いと思います。ACFinder では、通称で表示された適用がどの名称の農薬のモノであるかを確認できませんから。
　macs for acis では削除して同一通称としていますが、これは携帯電話の小さな画面ではこれらを別表示にすると使いづらくなることと、表示する適用があくまでも個々の名称の農薬のモノであることが明確だからです。

>（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）
　各レコードにですか？ どのような用途を想定しているのでしょう？
・ツリー全体表示
〔266〕屋号
 Hidemi Oya WEB  (06/06/11 17:30)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　[#255][#265] 以外では、「サイアナミッド」「カヤク(・)」「イヅツヤ」(これは tm.pm も^^;)が全く削除されません。サイアナミッドは以前 kabe さんに教えてもらったものなので、抜けじゃなくて削除文字列が間違ってるのかも？
　あと、硫酸銅で「マルア」「エルピー」「小名浜」、石灰硫黄合剤で「カダン」が削除されません。

　「シンジェンタ・」と「チバガイギー・」のような「・」の取り扱いについては、tm.pm では屋号に続いて存在する「・」は一括削除するようにしています。このほか、屋号接尾語として「−」「印」「の」「　」については、「・」と同様の処理です。
　Delphi だと、
(1) 屋号前後の「」〔〕［］を削除
(2) 屋号直後の接尾語を削除
って感じで処理できるのでは？

　また、多数の屋号が存在する「硫酸銅」「(粉末)生石灰」「石灰硫黄合剤」「石灰窒素」「エムダイファー」については、登録屋号を削除するのではなく、通称の前にある文字を全て削除するようにしています。
・ツリー全体表示
〔265〕Re:ACFinder 060610版
 s_kobayashi  (06/06/11 12:09)
引用なし
   ＞kabeさん

いくつか気づいた点を報告します。

（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。

（２）以下の通称に不具合がありました。
×ﾔｼﾏ産業ﾛﾌﾞﾗｰﾙﾌﾛｱﾌﾞﾙ→産業ﾛﾌﾞﾗｰﾙﾌﾛｱﾌﾞﾙ
×三共の草枯らし→の草枯らし
×ﾁﾊﾞｶﾞｲｷﾞｰ･農将軍ﾌﾛｱﾌﾞﾙ→･農将軍ﾌﾛｱﾌﾞﾙ
×ｼﾝｼﾞｪﾝﾀ･ﾄﾚﾎﾞﾝ乳剤→･ﾄﾚﾎﾞﾝ乳剤
×ｺｰﾌﾟｹﾐｶﾙ粒状石灰窒素40→ｺｰﾌﾟｹﾐｶﾙ粒状石灰窒素40
×ｴｽ･ｶ･ﾍﾞｰ粒状石灰窒素→ｴｽ･ｶ･ﾍﾞｰ粒状石灰窒素
×ｴｽ･ｶ･ﾍﾞｰ石灰窒素50防散→ｴｽ･ｶ･ﾍﾞｰ石灰窒素50
「家庭園芸用」という言葉の扱いをどうするか。削除？

（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）

（４）エクセル出力時などに、何日時点のデータから作成したかが分かるような工夫があればよいと思いました。

（５）sqlからdeleteやdrop tableができました。そのような使い方をすることはほとんどないので、検索のみに権限を制限する方が良いと思います。
・ツリー全体表示
〔264〕Re:複数作物の登録状況一覧 SQL 例（通称対...
 Hidemi Oya WEB  (06/06/11 10:56)
引用なし
   　うちの母ちゃんに依頼された実例です。なす、ピーマン、かぼちゃについては、（）無しと（露地栽培）のみということで、検索条件で全て列挙する方式です。

select yoto, shurui, tsusho,
max(case when sakumotsu like "なす%" then jiki||"、 "||kaisu else "" end) as nasu,
max(case when sakumotsu like "ﾋﾟｰﾏﾝ%" then jiki||"、 "||kaisu else "" end) as pman,
max(case when sakumotsu like "かぼちゃ%" then jiki||"、 "||kaisu else "" end) as kabocha,
max(case when sakumotsu = "にがうり" then jiki||"、 "||kaisu else "" end) as goya,
max(case when sakumotsu = "ｵｸﾗ" then jiki||"、 "||kaisu else "" end) as okura
from tekiyo where
(yoto like "殺虫%" or yoto like "%殺菌剤") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
sakumotsu in ("なす", "なす（露地栽培）", "ﾋﾟｰﾏﾝ", "ﾋﾟｰﾏﾝ（露地栽培）", "かぼちゃ", "かぼちゃ（露地栽培）", "にがうり", "ｵｸﾗ")
group by tsusho order by yoto, shurui, tsusho
・ツリー全体表示
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
40 / 54 ﾍﾟｰｼﾞ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.