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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
〔185〕ACFinder LocalDB版 kabe (06/05/31 22:51)
〔186〕Re:ACFinder LocalDB版 kabe (06/05/31 23:25)
〔193〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 22:57)
〔208〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/04 21:46)
〔210〕Re:ACFinder LocalDB版 kabe (06/06/04 23:07)
〔213〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/05 0:43)
〔187〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 0:31)
〔188〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 0:56)
〔190〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 13:12)
〔192〕Re:ACFinder LocalDB版 kabe (06/06/01 22:51)
〔195〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 23:33)
〔196〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/01 23:45)
〔198〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/02 23:07)
〔209〕Re:ACFinder LocalDB版 kabe (06/06/04 22:28)
〔214〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/05 1:42)
〔218〕複数作物の登録状況一覧 Hidemi Oya (06/06/05 23:28)
〔223〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/06 0:56)
〔235〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/08 23:53)
〔236〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 1:32)
〔237〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/09 7:10)
〔240〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 17:48)
〔241〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 20:38)
〔245〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/10 8:11)
〔242〕Re:フィールド名 kabe (06/06/10 5:23)
〔244〕Re:フィールド名 s_kobayashi (06/06/10 8:01)
〔246〕Re:フィールド名 s_kobayashi (06/06/10 8:20)
〔248〕Re:フィールド名 Hidemi Oya (06/06/10 15:07)
〔253〕Re:フィールド名 s_kobayashi (06/06/10 18:32)
〔257〕Re:フィールド名 Hidemi Oya (06/06/11 0:05)
〔250〕Re:フィールド名 Hidemi Oya (06/06/10 15:48)
〔247〕Re:フィールド名 Hidemi Oya (06/06/10 14:28)
〔249〕Re:フィールド名 Hidemi Oya (06/06/10 15:21)
〔225〕Re:複数作物の登録状況一覧 kabe (06/06/06 22:43)
〔227〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/06 23:45)
〔230〕Re:複数作物の登録状況一覧 kabe (06/06/07 21:32)
〔231〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/07 23:58)
〔234〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/08 1:02)
〔212〕Re:ACFinder LocalDB版 kabe (06/06/04 23:45)
〔221〕対象病害虫一覧 Hidemi Oya (06/06/06 0:30)
〔226〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/06 23:25)
〔229〕Re:ACFinder LocalDB版 kabe (06/06/07 20:11)
〔232〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/08 0:24)
〔251〕ACFinder 要望追加 Hidemi Oya (06/06/10 17:33)
〔215〕Re:ACFinder LocalDB版 Sekizuka (06/06/05 12:05)
〔216〕Re:ACFinder LocalDB版 Sekizuka (06/06/05 14:49)
〔217〕Re:ACFinder LocalDB版 kabe (06/06/05 20:09)
〔228〕Re:ACFinder LocalDB版 Sekizuka (06/06/07 16:17)
〔233〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/08 0:43)
〔238〕Re:ACFinder LocalDB版 Sekizuka (06/06/09 13:05)
〔239〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/09 17:04)
〔243〕Re:ACFinder LocalDB版 kabe (06/06/10 5:38)
〔252〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/10 18:08)
〔219〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/05 23:37)
〔254〕ACFinder 060610版 kabe (06/06/10 21:38)
〔255〕Re:ACFinder 060610版 Hidemi Oya (06/06/10 23:05)
〔260〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 1:39)
〔266〕屋号 Hidemi Oya (06/06/11 17:30)
〔269〕Re:屋号 Hidemi Oya (06/06/11 20:40)
〔256〕複数作物の登録状況一覧 SQL 例（通称対応） Hidemi Oya (06/06/10 23:09)
〔261〕Re:複数作物の登録状況一覧 SQL 例（通称対応... Hidemi Oya (06/06/11 8:46)
〔264〕Re:複数作物の登録状況一覧 SQL 例（通称対応... Hidemi Oya (06/06/11 10:56)
〔258〕対象病害虫一覧の SQL 例（通称対応） Hidemi Oya (06/06/11 0:32)
〔259〕Re:対象病害虫一覧の SQL 例（通称対応） Hidemi Oya (06/06/11 1:04)
〔262〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 10:28)
〔263〕作物名の数字が全角に(;_;) Hidemi Oya (06/06/11 10:52)
〔265〕Re:ACFinder 060610版 s_kobayashi (06/06/11 12:09)
〔267〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 17:51)
〔268〕Re:ACFinder 060610版 s_kobayashi (06/06/11 19:50)
〔272〕Re:ACFinder 060610版 kabe (06/06/11 21:19)
〔274〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 23:28)
〔275〕Re:ACFinder 060610版 s_kobayashi (06/06/12 0:18)
〔276〕Re:ACFinder 060610版 Hidemi Oya (06/06/12 13:34)
〔282〕Re:ACFinder 060610版 s_kobayashi (06/06/15 0:28)
〔283〕Re:ACFinder 060610版 Hidemi Oya (06/06/15 1:30)
〔284〕Re:ACFinder 060610版 s_kobayashi (06/06/15 23:16)
〔293〕Re:ACFinder 060610版 kabe (06/06/17 21:54)
〔294〕定型処理サンプル Hidemi Oya (06/06/18 2:12)
〔297〕Re:定型処理サンプル Hidemi Oya (06/06/18 14:13)
〔270〕ACFinder 060611版 kabe (06/06/11 21:07)
〔271〕Re:ACFinder 060611版 kabe (06/06/11 21:09)
〔273〕Re:ACFinder 060611版 Hidemi Oya (06/06/11 22:45)
〔277〕Re:ACFinder 060611版 kabe (06/06/12 19:59)
〔278〕Re:ACFinder 060611版 Hidemi Oya (06/06/12 22:51)
〔279〕Re:ACFinder 060611版 Hidemi Oya (06/06/12 23:02)
〔280〕日本語フィールドが使えないのは sqlite3.dl... Hidemi Oya (06/06/13 2:27)
〔281〕Re:日本語フィールドが使えないのは sqlite3... Hidemi Oya (06/06/13 20:34)
〔286〕成分ごとの総使用回数 Hidemi Oya (06/06/16 13:06)
〔291〕Re:成分ごとの総使用回数 kabe (06/06/17 21:15)
〔295〕Re:成分ごとの総使用回数 Hidemi Oya (06/06/18 2:32)
〔300〕Re:成分ごとの総使用回数 Hidemi Oya (06/06/19 9:17)
〔306〕Re:成分ごとの総使用回数 s_kobayashi (06/06/19 21:08)
〔312〕Re:成分ごとの総使用回数 Hidemi Oya (06/06/19 22:25)
〔288〕「にがうり」が「ニガうり」に Hidemi Oya (06/06/16 14:35)
〔289〕データベース共有 Hidemi Oya (06/06/16 15:21)
〔292〕Re:データベース共有 kabe (06/06/17 21:28)
〔296〕Re:データベース共有 Hidemi Oya (06/06/18 2:41)
〔298〕ACFinder 060618版 kabe (06/06/18 21:11)
〔299〕Re:ACFinder 060618版 kabe (06/06/18 21:25)
〔301〕日本語フィールド名 Hidemi Oya (06/06/19 9:45)
〔313〕Re:日本語フィールド名 Hidemi Oya (06/06/19 23:03)
〔319〕Re:日本語フィールド名 Hidemi Oya (06/06/20 1:34)
〔321〕Re:日本語フィールド名 kabe (06/06/20 6:35)
〔322〕Re:日本語フィールド名 Hidemi Oya (06/06/20 9:16)
〔323〕Re:日本語フィールド名 Hidemi Oya (06/06/20 12:09)
〔302〕作物・病害虫タブ Hidemi Oya (06/06/19 10:10)
〔309〕Re:作物・病害虫タブ kabe (06/06/19 22:09)
〔315〕Re:作物・病害虫タブ Hidemi Oya (06/06/20 0:45)
〔318〕Re:作物・病害虫タブ Hidemi Oya (06/06/20 1:19)
〔303〕薬剤タブ Hidemi Oya (06/06/19 10:41)
〔310〕Re:薬剤タブ kabe (06/06/19 22:17)
〔304〕定型処理タブ Hidemi Oya (06/06/19 11:12)
〔305〕SQLタブ Hidemi Oya (06/06/19 11:28)
〔311〕Re:SQLタブ kabe (06/06/19 22:25)
〔316〕Re:SQLタブ Hidemi Oya (06/06/20 0:53)
〔307〕ACFinder 060619版 kabe (06/06/19 21:45)
〔314〕Re:ACFinder 060619版 Hidemi Oya (06/06/20 0:26)
〔317〕Re:ACFinder 060619版 Hidemi Oya (06/06/20 0:59)
〔324〕Re:ACFinder 060619版 Hidemi Oya (06/06/20 20:02)
〔325〕Re:ACFinder 060619版 kabe (06/06/20 21:59)
〔326〕Re:ACFinder 060619版 Hidemi Oya (06/06/20 22:51)
〔329〕Re:ACFinder 060619版 kabe (06/06/20 23:26)
〔185〕ACFinder LocalDB版
 kabe WEB  (06/05/31 22:51)
引用なし
   kabe です。

とりあえず、作ってみました。
http://acfinder.kabe.info/
ドキュメントが全くできていません。
動作確認も不十分ですので、人柱になってもよいという方のみご利用ください。
ご協力お願いします。

＞HidemiOyaさん
当面、このスレッドを使わせてもらってよろしいですか。
〔186〕Re:ACFinder LocalDB版
 kabe WEB  (06/05/31 23:25)
引用なし
   kabe です。

追加です。
Excel と UNLHA32.DLL が必要です。
sqlite3.dll も必要ですが、これは同梱しています。
データベースを作成するまで、結構時間がかかります。
流れとしては、ダウンロード＞解凍＞Excelを起動してCSV保存＞CSVファイルを開いて、各セルにダブルクォーテーションを付加する（この処理に一番時間がかかります。これをやらないとSQLiteにつっこめない）＞SQLiteのデータベース作成
という順番です。

データベースファイルは acfinder.exe のあるフォルダのDBフォルダ内のacis.dbです。SQLite で扱えますので、このままサーバに入れてperlや PHP で処理することも可能と思いますが、私はWebアプリは全くわかりません。
ちなみに文字コードは UTF8に変換して入れています。
（そのせいかファイルサイズが大きいです）
shift-jis のままだと、「斑点病」とか「斑点細菌病」などがなぜか検索できませんでした。試しにUTF8で入れてみると検索できたのでそのままにしています。

テーブルは登録基本部と登録適用部の二つそのままです。
テーブルの正規化等でよい案があればお願いします。
一応 SQL文を投げて検索することもできます。
テーブル名とフィールド名は以下のとおりです。
ソースからコピペします。
フィールド名とかいいかげんなので、統一案あればお願いします。
'CREATE TABLE kihon (' +
　　'[No] INTEGER,'　　 + //登録番号,
　　'[Syurui] VARCHAR(255),' +　//農薬の種類,
　　'[Meisyo] VARCHAR(255),' + //農薬の名称,
　　'[Maker] VARCHAR(20),' + //略称,
　　'[Seibun] VARCHAR(255),' + //略称,
　　'[Noudo] VARCHAR(50),' + //濃度
　　'[Kongou] INTEGER,' + //混合数,
　　'[Youto] VARCHAR(20),' + //用途,
　　'[Zaikei] VARCHAR(20)' + //剤型,
　　');';

'CREATE TABLE tekiyou (' +
　　'[No] INTEGER,'　　 + //登録番号,
　　'[Youto] VARCHAR(20),' + //用途,
　　'[Syurui] VARCHAR(255),' +　//農薬の種類,
　　'[Meisyo] VARCHAR(255),' + //農薬の名称,
　　'[Maker] VARCHAR(20),' + //略称,
　　'[Sakumotu] VARCHAR(50),' + //作物名,
　　'[Basyo] VARCHAR(255),' + //適用場所,
　　'[Byogai] VARCHAR(255),' + //適用病害虫雑草名,
　　'[Mokuteki] VARCHAR(50),' + //使用目的,
　　'[Baisu] VARCHAR(255),' + //希釈倍数使用量,
　　'[Ekiryo] VARCHAR(255),' + //散布液量,
　　'[Jiki] VARCHAR(255),' + //使用時期,
　　'[Kaisu] VARCHAR(100),' + //本剤の使用回数,
　　'[Houhou] VARCHAR(500),' + //使用方法,
　　'[Kunjyojikan] VARCHAR(55),' + //くん蒸時間,
　　'[Kunjyoondo] VARCHAR(55),' + //くん蒸温度,
　　'[Dojyo] VARCHAR(255),' + //適用土壌,
　　'[Titai] VARCHAR(255),' + //適用地帯名,
　　'[Nouyaku] VARCHAR(255),' + //適用農薬名,
　　'[Kongou] INTEGER,' + //混合数,
　　'[Kaisu1] VARCHAR(255),' + //有効成分1.を含む農薬の総使用回数,
　　'[Kaisu2] VARCHAR(255),' + //有効成分2.を含む農薬の総使用回数,
　　'[Kaisu3] VARCHAR(255),' + //有効成分3.を含む農薬の総使用回数,
　　'[Kaisu4] VARCHAR(255),' + //有効成分4.を含む農薬の総使用回数,
　　'[Kaisu5] VARCHAR(255)' + //有効成分5.を含む農薬の総使用回数
　 ');';
〔187〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 0:31)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>とりあえず、作ってみました。
　ご苦労様です。私の方はちっとも進んでいません(^_^;)。

>動作確認も不十分ですので、人柱になってもよいという方のみご利用ください。
　早速使ってみました。農薬ナビ版や薬検版と違ってローカルデータの検索なので、検索が爆速になりましたね。隣接作物との共通登録農薬がすぐに検索できるのも good です。とりあえず現在の機能で気になった点を…。

1. 自宅パソコンは StarSuite なので(MS-Office 2003 までは正規ユーザですが、もう次の VerUp はやめようと思って)、XLS>CSV 変換で Excel が見つからないとエラー表示した後砂時計が続いてしまいます。中止ボタンで止まりますが、エラーが発生した段階で即座に自動モードから抜けるようにして欲しいです。
　欲を言えば、Excel がなくても使えるようにフリーの OpenOffice Calc のオブジェクトにも対応(できれば結果の Excel 出力も)するか、さらに欲を言えばこれらがなくても使えるように EXCELファイル出力／入力コンポーネント で CSV に変換していただければと…。

2. [#186] で書かれているとおり、特に「CSV ファイル変更」にかなり時間がかかります。現在どのようなアルゴリズムで正規化されているのか分かりませんが、ダブルクォートされていない文字列項目をダブルクォートするだけなら、アルゴリズムや使用関数の変更で劇的に改善できると思います。

3. SQL 直書きで上位分類も含めた一括検索は可能ですが、近接作物の検索も全て SQL 直書きが必要になります。やはり、近接作物も含めて、作物名指定／選択の段階で上位分類一括検索ができた方が使いやすそうです。

4. 将来的な話になりますが、従来の ACFinder にあったクロス集計は実装されることと期待しています。併せて、[#184] で書いたような機能が実装されるとすごくうれしいです。

>当面、このスレッドを使わせてもらってよろしいですか。
　どうぞどうぞ。こういったことのために設置してある掲示板なので、大歓迎です。
〔188〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 0:56)
引用なし
   書き忘れです。

5. 作物名や薬剤名などの入力項目で、ひらがな／カタカナは意識しなくても検索できるようにしてほしいです。農薬検査所や JPP-NET でもどちらでも検索できるようになっているので、少々とまどいます。

6. 以前のバージョンと同様に、殺虫剤／殺菌剤といった用途による絞り込みはやはり欲しいです。
〔190〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 13:12)
引用なし
   もうひとつ、現状部分で違和感がある点に気がつきました。

7. 検索語を入力時に、IME の変換確定のためのエンターキー押下で検索が始まってしまいます。一般的なソフトでは、全文字確定後のエンターキー押下で検索が始まるので、この辺の違いにちょっととまどいました。
〔192〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/01 22:51)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　早速使ってみました。農薬ナビ版や薬検版と違ってローカルデータの検索なので、検索が爆速になりましたね。
SQLiteの威力絶大です。検索結果が多いとStringGrid にセットするのに時間がかかります。職場のPCでは起動後の最初の検索がヒットするまで、少し時間がかかる感じです。メモリー容量が少ないせいかもしれません。

>1. エラーが発生した段階で即座に自動モードから抜けるようにして欲しいです。
了解です。

>　欲を言えば、Excel がなくても使えるようにフリーの OpenOffice Calc のオブジェクトにも対応(できれば結果の Excel 出力も)するか、
これはやってみないと、なんともわかりません。が、多分無理かも(^^;

>EXCELファイル出力／入力コンポーネントで CSV に変換していただければと…。
ダウンロードしてみました。これで取り組んでみたいと思います。

>2. 「CSV ファイル変更」にかなり時間がかかります。
ここは課題です。もう少し見直してみます。

>3. 近接作物も含めて、作物名指定／選択の段階で上位分類一括検索ができた方が使いやすそうです。
なんとか実現したいと思いますが、少し時間がかかるかもしれません。

>4. 従来の ACFinder にあったクロス集計は実装されることと期待しています。
>併せて、[#184] で書いたような機能が実装されるとすごくうれしいです。
クロス表的な機能はなんとか実現したいと思いますが、優先順位は後になりそうです。SQLで書ければいいのですが、ちょっと検討もつきません。

>5. ひらがな／カタカナは意識しなくても検索できるようにしてほしい
ひらがなとカタカナを両方SQLに渡して作物選択するか、dick101.plを利用させてもらって、SQLには置換結果を渡すようにするか、迷ってます。dick101.plだと別名検索もできそうなので便利そうですが、Delphi で正規表現を扱う方法を覚えないといけないので時間がかかりそうです。

>6. 殺虫剤／殺菌剤といった用途による絞り込みはやはり欲しいです。
了解です。最優先で入れたいと思います。

>7. 検索語を入力時に、IME の変換確定のためのエンターキー押下で検索が始まってしまいます。
OnKeyUp イベントに書いていたのですが、IME起動時のエンターも認識してしまうようなので OnKeyPress イベントに書き直します。
〔193〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 22:57)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>各セルにダブルクォーテーションを付加する（この処理に一番時間がかかります。
　この部分は、今どんな風にやってます？ メールでソースを送っていただければ、高速化を考えてみます(っても、6/5〜6/9 は公庫東京支店で研修なのでやってる暇はないかもしれませんが)。
　あと、保存時は文字列フィールドオンリーで全てダブルクォートするようにして、読み出す時だけ登録番号や混合数などを数値フィールドとして扱うってのはダメなんでしょうか？ これで OK なら、条件判定などを結構省けると思いますけど。

>データベースファイルは acfinder.exe のあるフォルダのDBフォルダ内のacis.dbです。SQLite で扱えますので、このままサーバに入れてperlや PHP で処理することも可能と思いますが、私はWebアプリは全くわかりません。
　できあがったファイルの利用なら多分 OK ですね。perl や PHP でデータベース作成までやろうとすると、lzh の解凍ですでに挫折ですけど(^_^;)。

>ちなみに文字コードは UTF8に変換して入れています。
>（そのせいかファイルサイズが大きいです）
　基本登録部の CSV ファイルを UTF-8 に変換して保存すると、ファイルサイズはほぼ２倍です。ファイルサイズを小さくしつつ問題のない日本語のハンドリングを実現するなら、半角カタカナを全角に変換した上で EUC にするのがベストかもしれません。

　ところで、天敵 Wiki で人柱を募集してもよろしいでしょうか？
〔195〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 23:33)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。


>SQLiteの威力絶大です。検索結果が多いとStringGrid にセットするのに時間がかかります。職場のPCでは起動後の最初の検索がヒットするまで、少し時間がかかる感じです。メモリー容量が少ないせいかもしれません。
　確かに、'%稲%' なんかだとややかかりますが、それでも家のパソコンだとほんの数秒です。メモリ容量は影響が大きいかもしれませんね。

>これはやってみないと、なんともわかりません。が、多分無理かも(^^;
　調べたワケじゃありませんが、オブジェクト操作自体も Excel 互換になっているんじゃないかと思います。だとすると、Excel か OpenOffice Calc かを判定する部分を追加すればなんとかなるかも…。

>>EXCELファイル出力／入力コンポーネントで CSV に変換していただければと…。
>ダウンロードしてみました。これで取り組んでみたいと思います。
　よろしくお願いします。データだけなので、多分問題なく読めるんじゃないかと思います。

>クロス表的な機能はなんとか実現したいと思いますが、優先順位は後になりそうです。SQLで書ければいいのですが、ちょっと検討もつきません。
　そうか、専用ビューを作って、SQL を発行すれば良いのかな…。しかし、ビューの作り方が…(^_^;)。

>ひらがなとカタカナを両方SQLに渡して作物選択するか、
　SQLite は LIKE オペレータとして REGEXP という正規表現で検索できるオペレータもあるんですが、ACFinder の SQL では REGEXP が使えませんでした。Delphi 用のライブラリが未サポートなんですかねえ？ 正規表現で検索できれば、この辺は楽に指定できますし、上位分類一括検索の記述も楽になるんですけどね。

>dick101.plだと別名検索もできそうなので便利そうですが、Delphi で正規表現を扱う方法を覚えないといけないので時間がかかりそうです。
　Delphi で BREGEXP.DLL を使うための BRegExp ユニットがあります。関数ベースなので、簡単に使えます。
　ただ、dick101.pl では先読みやルックビハインドのために (?....) 拡張構文を使用しているので、これには対応していないかもしれません。エラーが発生する場合は、(?....) の部分を書き直す必要があります。
〔196〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/01 23:45)
引用なし
   書き忘れです。

　dick101.pl は、検索側がひらがな／カタカナを区別しないで検索してくれることを前提に、仮名は全てカタカナに統一しています。したがって、dick101.pl のスクリプトを実行できるようになったとしても、SQLite 側でひらがな／カタカナの区別無く検索できる体制が必要です。
〔198〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/02 23:07)
引用なし
   >>クロス表的な機能はなんとか実現したいと思いますが、優先順位は後になりそうです。SQLで書ければいいのですが、ちょっと検討もつきません。
>　そうか、専用ビューを作って、SQL を発行すれば良いのかな…。しかし、ビューの作り方が…(^_^;)。
　クロス表は条件によって列数が変わるので難しそうだったので、[#184] のような列数固定の表なら SELECT 文だけでいけそうだと思って取り組んでみたんですが、サブクエリの書き方が分からない…(^_^;)。もうちょっと SQL を勉強しないとダメなようです。
　それはそれとして、クロス表はすでにできていたルーチンを使って実装できないんでしょうか？
〔208〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/04 21:46)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>ちなみに文字コードは UTF8に変換して入れています。
　perl で encoding プラグマを使った時は、実行時の内部形式は UTF-8 なので EUC を使っても問題は無いんですが、Delphi で正規表現ライブラリを使って文字列置換を行う場合は EUC でもやはり問題が発生することがあり得るので、UTF-8 が一番無難です。

　話は全く変わりますが、農薬ナビ版の ACFinder が GW 明けに更新されてたんですね。研究会専用の ML を設置し直して、こういった情報を提供してくれると良いんですけどね。
　しかし、一般公開の「農薬DB検索(機能限定版)」が http://riss.narc.affrc.go.jp/ から消えてしまったのに、研究会限定の「登録農薬データベース検索」が一般公開される気配は無し…。いつになったら、みんなが使えるようになるんだろう…。
〔209〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/04 22:28)
引用なし
   ＞Hidemi Oyaさん

>[#184] のような列数固定の表なら SELECT 文だけでいけそうだと思って取り組んでみたんですが、サブクエリの書き方が分からない…(^_^;)。
「SQL クロス集計」で検索してみました。
イメージ的には次のようなSQLでいけそうです。（内容が正しいかどうか不明）
SELECT Meisyo ,
MAX(CASE WHEN Sakumotu = "きゅうり" THEN Jiki||Kaisu ELSE NULL END) AS KYURI ,
MAX(CASE WHEN Sakumotu = "ﾄﾏﾄ" THEN Jiki||Kaisu ELSE NULL END) AS TOMATO
FROM
(SELECT Meisyo,Sakumotu,Jiki,Kaisu FROM tekiyou WHERE (Sakumotu LIKE "きゅうり" OR Sakumotu LIKE "ﾄﾏﾄ") AND No IN
(SELECT No FROM tekiyou WHERE Meisyo LIKE "ﾀﾞｺﾆｰﾙ%" OR Meisyo LIKE "ﾄｯﾌﾟｼﾞﾝ%")
)
GROUP BY Meisyo

>　それはそれとして、クロス表はすでにできていたルーチンを使って実装できないんでしょうか？
SQLにこだわるよりは、こちらの方が簡単そうなので、そのうち入れます。

Excel なしのCSV変換はなんとかできそうです。
〔210〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/04 23:07)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　話は全く変わりますが、農薬ナビ版の ACFinder が GW 明けに更新されてたんですね。研究会専用の ML を設置し直して、こういった情報を提供してくれると良いんですけどね。
サーバのアドレスが変わったので、それに対応したくらいです。
ＭＬは再募集するような話もあったような気がしますが、どうなったんでしょう。

>　しかし、一般公開の「農薬DB検索(機能限定版)」が http://riss.narc.affrc.go.jp/ から消えてしまったのに、研究会限定の「登録農薬データベース検索」が一般公開される気配は無し…。いつになったら、みんなが使えるようになるんだろう…。
今回の Excelデータを元データにしてシステムを作ってもらえば、一般公開には問題なさそうな気もしますが、どうなんでしょう。
ただExcelデータには毒性がなかったりで、今と全く同じものを作ることはできませんね。それにしても登録基本部の部分に毒性くらいは載せて欲しかったです。ここらへんは小出しにしているなという気もしないではない…
〔212〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/04 23:45)
引用なし
   ＞Hidemi Oyaさん

kabe です。

クロス表、これでできそうです。

SELECT Meisyo ,Jiki,Kaisu,
MAX(CASE WHEN Byogai = "べと病" THEN "●" ELSE "x" END) AS BETO ,
MAX(CASE WHEN Byogai = "灰色かび病" THEN "●" ELSE "x" END) AS HAIKABI ,
MAX(CASE WHEN Byogai = "褐斑病" THEN "●" ELSE "x" END) AS KAPPAN
FROM
(SELECT Meisyo,Byogai,Sakumotu,Jiki,Kaisu FROM tekiyou WHERE (Byogai LIKE "べと病" OR Byogai LIKE "灰色かび病" OR Byogai LIKE "褐斑病") AND
Sakumotu LIKE "きゅうり%")
GROUP BY Meisyo

CASE WHEN 〜　の行を先に作っておく必要ありますが、事前に病害虫名を単一化してリストを作ればなんとかなりそうです。
〔213〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/05 0:43)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>ＭＬは再募集するような話もあったような気がしますが、どうなったんでしょう。
　天敵 Wiki の談話室で菅原さんに出会った時に、農薬データベース利用者の ML があるといいですねと私も提案しておいたのですが…。

>今回の Excelデータを元データにしてシステムを作ってもらえば、一般公開には問題なさそうな気もしますが、どうなんでしょう。
　中央農研は自前サーバなので、自動更新も可能ですしね。これを菅原さんに提案しようかと考えてました。

>ただExcelデータには毒性がなかったりで、今と全く同じものを作ることはできませんね。
　そこなんですよね。本家更新のたびに部分自動更新、今まで通り月一程度に全データ手動更新なんて感じで運用してくれるとうれしいなあ。
　で、日付を渡すとその時刻以降に追加／変更／削除されたデータを渡してくれるようなクエリを追加してもらえば、こちらのデータ更新も楽になります。

>それにしても登録基本部の部分に毒性くらいは載せて欲しかったです。ここらへんは小出しにしているなという気もしないではない…
　同感。ま、登録票部分のデータは、必要ならその都度読みに行くという手もありますけどね。
〔214〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/05 1:42)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>イメージ的には次のようなSQLでいけそうです。（内容が正しいかどうか不明）
　おお〜、良い感じです！ サブクエリ使っても思ったより速いですね。農薬名のところを Sakumotu で「きゅうり」と「ﾄﾏﾄ」にすれば、全農薬もいけそうです。とりあえず、２作物だけなら全農薬でも十分高速でした。

>SQLにこだわるよりは、こちらの方が簡単そうなので、そのうち入れます。
　上ができれば、フィールド数固定なら SELECT だけでいけるなと思ったら、すでに [#212] が書かれてますね。こちらも実に良い感じです。
　が、従来のクロス表のように全ての病害虫を一覧にするのは SELECT 文だけでは無理なので、従来版も実装してもらえると助かります。

　で、これらを試してみてて気づいた点…。
　SQL テキストボックスの行数が増えてもスクロールバーが出てこないのがちょっと辛いです。SQL テキストボックスは条件消去でクリアされないのもちょっと辛いです。ツールバーのボタンはマウスの移動距離も大きいので、テキストボックスの脇に「消去」と「実行」ボタンがあると良いですね。
　AS で作るフィールド名に日本語が指定できると良いですね。今は、LIKE とか = とかの演算子の右側の文字列リテラルだけコード変換してるのでしょうか？ SQL 文全体を Shift-JIS -> UTF-8 変換するんじゃダメなのかなあ…。
　基本となるクエリ式は同じで、作物名／病害虫名／農薬名等の条件だけを変更したいという用途は多いと思います。これを支援するような機能があるとうれしいですね。どんな方法がよいかは検討の余地がありますが、たとえば下記のようにリストを条件式に展開するようなマクロが作れれば、マクロに渡すリストを変更するだけで簡単に条件変更できるようになります。マクロなら文字列置換だけで実装できそうなので楽かも…。

$sakumotu = 'Sakumotu, or, きゅうり% ﾄﾏﾄ%'
select Meisho from tekiyo where $sakumotu
// 先頭が $ ならマクロとしてデータを保存するだけでクエリを発行しない
// $sakumotu を「Sakumotu like 'きゅうり%' or Sakumotu like 'ﾄﾏﾄ%'」に展開してクエリを発行

>Excel なしのCSV変換はなんとかできそうです。
　こちらができれば、不可視の StringGrid にデータを入れて、そのデータから直接 INSERT 文を発行することでデータベース作成の高速化も可能かもしれませんね。
〔215〕Re:ACFinder LocalDB版
 Sekizuka  (06/06/05 12:05)
引用なし
   kabeさん、こんにちは。神奈川のSekizukaです。
サーバ対応版も愛用しておりました。
現在、csvへの変換でプログレスバーが静かに動いています。

前のサーバ対応版もそうでしたが、接続の設定でつまずく人が多そうですね。
（ウチだとプロキシ設定にしないと駄目）
それとも単独庁舎とかで独自接続しているところはまだ多いんですかね。

いずれ、各県別、設定集とか作ると便利かも。
〔216〕Re:ACFinder LocalDB版
 Sekizuka  (06/06/05 14:49)
引用なし
   食事を終えて帰ってきたら流石に終わってました。
（もっと早かったのかも）
ざっと、動かしてみたところ、動作に支障はないようです。


当方の環境は、、、
ＯＳ：windows2000
CPU：Mobile Celeron 1.8GHz
RAM:245MB
EXCEL:2000版

後、何か影響ありそうな項目ってありますかね？

自宅ではｘｐと９８がありますが、EXCELがないので必須だと無理です。(^^;)
〔217〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/05 20:09)
引用なし
   ＞Sekizukaさん

kabeです。はじめまして。

>前のサーバ対応版もそうでしたが、接続の設定でつまずく人が多そうですね。
>（ウチだとプロキシ設定にしないと駄目）
レジストリからWindowsのインターネットオプションのプロキシ設定を読めるようにすれば、いいのかなと思いますが、まだ試したことがありません。
これは取り組んでみます。

#216
>自宅ではｘｐと９８がありますが、EXCELがないので必須だと無理です。(^^;)
Excelに依存せずデータ変換できるよう修正版を作成中です。
もうしばらくお待ちください。
ただ、データベースを作成したら、DBフォルダを含めて自宅PCにコピーすれば検索はできます。
〔218〕複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/05 23:28)
引用なし
   　指定作物の全農薬リストは、下記のようにサブクエリ無し集約関数のみで実現できました。農薬数が多くなりすぎるのと使い勝手を考えて、農薬の種類が "%水和剤" または "%乳剤" で、かつ用途が "殺虫剤" のみのものに限定しています。４作物全農薬でも結構高速です。

select Syurui, Meisyo,
max(case when Sakumotu like "だいこん%" then Jiki||Kaisu else null end) as Daikon,
max(case when Sakumotu like "はくさい%" then Jiki||Kaisu else null end) as Hakusai,
max(case when Sakumotu like "ｷｬﾍﾞﾂ%" then Jiki||Kaisu else null end) as Cabbege,
max(case when Sakumotu like "ﾌﾞﾛｯｺﾘｰ%" then Jiki||Kaisu else null end) as Broccoli
from tekiyou where
(Syurui like "%水和剤" or Syurui like "%乳剤") and Youto like "殺虫剤" and
(Sakumotu like "だいこん%" or Sakumotu like "はくさい%" or Sakumotu like "ｷｬﾍﾞﾂ%" or Sakumotu like "ﾌﾞﾛｯｺﾘｰ%")
group by Meisyo

　いやしかし、やっぱり作物リストを指定するだけで SQL に展開してくれるような支援機能が欲しいですね。[#214] のような文字列マクロじゃ、case 文の生成は無理なのであまり意味がないですね(^_^;)。
　VIEW とか PRAGMA を使っても無理なのかなあ…。

　話は変わりますが、フィールド名で、表記は "う" だけど読みは長音記号として使われる "う" が、Youto のように "u" が付いていたり、Meisyo のように "u" が省略されていたりするのは非常に分かりづらいので、どちらかに統一した方が良いと思います。それと、syu, syo などを指が勝手に shu, sho と打ってしまい、しょっちゅうエラーを出してます(^_^;)。
　フィールド名に日本語を使用するか、Meisyou でも Meisho でも使えるようにエリアスを設定してもらえると良さそうです。
〔219〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/05 23:37)
引用なし
   Sekizuka さん、こん＊＊は。Hidemi Oya です。

　天敵 Wiki から早速釣られてきていただいて、ありがとうございます。

>（ウチだとプロキシ設定にしないと駄目）
　県庁 LAN で使用する場合は、いずこも同じだと思います。

>いずれ、各県別、設定集とか作ると便利かも。
　各県のセキュリティ上の問題で、ローカルアドレスとはいえ公開は難しくないですか？ インターネットオプションに設定している HTTP の設定と同じなので、それを見てもらえば手動設定でも難しくないとは思いますが…。
　ま、[#127] で kabe さんが書かれているように、自動設定してもらうのが一番ですね。

　データベース更新速度については、Excel 不要版ができれば、改善されるかもしれません。
〔221〕対象病害虫一覧
 Hidemi Oya WEB  (06/06/06 0:30)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　列数固定クロス表は、下記のような感じでサブクエリ無し集約関数のみで実装できそうです。ただし、[#218] と違って、何故か else 節を NULL にするとうまく表示できません。

select Syurui, Meisyo, Jiki, Kaisu,
max(case Byogai when "べと病" then "●" else "" end) as beto,
max(case Byogai when "灰色かび病" then "●" else "" end) as haikabi,
max(case Byogai when "うどんこ病" then "●" else "" end) as udonko,
max(case Byogai when "斑点細菌病" then "●" else "" end) as hanten,
max(case Byogai when "褐斑病" then "●" else "" end) as kappan,
max(case Byogai when "菌核病" then "●" else "" end) as kinkaku
from tekiyou where Sakumotu like "きゅうり%" and
(Byogai = "べと病" or Byogai = "灰色かび病" or Byogai = "うどんこ病" or Byogai = "斑点細菌病" or Byogai = "褐斑病" or Byogai = "菌核病")
group by Meisyo
〔223〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/06 0:56)
引用なし
   　else 節が null だと order by Syurui がうまく使えなかったんですが、[#221] のように else "" にしたら order by が使えるようになりました。

select Syurui, Meisyo,
max(case when Sakumotu like "だいこん%" then Jiki||Kaisu else "" end) as Daikon,
max(case when Sakumotu like "はくさい%" then Jiki||Kaisu else "" end) as Hakusai,
max(case when Sakumotu like "ｷｬﾍﾞﾂ%" then Jiki||Kaisu else "" end) as Cabbege,
max(case when Sakumotu like "ﾌﾞﾛｯｺﾘｰ%" then Jiki||Kaisu else "" end) Broccoli
from tekiyou where
(Syurui like "%水和剤" or Syurui like "%乳剤") and Youto like "殺虫剤" and
(Sakumotu like "だいこん%" or Sakumotu like "はくさい%" or Sakumotu like "ｷｬﾍﾞﾂ%" or Sakumotu like "ﾌﾞﾛｯｺﾘｰ%")
group by Meisyo order by Syurui
〔225〕Re:複数作物の登録状況一覧
 kabe WEB  (06/06/06 22:43)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　指定作物の全農薬リストは、下記のようにサブクエリ無し集約関数のみで実現できました。
なるほど。サブクエリで作成した表を元にして転置しなきゃダメかなと思ったのですが、この方が簡単ですね。

>　いやしかし、やっぱり作物リストを指定するだけで SQL に展開してくれるような支援機能が欲しいですね。
SQL文さえわかれば、インターフェース部分はなんとかなると思います。

>　フィールド名に日本語を使用するか、Meisyou でも Meisho でも使えるようにエリアスを設定してもらえると良さそうです。
フィールド名は日本語、ローマ字どちらがよいでしょう。
エリアスというのはデータベース側に設定できるのですか。
〔226〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/06 23:25)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　Delphi の正規表現ライブラリに下記のようなものもありました。こちらは、(?...) 拡張構文に対応しているようです。試してませんが、UTF-8 なら恐らく日本語も問題なく使えると思います。
http://regexpstudio.com/TRegExpr/TRegExpr.html

　あと、展着剤や倉庫用農薬以外にも、ごくまれにではありますが、対象作物や対象病害虫フィールドに複数項目を「､」で区切って列挙されている農薬があります。これのために like '%ﾄﾏﾄ%' で検索すると、「ミニトマト」まで検索してしまいます。正規表現が使えれば、regexp '(^|､)ﾄﾏﾄ(､|$)' のような感じにすれば、「トマト」だけを検索することが可能です。
　少なくとも、SQLite 3.x には like 類似演算子として regexp が明記されています。ACFinder が使っているのは sqlite3.dll なので、dll 自体は正規表現を使用可能だと思います。にも関わらず egexp が使えないのは、ライブラリ側の問題である可能性が高いと思われます。下記ライブラリでも、regexp は使えませんかねえ？
http://www.torry.net/
〔227〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/06 23:45)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>SQL文さえわかれば、インターフェース部分はなんとかなると思います。
　よろしくお願いします。
　用途固定なら専用 UI もありだと思いますが、DMonkey 等でスクリプトマクロが使えると汎用的に使えて便利かもしれませんね(さらにマニアックな機能になってしまいますが^^;)。将来の拡張機能のひとつとしてご検討いただければと思います。
http://sourceforge.jp/projects/dmonkey/

>フィールド名は日本語、ローマ字どちらがよいでしょう。
　個人的にはフィールド名に日本語を使うのは好きではありませんが、いろんな人が使うことを考えると、日本語の方が取っつきやすいかもしれませんね。ローマ字は表記のフレの問題もあるので、日本語でなければ英語が良いかも…。

>エリアスというのはデータベース側に設定できるのですか。
　と思うのですが、やり方はよく分かりません(^_^;)。フィールド定義時に AS を使うのかなあ？
〔228〕Re:ACFinder LocalDB版
 Sekizuka  (06/06/07 16:17)
引用なし
   ＞kabeさん

>kabeです。はじめまして。

あ〜、はじめましてでしたっけ？
農薬ナビＭＬやei-netで一方的に名前を見かけていただけか。

改めて、はじめまして。今後ともよろしく。

>レジストリからWindowsのインターネットオプションのプロキシ設定を読めるようにすれば、いいのかなと思いますが、まだ試したことがありません。
>これは取り組んでみます。

ちなみにウチだとＩＥのメニュー→ツール→インターネットオプション→接続
とやると全てのボタンが灰色になってます。
セキュリティの関係で弄れないのはもちろん、内容も見れませんね。

私は移行期にプロクシの設定などを見ていたので、何とかなりましたが、、、

でも、firefoxの設定はＩＥから直接firefoxの機能で引っこ抜いたはずだから
直接レジストリからは読めるんだろうなぁ。
reditは起動できませんが。

余所の設定はどうなんでしょうね？
ウチのは厳しいのか甘いのかイマイチよくわかりませんが。

>Excelに依存せずデータ変換できるよう修正版を作成中です。
>もうしばらくお待ちください。
>ただ、データベースを作成したら、DBフォルダを含めて自宅PCにコピーすれば検索はできます。

了解しました。少し待ちます。
時間がかかるようでしたら、コピーでやってみます。
〔229〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/07 20:11)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　正規表現が使えれば、regexp '(^|､)ﾄﾏﾄ(､|$)' のような感じにすれば、「トマト」だけを検索することが可能です。
SQLite Spy(http://www.yunqa.de/delphi/sqlitespy/index.htm)を使うとこれが可能でした。このソフトは外部DLLの機能を内蔵しているみたいです。
正規表現検索部分は DIRegEx ライブラリを使っているようです。
SQLite Spy が使っていると思われるDISQLite3 というDelphi用のライブラリも同じサイトで公開されていますが、ダウンロードしてみたところ、どうも私のレベルでは使えそうもありません。
SQLite Spy で acis.db を開いて使うのが現状では最強かも(^^;

>下記ライブラリでも、regexp は使えませんかねえ？
>http://www.torry.net/
どれか、具体的に示していただければ…
〔230〕Re:複数作物の登録状況一覧
 kabe WEB  (06/06/07 21:32)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　用途固定なら専用 UI もありだと思いますが、DMonkey 等でスクリプトマクロが使えると汎用的に使えて便利かもしれませんね
う〜ん。私には難易度が高そう。

>　個人的にはフィールド名に日本語を使うのは好きではありませんが、いろんな人が使うことを考えると、日本語の方が取っつきやすいかもしれませんね。ローマ字は表記のフレの問題もあるので、日本語でなければ英語が良いかも…。
安易なんですが、自分ではローマ字が使いやすいですね。
ヘボン式ローマ字に統一しようと思います。
これでどうでしょう。
No,Yoto,Shurui,Meisho,Maker,Sakumotsu,Basho,Byogai,Mokuteki,
Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Chitai,
Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5

>>エリアスというのはデータベース側に設定できるのですか。
>　と思うのですが、やり方はよく分かりません(^_^;)。フィールド定義時に AS を使うのかなあ？
SQLを実行する前にフィールド名を置換するのであればできそうです。
根本的にユーザーにフィールド名を自由に設定してもらうという手もありですが…
〔231〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/07 23:58)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>う〜ん。私には難易度が高そう。
　ま、あくまでも将来の拡張機能のひとつってことで…。

>ヘボン式ローマ字に統一しようと思います。
>これでどうでしょう。
>No,Yoto,Shurui,Meisho,Maker,Sakumotsu,Basho,Byogai,Mokuteki,
>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Chitai,
>Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
　私自身はローマ字を使う時はヘボン式なので(タイプ数が少ないですから)大歓迎なんですが、これはこれでなれてない人が使うのは不便かもって感じもします。

>SQLを実行する前にフィールド名を置換するのであればできそうです。
　テーブル定義時にフィールドの別名を設定するのは無理っぽいですね。ということで、Delphi 側で 'sy' -> 'sh', 'ou' -> 'o', 'uu' -> 'u' の変換をしてやるのが一番簡単そうです。

>根本的にユーザーにフィールド名を自由に設定してもらうという手もありですが…
　テーブル別のフィールド番号／フィールド名対比表を持っていれば、ユーザが名前を付けても問題はないわけですね。ということは、INI ファイルにデフォルトでヘボン式ローマ字を記述しておき、必要に応じて書き換えてもらうのが一番自由度が高いかな。ただ、書き換える場合は、テーブルを作る前に書き換えてもらう必要がありますかね。
〔232〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/08 0:24)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>>下記ライブラリでも、regexp は使えませんかねえ？
>>http://www.torry.net/
>どれか、具体的に示していただければ…
　SQLite で検索して出てくるコンポーネントの内のどれかという意味でした。

　が、よくよく調べてみたら、ライブラリの問題ではなく、sqlite3.dll に regexp 演算子サポート関数が実装されていないのが、使用できない原因のようです。SQLite 3.2.2 からパーサが regexp 演算子を通すようになっていますが、UTF-8 ならsqlite3_create_function() でユーザ関数として追加しなければならないので、ちょっと面倒そうです。暇が出来たら、sqlite3.dll のソースで like 関数がどのように実装されているのか確認してみます。
　ちなみに、like 演算子もユーザ関数でオーバーライドできるようなので、これを正規表現対応にするなんて使い方もできそうです。

[1] http://www.sqlite.org/changes.html#version_3_2_2
Added a REGEXP operator to the parser. There is no function to back up this operator in the standard build but users can add their own using sqlite3_create_function()

[2] http://www.sqlite.org/lang_expr.html#regexp
The REGEXP operator is a special syntax for the regexp() user function. No regexp() user function is defined by default and so use of the REGEXP operator will normally result in an error message. If a user-defined function named "regexp" is defined at run-time, that function will be called in order to implement the REGEXP operator.
〔233〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/08 0:43)
引用なし
   Sekizuka さん、こん＊＊は。Hidemi Oya です。

>ちなみにウチだとＩＥのメニュー→ツール→インターネットオプション→接続
>とやると全てのボタンが灰色になってます。
　WindowsXp では、インターネットオプション等で使用される WinINet プロクシと、WinHTTP プロクシの２系統があり、たしかどちらかだけでも利用可能だと思いました。WinHTTP プロクシは、proxycfg コマンドで簡単に設定できるので、もしかするとこちらだけ設定しているのかもしれません。

>セキュリティの関係で弄れないのはもちろん、内容も見れませんね。
　もし WinHTTP プロクシが設定されているのだとすれば、コマンドプロンプトを起動して proxycfg を実行することで、内容が確認できるかもしれません。

>でも、firefoxの設定はＩＥから直接firefoxの機能で引っこ抜いたはずだから
>直接レジストリからは読めるんだろうなぁ。
　WinINet プロクシと WinHTTP プロクシはレジストリの場所が異なるので、プログラムで読むなら、両方確認する必要がありますね。

>余所の設定はどうなんでしょうね？
　埼玉県は、インターネットオプションで手動設定です。WinHTTP プロクシは使ってはいけないことになっているので、現在の Windows Update では自動更新／自動ダウンロードができません(というか、自動更新させないために WinHTTP プロクシを使わせないようです)。せめて自動ダウンロードくらいさせて欲しいものです。
〔234〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/08 1:02)
引用なし
   >　私自身はローマ字を使う時はヘボン式なので(タイプ数が少ないですから)大歓迎なんですが、これはこれでなれてない人が使うのは不便かもって感じもします。
　しまった、「ち」と「つ」は日本式ローマ字のちゃんぽんで使ってました(なぜならば、タイプ数が少ないから)。今回は関係ないけど、ヘボン式ローマ字では「ぢ」と「づ」は表現できないので、これは日本式を使わざるを得ませんね。
　ってことで、デフォルトヘボン式で、ユーザ自由設定方式が一番良いかもしれません。
〔235〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/08 23:53)
引用なし
   ＞Hidemi Oyaさん

web上からsql文を直で打てるようにしてみました。結果はtableで返します。

http://192.168.0.56/yaku_sql.html

データベースのテーブル名やカラム名がabeさんのと違うのでそのままでは動きません。調整しても使用時期と回数がうまく表示できませんでした。

何かアドバイスをいただけたらありがたいです。

−−−−−−−−−−−−−−−−−−−−−−−−−−−
select shurui, meishou,
max(case when sakumotsumei like "だいこん%" then jiki||shiyoukaisuu else "" end) as Daikon,
max(case when sakumotsumei like "はくさい%" then jiki||shiyoukaisuu else "" end) as Hakusai,
max(case when sakumotsumei like "キャベツ%" then jiki||shiyoukaisuu else "" end) as Cabbege,
max(case when sakumotsumei like "ブロッコリー%" then jiki||shiyoukaisuu else "" end) as Broccoli
from tekiyoubu where
(shurui like "%水和剤" or shurui like "%乳剤") and youto like "殺虫剤" and
(sakumotsumei like "だいこん%" or sakumotsumei like "はくさい%" or sakumotsumei like "キャベツ%" or sakumotsumei like "ブロッコリー%")
group by meishou order by shurui
−−−−−−−−−−−−−−−−−−−−−−−−−−−

ｐｓ
このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。
〔236〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 1:32)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>http://192.168.0.56/yaku_sql.html
　うっ、思わずそのままクリックしてしまいました(^_^;)。
http://otori.homes.com.au/yaku_sql.html
ですね。

>調整しても使用時期と回数がうまく表示できませんでした。
　MySQL には || 演算子による文字列結合が無いようで(バージョンによるかもしれません)、jiki||shiyoukaisuu の部分を concat(jiki, shiyoukaisuu) としなければならないようです。一応、下記で大丈夫そうです。

select shurui, meishou,
max(case when sakumotsumei like "だいこん%" then concat(jiki, shiyoukaisuu) else "" end) as Daikon,
max(case when sakumotsumei like "はくさい%" then concat(jiki, shiyoukaisuu) else "" end) as Hakusai,
max(case when sakumotsumei like "キャベツ%" then concat(jiki, shiyoukaisuu) else "" end) as Cabbege,
max(case when sakumotsumei like "ブロッコリー%" then concat(jiki, shiyoukaisuu) else "" end) as Broccoli
from tekiyoubu where
(shurui like "%水和剤" or shurui like "%乳剤") and youto like "殺虫剤" and
(sakumotsumei like "だいこん%" or sakumotsumei like "はくさい%" or sakumotsumei like "キャベツ%" or sakumotsumei like "ブロッコリー%")
group by meishou order by shurui

　ところで、yaku_sql.html の「出力時カラム数」って、いちいち数えなくてはならないので不便です。結果をどのように取り出しているか分かりませんが、DBI モジュールでは必ず行の内容が配列として参照できるはずなので、その配列の要素数でカラム数は分かりますよね。出力時カラム数が無設定の場合は、自動設定してくれるとうれしいです。一番単純なのは、
@row = $sth->fetchrow_array();
$colomuns = @row;
ですかね。fetchall_arrayref でも、行要素の配列として取り出した段階で同じです。

>このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。
　確かに、テーブル名やフィールド名は統一しておいた方が良いかもしれませんね。ただ、今回の || と concat のように DBMS によって異なる部分があるので、いずれにしても多少の書き換えは発生すると思います。
〔237〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/09 7:10)
引用なし
   ＞Hidemi Oyaさん

>>http://192.168.0.56/yaku_sql.html
>　うっ、思わずそのままクリックしてしまいました(^_^;)。
>http://otori.homes.com.au/yaku_sql.html
>ですね。

　これはローカル接続時のアドレスでした。大変失礼しました。(^^ゞ

>>調整しても使用時期と回数がうまく表示できませんでした。
>　MySQL には || 演算子による文字列結合が無いようで(バージョンによるかもしれません)、jiki||shiyoukaisuu の部分を concat(jiki, shiyoukaisuu) としなければならないようです。一応、下記で大丈夫そうです。

　ありがとうございます。concatってよく分かっていませんでした。

>　ところで、yaku_sql.html の「出力時カラム数」って、いちいち数えなくてはならないので不便です。結果をどのように取り出しているか分かりませんが、DBI モジュールでは必ず行の内容が配列として参照できるはずなので、その配列の要素数でカラム数は分かりますよね。出力時カラム数が無設定の場合は、自動設定してくれるとうれしいです。

　これは単純に手抜きでした。(^^ゞ　いつも結果をリストで取り出しているので、カラムの個数が分からなかったのです。データベースを呼び出すサブルーチンで、カラムの数も返すようにするのがいいかもしれません。

>>このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。
>　確かに、テーブル名やフィールド名は統一しておいた方が良いかもしれませんね。ただ、今回の || と concat のように DBMS によって異なる部分があるので、いずれにしても多少の書き換えは発生すると思います。

　私はローカル環境なので、httpdのエラーログが見えますが、普通の利用者はカラム名の間違いを自力で発見するのはとても難しいと思います。shとsyなど微妙なものも苦労しました。今回は２０カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(T.T)　名前の統一でこの苦労が無くなればアルゴリズムに意識を集中できると思います。(^^)
〔238〕Re:ACFinder LocalDB版
 Sekizuka  (06/06/09 13:05)
引用なし
   ＞Hidemi Oyaさん

>　埼玉県は、インターネットオプションで手動設定です。

ウチも２年程前はそうだったんですが、県庁情報課が直接所管（出先が自分で調達したものじゃない奴）するPCが増えるに連れ、設定を自動でできるように現状のシステムになっていったようです。
自動プロクシ設定スクリプトがどうたら、とかっていう時代もあったかな。

大分、本来の話題から逸れたので人柱（アルファ版）が終わって普及段階になったらまた考えましょう。
〔239〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/09 17:04)
引用なし
   Sekizuka さん、こん＊＊は。Hidemi Oya です。

>ウチも２年程前はそうだったんですが、県庁情報課が直接所管（出先が自分で調達したものじゃない奴）するPCが増えるに連れ、設定を自動でできるように現状のシステムになっていったようです。
>自動プロクシ設定スクリプトがどうたら、とかっていう時代もあったかな。
　なるほど、手動設定→自動構成スクリプト→自動検出になったということですね。そうすると、Firefox の「ツール(T)→オプション(O)→一般→接続設定(O)が、「このネットのプロキシ設定を自動検出する(W)」になってたりしませんか？

>大分、本来の話題から逸れたので人柱（アルファ版）が終わって普及段階になったらまた考えましょう。
　ただ、普及段階になる前に、自動検出でもレジストリから直接 proxy のアドレス等を読み出せるのかどうかを確認しておいた方が良いかもしれませんね。
〔240〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 17:48)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　これは単純に手抜きでした。(^^ゞ　いつも結果をリストで取り出しているので、カラムの個数が分からなかったのです。データベースを呼び出すサブルーチンで、カラムの数も返すようにするのがいいかもしれません。
　え〜と、結果をリストで取り出しているというのは、
($code, $torokunaum, $youto, $shurui, ...) = $sth->fetchrow_array();
のような左辺リストで受けているってことでしょうか？ select * で検索した結果ならそれもありだと思いますが、ユーザ SQL を実行するような場合は、どのフィールドがどういう順番でいくつ現れるかが分からないので、
@row = $sth->fetchrow_array();
のように配列で受けた方が楽じゃないですか？

　ちなみに、@row をスカラーで受けて要素数にしなくても、SELECT 文実行後に
$colomns = $sth->{NUM_OF_FIELDS};
でフィールド数(というかフィールド数−１かな？)は取得できるようです。
　また、
$colomun_name[0] = $sth->$sth->{NAME}->[0];
でフィールド名も取得できます。これを使えば、結果の表頭にフィールド名を入れることも可能ですね。

>　私はローカル環境なので、httpdのエラーログが見えますが、普通の利用者はカラム名の間違いを自力で発見するのはとても難しいと思います。shとsyなど微妙なものも苦労しました。今回は２０カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(T.T)　名前の統一でこの苦労が無くなればアルゴリズムに意識を集中できると思います。(^^)
　ですね。s_kobayashi さんのフィールド名には tekiyoubyougaichuu みたいに長すぎてタイプミスを頻発しそうなのがあるので、できれば分かる範囲で短く統一するのが良いと思います。[#230] をベースに検討するってのでどうでしょう？

　ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう？
〔241〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 20:38)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう？
　そうか、登録番号はユニークだけど、同じ登録番号で複数の登録内容が存在するからですね。
〔242〕Re:フィールド名
 kabe WEB  (06/06/10 5:23)
引用なし
   ＞Hidemi Oyaさん
＞s_kobayashi さん　資格試験サイト活用させていただいております。

kabe です。

>　ですね。s_kobayashi さんのフィールド名には tekiyoubyougaichuu みたいに長すぎてタイプミスを頻発しそうなのがあるので、できれば分かる範囲で短く統一するのが良いと思います。[#230] をベースに検討するってのでどうでしょう？
ACFinderの手元のバージョンでは次のように設定しました。
どんなもんでしょう。
登録適用部　テーブル名 tekiyou
No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
私も、どうも tsu chi よりは tu ti と打ってしまいます。

このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。
屋号抜き農薬名で検索できるよう次のようなビューを作成し
CREATE VIEW vTekiyou AS SELECT DISTINCT Sakumotu,Byogai,Tusho,Jiki,Baisu,Ekiryo,
Hoho,Kunjojikan,Kunjoondo,Titai,Noyaku,Kongo,
Kaisu,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5,Yoto
FROM tekiyou;
これを元に作物、病害虫の検索をするモードを付けようかなと思っています。

Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。
〔243〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/10 5:38)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　ただ、普及段階になる前に、自動検出でもレジストリから直接 proxy のアドレス等を読み出せるのかどうかを確認しておいた方が良いかもしれませんね。

プロキシの検出は、少し後回しになりますが、いずれは付けたいと思います。
ただ自動プロキシのスクリプト解釈をACFinderに付けるのは多分難しいです。
うちの県も、以前は自動プロキシだったのですが、いつの頃からか無くなってしまいました。その頃は自動プロクシのファイル中に書いてあるIPアドレスからプロキシサーバ名を推定して、必要なソフトにIPアドレスを直接指定したりしてました。
〔244〕Re:フィールド名
 s_kobayashi  (06/06/10 8:01)
引用なし
   ＞kabeさん

ご無沙汰しています。(^^)

>ACFinderの手元のバージョンでは次のように設定しました。
>どんなもんでしょう。
>登録適用部　テーブル名 tekiyou
>No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
>Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
>ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
>私も、どうも tsu chi よりは tu ti と打ってしまいます。

少し直感的でないと感じる部分があったので、改善案です。

no,youto,shurui,meisho,tusho,maker,sakumotu,basho,byogaichu,mokuteki,
baisu,ekiryo,jiki,kaisu,houho,kunjojikan,kunjoondo,dojo,titai,
tekiyaku,kongo,kaisu1,kaisu2,kaisu3,kaisu4,kaisu5

改善案
（１）小文字に統一（入力労力の軽減）
（２）Byogai→byogaichu
（３）Hoho→houho
（４）Noyaku→tekiyaku（誤解を無くすため造語）

>このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。

これはあった方が良いですね。ニーズが高い割に、オンデマンドで処理するには負担が重いですから。

>Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
>大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。

今はどんな使われ方をするか模索している段階なので、フィールドを減らすのは避けた方が良いでしょう。

ちょっと話は脱線しますが。

Windows環境では半角カナも特に問題はないと思いますが、linuxやhtmlなど一部の環境では半角カナは非常に取り扱いにくい場合があります。入力する際も半角カナは不便なので、できれば全角カナで取扱いするほうがいいでしょう。私の農薬検索では、データベース構築時に半角カナはunicode正規化のNFKCを掛け、さらに機種依存文字「リットル」などの置換をしています。半角英数字は変化無しです。

ACFinderでも同様の事前処理を行えば、データ内容やsql文も汎用性、共通性が高まると思います。いかがなものでしょうか。
〔245〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/10 8:11)
引用なし
   ＞Hidemi Oyaさん

>>　ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう？
>　そうか、登録番号はユニークだけど、同じ登録番号で複数の登録内容が存在するからですね。

　作ったときはそこまで考えていませんでした。連続したユニークな番号が保証されていると、レコードを順位付けをする場合に便利なので、１個目のカラムはオートインクリメントで番号を振るようにしています。(^^ゞ
〔246〕Re:フィールド名
 s_kobayashi  (06/06/10 8:20)
引用なし
   >改善案
>（１）小文字に統一（入力労力の軽減）
>（２）Byogai→byogaichu
>（３）Hoho→houho
>（４）Noyaku→tekiyaku（誤解を無くすため造語）

（１）小文字に統一（入力労力の軽減）
（２）Yoto→youto
（３）Byogai→byogaichu
（４）Hoho→houho
（５）Noyaku→tekiyaku（誤解を無くすため造語）

　抜けてました。(^^ゞ
〔247〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 14:28)
引用なし
   kabe さん、早朝からご苦労様です。Hidemi Oya です。

　実は、昨夜テーブル名／フィールド名統一の新スレッドを立てようと発言を書き始めたんですが、睡魔に襲われて挫折してしまいました。すでにこのスレッドで議論が始まりましたので、このスレッドが巨大化しすぎるかなという懸念はあるものの、ここで続けさせてもらいます。

>No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
　Maker は、元データの「略称」のことでしょうか？ 英語とローマ字のチャンポンは分かりにくいので、ローマ字に統一した方が良いと思います。下記のように、元データの一部を切り出したローマ字にするというのを原則としませんか？
登録番号→番号→bango
略称→ryakusho

>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
　kunjojikan, kunjoondo は長いですし、他にかぶる項目もないので jikan, ondo でも良さそうです。

>ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
>私も、どうも tsu chi よりは tu ti と打ってしまいます。
　訓令式や日本式の撥音記号(')はフィールド名としては使えませんし、長音記号は入力できませんので、ヘボン式で統一するのは賛成です。が、部分的にヘボン式以外を採用してしまうと分かりにくくなるので、これは避けた方が良いと思います。
　ただし、syo と sho、chi と ti などは慣れていないとタイプミスを頻発する可能性が高いので、表記のフレについてはフロントエンド変換で対応するってのでどうでしょう？ $sql に SQL 文が入っているとして、perl で書くと以下のようなフロントエンド変換を行うってことです。動作確認はしてませんけど(mg オプションじゃなくて sg オプションの方が良いのかな)。

$sql =~ s/sy([aou])/sh\1/mg; # 部分一括変換で問題は発生しないはず
$sql =~ s/ty[aou]/ch\1/mg;
$sql =~ s/(ngo)u/\1/mg; # bangou, kongou → bango, kongo
$sql =~ s/youto/yoto/mg;
$sql =~ s/ts?uu?sho/tsusho/mg; # tusho, tuusho, tsuusho → tsusho
$sql =~ s/([iu]sho)u/\1/mg; # meishou, tsushou, ryakushou の最後の u 削除
$sql =~ s/motsu/motu/mg; # sakumotu → sakumotsu
$sql =~ s/byou?gaichuu?/byogaichu/mg; # byougauchuu, byougaichu, byogaichuu → byogaichu
$sql =~ s/suu/su/mg; # baisuu, kaisuu → baisu, kaisu
$sql =~ s/(ryo)u/\1/mg; # ekiryou → ekiyo
$sql =~ s/hou?hou?/hoho/mg; # houho, hohou, houhou → hoho
$sql =~ s/(dojo)u/\1/mg;
$sql =~ s/titai/chitai/mg;
$sql =~ s/nouya/noya/mg; # nouyaku → noyaku

>このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。
　どうやって屋号を抜くかはさらに検討する必要がありますが、後の利用を考えるとこれはぜひ欲しいデータですね。

>屋号抜き農薬名で検索できるよう次のようなビューを作成し
　MySQL 3.x/4.x ではビューが使えないですし、例示のような場合は必ずしもビューが必要ではないので(ビューを使うと select * from vekiyo ですむので楽ですが)、なるべくビューを使わない方がいろいろなシステムで使えて良いですね。

>Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
>大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。
　キルパー、殺虫プレートなど使用方法が長文で、かつくん蒸時間にもデータが入っている農薬があるので、全部を使用方法に入れてしまうのはどうかと思います。くん蒸温度が入っている農薬は少ないので、くん蒸時間とくん蒸温度をひとつのフィールドにまとめるのは問題ないと思いますが…。
　SQLite は特殊なので内部保存方法がよく分かりませんが、MySQL のような一般的な DBMS では、varchar(55) のフィールドはデータがあろうがなかろうが 56 バイトの領域が確保されますが、CLOB(TEXT) フィールドなら実体へのポインタだけの領域しか使用しません。そういう意味では、データ出現頻度が少なくて varchar(3) を超えるものは CLOB(TEXT) 型(MySQL なら TINYTEXT)にした方が良いのかもしれませんね。この辺のデータを検索条件にすることはほとんどないでしょうから、検索速度向上のために INDEX を作成する必要もありませんし。
〔248〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:07)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>（１）小文字に統一（入力労力の軽減）
　テーブル名は OS によってケース依存するので、小文字統一とかに規定した方が良いですね。フィールド名は、余程特殊な DBMS でなければケース非依存なので、あまり気にする必要はないかと思いますが、私も小文字統一に一票。

>（２）Yoto→youto
>（４）Hoho→houho
　見た目の直感性ということでしょうか？ これだと、meisho 等との一貫性がなくなり(houho なんかこれだけでも一貫性に欠けます)、入力時に間違える可能性が大です。結果表示の際には、フィールド名を元データの項目名で表示するようにすればフィールド名の見た目を重視する必要はないので、フィールド名はヘボン式を原則とした方が良いと思います。

>（５）Noyaku→tekiyaku（誤解を無くすため造語）
　適用地帯名を「地帯」と省略するなら、適用農薬名は「農薬」と省略しないと一貫性に欠けて分かりづらくなります。項目名とフィールド名の対応表を参照しなくてもフィールド名を入力できるようにするには、省略のしかたに一貫性を持たせるべきだと思います。
　上記同様に、結果表示時にはフィールド名を元データの項目名で表示するようにすれば問題はないと思いますが？
〔249〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:21)
引用なし
   >　SQLite は特殊なので内部保存方法がよく分かりませんが、MySQL のような一般的な DBMS では、varchar(55) のフィールドはデータがあろうがなかろうが 56 バイトの領域が確保されますが、CLOB(TEXT) フィールドなら実体へのポインタだけの領域しか使用しません。
　MySQL では、varchar でも格納域は可変ですね。ということは、レコード内の実データとしては格納域へのポインタを持っているだけかな？
　いずれにしろ、可変長文字列型を使っていれば、データベースサイズの肥大は気にしなくても良いということになりそうです。
〔250〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:48)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>これはあった方が良いですね。ニーズが高い割に、オンデマンドで処理するには負担が重いですから。
　macs for acis のようなやり方なら、それほど負荷は高くありません。が、SQL 段階で結果を通称でグルーピングするなどができた方が便利なのは、間違いありませんね。
　ということで、このデータを持つのは大賛成なんですが、問題はどうやって屋号を削除するかです。macs for acis の tm.pm では、完全に屋号を削除できる自信は今のところありません。

>Windows環境では半角カナも特に問題はないと思いますが、linuxやhtmlなど一部の環境では半角カナは非常に取り扱いにくい場合があります。入力する際も半角カナは不便なので、できれば全角カナで取扱いするほうがいいでしょう。
　おっしゃるとおりだと思います。さらに付け加えていうなら、SQL 直書きの際に、「きゅうり」と「トマト」のようにひらがな／カタカナが混在というのも困りものです。検索条件として使用する可能性が高い適用作物名と適用病害虫雑草名については、カタカナをひらがなに変換したフィールドを追加し、検索条件は追加フィールドを使って全てひらがなで指定できるようになるとうれしいです(カタカナフィールドでも良いのですが、カタカナだと IME でひらがなからカタカナに変換するステップがひとつ増えてしまうので)。漢字→ひらがなは自動変換できないので、完全ひらがな入力はあきらめるしか無いですが…。
〔251〕ACFinder 要望追加
 Hidemi Oya WEB  (06/06/10 17:33)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　昨夜母ちゃん(同業者です)に頼まれて、複数作物の登録状況一覧を作成して CSV ファイルに保存して気づいたんですが、CSV の先頭にフィールド名が付かないんですね。StringGrid のヘッダにはフィールド名または項目名が表示されるようになっているので、CSV にも先頭に付けてもらえるとありがたいです。
〔252〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/10 18:08)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>ただ自動プロキシのスクリプト解釈をACFinderに付けるのは多分難しいです。
　自動構成スクリプトの場合、起動時にスクリプトを実行して、レジストリにプロクシの設定が書き込まれると思ってたんですが、レジストリに保存しないで接続のたびにスクリプトを実行してるんでしょうか？
　だとすると、WPAD による自動検出(DHCP や DNS の情報を使ってスクリプトサーバを自動的に探す)でも設定には同じスクリプトを用いるので、レジストリにプロクシ設定が書き込まれる可能性は皆無ですね。

>うちの県も、以前は自動プロキシだったのですが、いつの頃からか無くなってしまいました。
　自動構成スクリプトだったのが自動検出になったということでしょうか？

　いずれにしても、自動検出や自動構成でレジストリの
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer
や
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\WinHttpSettings
に設定が保存されているかどうかを確認してみる必要があると思います。で、どこにも保存されていなければ、自動検出や自動構成を実行するのがベストかと…。WinINet または WinHTTP の API に直接実行できる関数があれば楽ですが、まだそこまで探せていません。
〔253〕Re:フィールド名
 s_kobayashi  (06/06/10 18:32)
引用なし
   ＞Hidemi Oyaさん

>>（１）小文字に統一（入力労力の軽減）
>　テーブル名は OS によってケース依存するので、小文字統一とかに規定した方が良いですね。フィールド名は、余程特殊な DBMS でなければケース非依存なので、あまり気にする必要はないかと思いますが、私も小文字統一に一票。
>
>>（２）Yoto→youto
>>（４）Hoho→houho
>　見た目の直感性ということでしょうか？ これだと、meisho 等との一貫性がなくなり(houho なんかこれだけでも一貫性に欠けます)、入力時に間違える可能性が大です。結果表示の際には、フィールド名を元データの項目名で表示するようにすればフィールド名の見た目を重視する必要はないので、フィールド名はヘボン式を原則とした方が良いと思います。

　了解しました。

>>（５）Noyaku→tekiyaku（誤解を無くすため造語）
>　適用地帯名を「地帯」と省略するなら、適用農薬名は「農薬」と省略しないと一貫性に欠けて分かりづらくなります。項目名とフィールド名の対応表を参照しなくてもフィールド名を入力できるようにするには、省略のしかたに一貫性を持たせるべきだと思います。

　ここはかなり引っかかります。省略ルールを統一してtekiti,tekinoなどにする訳にはいかないでしょうか。今後、独自のフィールド名を追加するのであればなおさら「適」から始まる省略名にしておく方が、出所が明確になっていいと思います。実際には展着剤でしか使用されないマイナーな欄ですので多少わかりにくい名前でも良いでしょう。
〔254〕ACFinder 060610版
 kabe WEB  (06/06/10 21:38)
引用なし
   kabe です。

暫定修正版？です。
http://acfinder.kabe.info/

データベース作成の時間をかなり短縮しました。
Excelファイルからダイレクトにデータベースファイルに変換します。
変換作業にはExcelは不用です。
Excelがインストールされていない PC でも OKです。

検索機能については、農薬通称（屋号抜き）で表示するモードを追加してみました。
作物名は前よりは融通がきくようにしていますが、検証が不十分です。
ほとんど動作確認できていませんので、バグ出しにご協力ください。

テーブル kihon
seibun,nodo,zaikei
テーブル tekiyo
bango,yoto,shurui,meisho,tsusho,ryakusho,sakumotsu,basho,byochu,mokutek,
baisu,ekiryo,jiki,kaisu,hoho,jikan,ondo,dojo,chitai,noyaku,kongo,
kaisu1,kaisu2,kaisu3,kaisu4,kaisu5'

ですが、作物、病害虫検索については独自にビューを作成して検索しています。
〔255〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/10 23:05)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>暫定修正版？です。
　早速のアップデートお疲れ様です。

>データベース作成の時間をかなり短縮しました。
　一番時間がかかっていた CSV の正規化部分がなくなり、かなり速くなりましたね。前バージョンではちょっとデータ更新をためらう速度でしたが、今回は許容範囲かなという感じです。
　中間ファイルができなくなったのも HDD に優しくて良いです。

>検索機能については、農薬通称（屋号抜き）で表示するモードを追加してみました。
　これはなかなかいいですね。やはり、我々の用途ではこうでなくっちゃ！
　ただ、ツールバーだと、ボタンの表示状態が変わるとはいえ、ちょっと分かりづらいかも…。それと、検索表示が高速なので、ツールバーのボタンをクリックしたら表示も即座に切り替わる方が良いかもしれません。
　なお、通称対応版複数作物登録一覧を試している時に、以下の点について気が付きました。
イヅツＤＤＶＰ５０％乳剤の「イヅツ」が取れていない
シンジェンタ・トレボン乳剤の「・」が取れていない

>作物名は前よりは融通がきくようにしていますが、検証が不十分です。
　いいですねえ〜。ちょっと試しただけですが、「ｷｬﾍﾞﾂ」は「キャベツ」や「きゃべつ」で、「はくさい」は「ハクサイ」や「ﾊｸｻｲ」でも検索できました。文字列を確定してからのエンターキーの押下で検索実行されるのも good です。
　これが SQL でも使えると、すっごくありがたいんですけどね。=, <> や like などの比較演算子の右側にある文字列リテラルをだけを同じように変換するってできないんでしょうか？

　SQL にスクロールバーが付いたのと、条件消去で SQL も消去されるようになったのはありがたいです。

　通称対応版複数作物登録一覧を試している際に、もうひとつ気が付いた点があります。今バージョンでは、
max(case when sakumotsu like "だいこん%" then jiki||kaisu else "" end) だいこん
のようにフィールドエリアスに日本語を使ってもエラーにならなくなりましたが、AS を付けてもシングルクォートやダブルクォートで括ってみても、ヘッダにフィールド名が表示されません。これで、ヘッダに日本語が表示されるようになれば完璧です。
〔256〕複数作物の登録状況一覧 SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/10 23:09)
引用なし
   　ACFinder 060610 版の新機能である「農薬通称」による複数作物の登録状況一覧の SQL 例です。

　[#218] の例では、農薬の種類を「水和剤」と「乳剤」に限定していたので、「水溶剤」が表示されませんでした。今回は、使用方法が「散布」で、農薬の種類が「粉剤」「粒剤」以外という条件に変更しています。このクエリの用途からいうと、「粉剤」は表示した方が良いかもしれませんが…。

select shurui, tsusho,
max(case when sakumotsu like "だいこん%" then jiki||kaisu else "" end) as daikon,
max(case when sakumotsu like "はくさい%" then jiki||kaisu else "" end) as hakusai,
max(case when sakumotsu like "ｷｬﾍﾞﾂ%" then jiki||kaisu else "" end) as cabbege,
max(case when sakumotsu like "ﾌﾞﾛｯｺﾘｰ%" then jiki||kaisu else "" end) as broccoli
from tekiyo where
yoto = "殺虫剤" and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(sakumotsu like "だいこん%" or sakumotsu like "はくさい%" or sakumotsu like "ｷｬﾍﾞﾂ%" or sakumotsu like "ﾌﾞﾛｯｺﾘｰ%")
group by tsusho order by shurui
〔257〕Re:フィールド名
 Hidemi Oya WEB  (06/06/11 0:05)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　ここはかなり引っかかります。省略ルールを統一してtekiti,tekinoなどにする訳にはいかないでしょうか。
　省略のしかたに一貫性があれば、それで良いと思います。が、「適用○○」については、適用地帯名と適用農薬名の他に、適用場所／適用病害虫雑草名／適用土壌とあって、一貫性を保つためにこれら全てを teki... とするのはかなり違和感があり、本末転倒になってしまいますね。

　kabe さんが、ACFinder 060610 版で適用病害虫雑草名を byochu とされています。確かに、byogaichu ではちょっと長すぎる感はなきにしもあらずです。検索条件としてよく使用するフィールドなので、短いにこしたことはありません。
　逆に、適用農薬名は普通のクエリで使用することはまずないでしょうから、一貫性に欠けてても問題が出ることはないでしょう。

　ということで、適用病害虫雑草名と適用農薬名に限っては、例外的に一貫性のない略称を採用するってのが最も使いやすい落としどころのようですね。適用病害虫雑草名は kabe さん案の byochu、適用農薬名は s_kobayashi の第１案 tekiyaku が無難でしょうか…。
〔258〕対象病害虫一覧の SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/11 0:32)
引用なし
   　ACFinder 060610 版の新機能である「農薬通称」による、対象病害虫一覧の SQL 例です。

　今回は希釈倍数・使用量も表示するようにしてみました。対象病害虫によって希釈倍数が異なる場合は薄い方を表示するようにしてあります。たとえば、「1000倍」と「1000〜2000倍」があれば「1000〜2000倍」、「1000〜2000倍」と「2000倍」があれば「2000倍」が表示されます。
　ただし、MAX 関数は左側から順に大小判定をするようで、「500倍」と「1000倍」がある場合は「500倍」が表示されてしまいます。今のところ、これを解決する方法は不明です(^_^;)。

select shurui, tsusho, max(baisu) as baisu, jiki, kaisu,
max(case byochu when "べと病" then "●" else "" end) as beto,
max(case byochu when "灰色かび病" then "●" else "" end) as haikabi,
max(case byochu when "うどんこ病" then "●" else "" end) as udonko,
max(case byochu when "斑点細菌病" then "●" else "" end) as hanten,
max(case byochu when "褐斑病" then "●" else "" end) as kappan,
max(case byochu when "菌核病" then "●" else "" end) as kinkaku
from tekiyo where sakumotsu like "きゅうり%" and hoho = "散布" and
(byochu = "べと病" or byochu = "灰色かび病" or byochu = "うどんこ病" or byochu = "斑点細菌病" or byochu = "褐斑病" or byochu = "菌核病")
group by tsusho order by shurui
〔259〕Re:対象病害虫一覧の SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/11 1:04)
引用なし
   　農薬通称で一括する場合は農薬数が少ないので、当面 MAX 関数を使わずに希釈倍数でグルーピングして、希釈倍数が異なるモノを全て列挙するようにした方が間違いがないですね。
　ついでに、「きゅうり」ならなんでもではなく、「きゅうり」と「きゅうり（施設栽培）」だけにしてみました。

select shurui, tsusho, baisu, jiki, kaisu,
max(case byochu when "べと病" then "●" else "" end) as beto,
max(case byochu when "灰色かび病" then "●" else "" end) as haikabi,
max(case byochu when "うどんこ病" then "●" else "" end) as udonko,
max(case byochu when "斑点細菌病" then "●" else "" end) as hanten,
max(case byochu when "褐斑病" then "●" else "" end) as kappan,
max(case byochu when "菌核病" then "●" else "" end) as kinkaku
from tekiyo where (sakumotsu = "きゅうり" or sakumotsu = "きゅうり（施設栽培）") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(byochu = "べと病" or byochu = "灰色かび病" or byochu = "うどんこ病" or byochu = "斑点細菌病" or byochu = "褐斑病" or byochu = "菌核病")
group by baisu, tsusho order by shurui
〔260〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 1:39)
引用なし
   要望をもう一つ追加です。

　データベース更新がかなり速くなったとはいえ、待ち時間いらずというわけにはいきません。SQLite はデータベースファイルを共有しても問題なく使用できるように作られているようなので、事務所で使うような場合は、基本設定にデータベースパスを追加して、データベースファイルを共有できると良いですね。これだと、誰かが更新すれば、他の人は更新しなくてすみます。
　システム全体をサーバにおいて共有すれば、上記のような設定は不要になりますが、確か農薬ナビ版や農薬検査所版ではこういう使い方はできませんでした。試してないけど、今バージョンは大丈夫なのかな？
〔261〕Re:複数作物の登録状況一覧 SQL 例（通称対...
 Hidemi Oya WEB  (06/06/11 8:46)
引用なし
   　農薬通称だと検索農薬数が激減するので、用途を表示して、「殺虫剤」「殺菌剤」「殺虫殺菌剤」を一括して検索するという手もありますね（稲では農薬数が多すぎて使えませんが）。

select yoto, shurui, tsusho,
max(case when sakumotsu like "だいこん%" then jiki||"、 "||kaisu else "" end) as daikon,
max(case when sakumotsu like "はくさい%" then jiki||"、 "||kaisu else "" end) as hakusai,
max(case when sakumotsu like "ｷｬﾍﾞﾂ%" then jiki||"、 "||kaisu else "" end) as cabbege,
max(case when sakumotsu like "ﾌﾞﾛｯｺﾘｰ%" then jiki||"、 "||kaisu else "" end) as broccoli
from tekiyo where
(yoto like "殺虫%" or yoto like "%殺菌剤") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(sakumotsu like "だいこん%" or sakumotsu like "はくさい%" or sakumotsu like "ｷｬﾍﾞﾂ%" or sakumotsu like "ﾌﾞﾛｯｺﾘｰ%")
group by tsusho order by yoto, shurui, tsusho
〔262〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 10:28)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　作物名のワイルドカードですが、「不知火」や「温州」のように全部漢字だと、'%不知火%' のようにキーワードの両サイドに付きますが、「温州みかん」や「ぽんかん」だと 'ぽんかん%' と末尾にのみ付きます。このため、植調剤（ジベレリン、MCPB）のように作物名が「かんきつ（温州みかん、伊予柑、不知火、サガマンダリン、ぽんかん）」のような表記の農薬は、「不知火」は全部検索できても「ぽんかん」は検索落ちが発生します。
　おそらく、「ねぎ」と「たまねぎ」や、「トマト」と「ミニトマト」を区別するために、ひらがな／カタカナが混ざっているものはワイルドカードを末尾のみに付ける仕様にしてあるのだと推測します。上記のようなケースでなくても、'%なす%' で検索すると「野菜類（なすを除く）」まで拾ってきてしまうという弊害も出ますしね。
　とはいえ、最初のジベレリンのようなケースを検索できないのも不便なので、ワイルドカードの自動付与は一律末尾のみにし、頭に付けたい場合はユーザが自分で付けるってのでどうでしょう？

　正規表現が使えれば、上記の何れのケースにでも対応できる検索条件を自動的に設定することが可能です。暇が出来たら、Delphi での実装を検討してみます。
〔263〕作物名の数字が全角に(;_;)
 Hidemi Oya WEB  (06/06/11 10:52)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>作物名は前よりは融通がきくようにしていますが、検証が不十分です。
　「ぶどう(巨峰系4倍体品種)」が「ぶどう(巨峰系４倍体品種)」に変換されてしまい、検索できません。「ぶどう(2倍体欧州系品種)」等も同様です。
　とりあえず、現行のデータ保存方法では、作物名の数字は全角変換しないようにする必要がありますね。
〔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
〔265〕Re:ACFinder 060610版
 s_kobayashi  (06/06/11 12:09)
引用なし
   ＞kabeさん

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

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

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

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

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

（５）sqlからdeleteやdrop tableができました。そのような使い方をすることはほとんどないので、検索のみに権限を制限する方が良いと思います。
〔266〕屋号
 Hidemi Oya WEB  (06/06/11 17:30)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

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

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

　また、多数の屋号が存在する「硫酸銅」「(粉末)生石灰」「石灰硫黄合剤」「石灰窒素」「エムダイファー」については、登録屋号を削除するのではなく、通称の前にある文字を全て削除するようにしています。
〔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 では削除して同一通称としていますが、これは携帯電話の小さな画面ではこれらを別表示にすると使いづらくなることと、表示する適用があくまでも個々の名称の農薬のモノであることが明確だからです。

>（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）
　各レコードにですか？ どのような用途を想定しているのでしょう？
〔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節やサブクエリで十分対応できそうです。
〔269〕Re:屋号
 Hidemi Oya WEB  (06/06/11 20:40)
引用なし
   >kabe さん、こん＊＊は。Hidemi Oya です。

>　Delphi だと、
>(1) 屋号前後の「」〔〕［］を削除
>(2) 屋号直後の接尾語を削除
>って感じで処理できるのでは？
　'」〕］'の後ろに '・−印の　' が付くことはないでしょうから、
(1) 屋号直前の '「〔［' を削除
(2) 屋号直後の '」〕］・−印の　' を削除
の方がプログラムは楽かもしれませんね。
〔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 に変更しました。
〔271〕Re:ACFinder 060611版
 kabe WEB  (06/06/11 21:09)
引用なし
   kabe です

CSV保存時に列名も付けるようにしました。
〔272〕Re:ACFinder 060610版
 kabe WEB  (06/06/11 21:19)
引用なし
   ＞Hidemi Oyaさん
＞s_kobayashi さん

kabe です。

>>（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。
>　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ
ここまでは無理としても、将来的に簡易な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 変換していただけるとうれしいです。
〔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」のページコントロールがツールバーに入っていて、結果表示用のストリンググリッドとリンクしていません。このページコントロールをツールバーから出してクライアント領域全体に置き、それぞれのタブの中に設定パネルとストリンググリッドを持つようにするってのはどうでしょう？(ログペインも共用型じゃなくてタブごとに独立してる方が良いかな？)
　これなら、それほど大きな変更なしに、少なくとも３項目の結果を独立して見ることができます。
〔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」を呼び出して、エクセル印刷ボタンを押せばデラウエアに登録のある農薬（対象作物が落葉果樹、ぶどう、少粒種ぶどう、ぶどう（デラウエア）…のもの、但し県使用自粛農薬を除外）を検索し、結果をエクセルファイルに書き出し、印刷もしてくれるというような機能です。

　ま、このあたりは単なるアイデアですので、あんまり気にしないでください。(^^ゞ
〔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 の方が向いているかな…。
〔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 変換していただけるとうれしいです。
ここは修正します。
〔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 キン核
〔279〕Re:ACFinder 060611版
 Hidemi Oya WEB  (06/06/12 23:02)
引用なし
   >　'病' が入ると 'misuse of aggregate' になるので、集約関数の一部として認識されてしまっているということですかねえ？
　'病' の後ろに '病1' のように何か文字を付けるとエラーが出なくなります。どんな文字を付加しても、列表示は '?E' となります。やはり、ShiftJIS -> UTF-8 変換の際に化けているようです。
〔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 は識別子直後のエンコード文字列をデコードして表示する
といった作業が必要ですね。
〔281〕Re:日本語フィールドが使えないのは sqlit...
 Hidemi Oya WEB  (06/06/13 20:34)
引用なし
   >フィールド名は UTF-8 であっても大文字／小文字変換をしてしまっているというのが、文字化けの原因だと考えられます。
　ってことは、フィールド名をケース依存にする
PRAGAM case_sensitive_column_name = 1;
なんてプラグマがあれば簡単に対応できるなと思ったんですが、残念ながらありませんでした(;_;)。やはり、Delphi 側で処理するしかなさそうです。
〔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 の方が向いているかな…。

　それでもいいですね。
〔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 テンプレートを用意し、ユーザが選択した条件に基づいてその部分をシステムが自動的に書き換えて検索を実行する。
〔284〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 23:16)
引用なし
   ＞Hidemi Oyaさん

>　ということなら、同じですね。[#274] はあくまでも「簡易 SQL エディタ」に関する提案であり、通常の使い方に関しては [#276] の
>>私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
>が希望です。[#275] を読んだ時は、ユーザが SQL タブを使用することを前提として、それを如何に簡単に使えるようするかという提案のように感じたもので(^_^;)。

　わたしがちょっと思考硬直化していたかもしれません。上の文を読んで、定型処理をどんどん増やすような印象を持ってしまいました。(^^ゞ　私は複雑であまり使われない機能のタブを増やすのには抵抗があります。

　私のイメージする用途では、定型処理だけで対応できるものが２〜３割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが７〜８割くらいあります。oyaさんが提案された商品名、作物名、使用前日数、使用方法の二次元リストなどはSQLの面目躍如という感じです。

　oyaさんが示された新ユーザーインターフェイスはイメージがよくつかめていませんが、モックアップが完成したらぜひトライしてみます。(^^)
〔286〕成分ごとの総使用回数
 Hidemi Oya WEB  (06/06/16 13:06)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　現在「作物・病害虫」タブなどで表示される検索結果は、成分ごとの総使用回数の成分名が分かりません。たとえば、リドミルＭＺ水和剤は、名称から考えると成分１がメタラキシル、成分２がマンゼブのように思えますが、実は逆になっています。これでは、有効成分ごとの総使用回数遵守は困難です。
　ってことで、標準タブの検索結果については、kihon テーブルから seibun フィールドの値を参照してきて、'有効成分名１', '総使用回数１', '有効成分名２', '総使用回数２' のように表示するようにしてもらえると助かります。kihon テーブルに成分番号がないので、どうやって参照するかちょっと頭を捻る必要がありそうですが…。
〔288〕「にがうり」が「ニガうり」に
 Hidemi Oya WEB  (06/06/16 14:35)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　「作物・病害虫」タブの作物名テキストボックスに「にがうり」と入力すると、「ニガうり」と変換されてしまいます。作物名ボタンをクリックして選択した場合は OK です。
〔289〕データベース共有
 Hidemi Oya WEB  (06/06/16 15:21)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>データベースファイルの設置場所を自由に設定できるようにしてみました。
　ドライブ割り当てした共有フォルダはもちろん、UNC でも使えました。ただ、共有フォルダを指定する際に、時々ゼロ除算エラーが表示されることがあります。
　あと、ふと思ったんですが、データベースを共有する場合、２重更新対策はされているでしょうか？ 先に使っている誰かが新データに更新中（更新完了はしていない状態）なら、後から使おうとした人は更新しないようになってないと無駄が出ますね。

>一応 LAN内の共有フォルダに置いた場合も検索できるようですが、パフォーマンスは不明です。
　パフォーマンスは、100Mbps ならそれほど問題はなさそうですが、ローカル使用時の速さになれているとかなり遅く感じます。100Mbps でこれだと、11Mbps の無線 LAN を利用している人はちょっと辛いかもしれません。
　データベース更新時間の短縮と検索速度の低下防止を両立させるには、単純にデータベースファイルを共有するのではなく、下記のようにファイルサーバでデータベース更新だけをしておき、使用する際はそれをローカルディスクにコピーして使うようにするのが良いかもしれません。この方式の方が農薬検査所サーバに対する負荷がさらに軽減されますし、proxy 設定や UNLHA32.DLL の設置もサーバだけですみ、さらアクセス権が Read Only の共有フォルダでも使えると色々メリットがあります。す。

1-1 ACFinder にデータ更新のみ実行するオプションを付けるか、データ更新専用ソフトを用意する
1-2 ファイルサーバのタスクスケジューラに登録するかスタートアップに入れて、定期的にデータベース更新チェックと必要なら更新を行う
2-1 データベース更新チェックとデータ取得を農薬検査所サイトから直接行うか、LAN 内のデータベースで行うかを選択できるようにする
2-2 LAN 内データベース利用の場合は、更新されていたらローカルディスクにコピーする
〔291〕Re:成分ごとの総使用回数
 kabe WEB  (06/06/17 21:15)
引用なし
   ＞Hidemi Oyaさん
kabe です。

>　現在「作物・病害虫」タブなどで表示される検索結果は、成分ごとの総使用回数の成分名が分かりません。たとえば、リドミルＭＺ水和剤は、名称から考えると成分１がメタラキシル、成分２がマンゼブのように思えますが、実は逆になっています。
元のExcelファイルの説明書きをみると「農薬の種類」で示される有効成分の順番というルールになっています。
リドミルＭＺだと、マンゼブ・メタラキシルなので、このルールからすると成分１がマンゼブ、成分２をメタラシルと解釈しろという意味なのでしょう。

>　標準タブの検索結果については、kihon テーブルから seibun フィールドの値を参照してきて、'有効成分名１', '総使用回数１', '有効成分名２', '総使用回数２' のように表示するようにしてもらえると助かります。
上記のルールどおりだとすると、shurui フィールドから有効成分を抜き出してくる方が簡単ですね。追加機能候補とします。
〔292〕Re:データベース共有
 kabe WEB  (06/06/17 21:28)
引用なし
   ＞Hidemi Oyaさん
kabe です。

>　あと、ふと思ったんですが、データベースを共有する場合、２重更新対策はされているでしょうか？ 先に使っている誰かが新データに更新中（更新完了はしていない状態）なら、後から使おうとした人は更新しないようになってないと無駄が出ますね。
今のところ、これは全く対策はされていません。(^^;
ただ、共有を想定すると、必須の機能ですね。

>1-1 ACFinder にデータ更新のみ実行するオプションを付けるか、データ更新専用ソフトを用意する
>1-2 ファイルサーバのタスクスケジューラに登録するかスタートアップに入れて、定期的にデータベース更新チェックと必要なら更新を行う
当面、ACFinder に起動オプションを付けて、更新チェックを行う機能を付けたいと思います。別ソフトにするかどうかは ACFinder の更新機能がある程度、完成した段階で考えたいと思います。

>2-1 データベース更新チェックとデータ取得を農薬検査所サイトから直接行うか、LAN 内のデータベースで行うかを選択できるようにする
>2-2 LAN 内データベース利用の場合は、更新されていたらローカルディスクにコピーする
修正候補としますが、検索機能をある程度完成させてからになるかと思います。
〔293〕Re:ACFinder 060610版
 kabe WEB  (06/06/17 21:54)
引用なし
   ＞Hidemi Oyaさん
kabe です。

複数作物の登録確認と、対象病害虫のクロス表機能は現在、鋭意作成中です。
ただ定型処理として、どこまで汎用性を持たせるか、なかなか難しいものがあります。
明日中にはプロトタイプを一度アップしたいと思います。
〔294〕定型処理サンプル
 Hidemi Oya WEB  (06/06/18 2:12)
引用なし
   s_kobayashi さん、kabe さん、こん＊＊は。Hidemi Oya です。

　下記 URL に、定型処理タブのサンプルをあげてみました。こんな感じの処理ができれば、以前のクロス表のように SQL だけでは処理しにくい特殊な処理以外は、全部このタブに任せてしまっても良いような感じがします。
http://macs.o-ya.net/sample/

[#284] s_kobayashi さん
>　私のイメージする用途では、定型処理だけで対応できるものが２〜３割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが７〜８割くらいあります。
　上のサンプルを見ていただければ分かるように、私がいう定型処理は SQL 複合絞り込みも含みます。っていうか、出来合いの SQL の基本フレームを使って、検索条件等を GUI で指定できるようにするのが「定型処理」の主眼です。
　ちなみに、手作業による二次加工がたとえば除外農薬の削除だとすれば、農薬の種類で除外農薬一覧を作成しておき、where 節に
shurui not in (<shurui>)
という一文を全てのテンプレートに入れておけば、手作業の必要はなくなります。現在は指定が面倒だけど、これなら簡単に自動化できるというような手作業は他にもいろいろあると思います。

[#293] kabe さん
>複数作物の登録確認と、対象病害虫のクロス表機能は現在、鋭意作成中です。
　ありがとうございます。いろいろ要望に対応していただいているところで申し訳ありませんが、このサンプルのような機能を実装していただけないでしょうか？ 作物名／病害虫名等の複数選択 GUI など、まだまだ開発すべき部分は多いですけど(^_^;)、この機能ができれば多くのユーザが実用的に使えるようになると思います。
〔295〕Re:成分ごとの総使用回数
 Hidemi Oya WEB  (06/06/18 2:32)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>元のExcelファイルの説明書きをみると「農薬の種類」で示される有効成分の順番というルールになっています。
　書き込んだ後に気が付きました(^_^;)。ただ、知ってなきゃ分からないし、農薬の種類と成分ごとの総使用回数は離れた位置に表示されるので、やはり使用回数の近くに成分名が表示された方が使いやすいですね。

>上記のルールどおりだとすると、shurui フィールドから有効成分を抜き出してくる方が簡単ですね。追加機能候補とします。
　shurui フィールドから抜き出してくるとなると、データベース作成時にフィールドを追加する形でしょうか？ kihon テーブルから持ってくる場合も、成分ごとの連番を追加しないと join やサブクエリで持って来にくいし、現在のままで表示だけ追加するのは、ちょっと面倒ですよね。
　いずれにしても、実装方法はお任せしますのでよろしくお願いします。
〔296〕Re:データベース共有
 Hidemi Oya WEB  (06/06/18 2:41)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>ただ、共有を想定すると、必須の機能ですね。
　データフォルダに ini ファイルをおくか、データベースの中にシステムステータステーブルを作って、更新中フラッグを設定するくらいですみそうですから、是非よろしくお願いします。

>当面、ACFinder に起動オプションを付けて、更新チェックを行う機能を付けたいと思います。別ソフトにするかどうかは ACFinder の更新機能がある程度、完成した段階で考えたいと思います。
　とりあえず、起動オプションだけで十分です。サーバ側で自動的に更新してしまえば、個々のユーザは更新時の待ち時間がいらなくなるので、かなり助かります。

>修正候補としますが、検索機能をある程度完成させてからになるかと思います。
　もちろんそちらが先ですね。100Mbps ならそんなに遅いわけでもありませんし。
〔297〕Re:定型処理サンプル
 Hidemi Oya WEB  (06/06/18 14:13)
引用なし
   　どうでも良い話なんですが、
#define {
　select ...
}
のようにインデントを付けても、SQL への変換時は行両端の無駄なスペースを削除するように若干変更しました。
〔298〕ACFinder 060618版
 kabe WEB  (06/06/18 21:11)
引用なし
   kabe です。

時間切れで、060618版暫定アップします。
http://acfinder.kabe.info/

今回のバージョンから、データベース更新時に作物名、農薬名を全角に変換します。
検索も全角を前提にしていますので、以前のデータベースファイルでは検索できません。めんどうですが、一度、手動で XLS->データベース更新の部分のみ実行してください。

#294の機能を取り入れてみました。
HidemiOya さんのコードをほとんど、そのまま使っています。
なお、テンプレートの内容に応じたボタンの表示、非表示は、まだ対応していません。全てのボタンが表示されるので、わかりにくいです。
使い方は
http://macs.o-ya.net/sample/
を参考にしてください。
as で指定したフォールド名は、文字列によっては表示されないか、文字化けします。

SQLエディタに簡易な入力支援機能を付けました。
SQLタブ内の左側にテーブルとフィールド名を選択する覧があります。
フォールド名のリストボックスでポップアップメニューが出ますので、適当に試してみてください。

薬剤検索部分を変更しました。
検索と閲覧的な用途にも使えます。
使い方わかりにくいかもしれませんので、インターフェース等、改善案あれば提案お願いします。
〔299〕Re:ACFinder 060618版
 kabe WEB  (06/06/18 21:25)
引用なし
   ＞HidemiOyaさん

kabe です。

>as で指定したフォールド名は、文字列によっては表示されないか、文字化けします。
これなんですが、ASの後のフォールド名を F1 F2 F3... と指定するような方法にできませんでしょうか。

max(case when sakumotsu = "なす" then jiki||"、 "||kaisu else "" end) as jp_なす,
max(case when sakumotsu = "なす（露地栽培）" then jiki||"、 "||kaisu else "" end) as jp_なす（露地栽培）,
を
max(case when sakumotsu = "なす" then jiki||"、 "||kaisu else "" end) as F1,
max(case when sakumotsu = "なす（露地栽培）" then jiki||"、 "||kaisu else "" end) as F2,

として検索します。
なす->F1
なす（露地栽培）->F2
のような対応表を持っておいて、グリッドに表示するときに置換したらよいのかなと思います。
〔300〕Re:成分ごとの総使用回数
 Hidemi Oya WEB  (06/06/19 9:17)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　kihon テーブルのデータを見ると、三共ラブサイドベフラントレボン粉剤ＤＬ／ヤシマラブサイドベフラントレボン粉剤ＤＬのように種類の順番と有効成分の順番が逆順になっていたり、ピーチガード水和剤は順番が正しいのに〔ＤＩＣ〕ピーチガード水和剤は逆順になっていたりと、kihon テーブルの順番で使うのは無理ですね。
　また、農薬検査所のシステムではちゃんと成分ごとの総使用回数の成分名として、イミノクタジンアシベル酸塩もイミノクタジン酢酸塩も「イミノクタジン」として表示されるので、有効成分名がイミノクタジンになっているのかと思ったのですが、２種類に分かれてました。

　ってことで、有効成分名を表示するときは、やはり農薬の種類の順番を使った方が良いようです。さらに、イミノクタジンのように例外処理が必要な場合が若干あるので、テーブル作成時に有効成分フィールドを追加するのが最も使い勝手が良さそうです。
　ところで、イミノクタジン以外で複数の有効成分をまとめてカウントする有効成分をご存じの方は是非お教えください。
〔301〕日本語フィールド名
 Hidemi Oya WEB  (06/06/19 9:45)
引用なし
   kabe さん、こん＊＊は。HidemiOya です。

>これなんですが、ASの後のフォールド名を F1 F2 F3... と指定するような方法にできませんでしょうか。
　[#280] の方法に従って作成して、SQL タブでも使用する可能性があるのでエンコードは SQLite に渡す直前に実行する必要があるので、今回のサンプルでは実際のエンコード／デコートルーチンを割愛しました。
　フィールド名を F1, F2 のようにしてしまうと、対応表を作成して結果表示ルーチンに渡さなければならず、複数のフィールドでこのような使い方があると、ちょっと面倒です。やはり [#280] のような方法が楽だと思います。

　で、SQLite の方にもしかするとユーザ関数を組み込めるかもしれないので、将来的にこの方法の採用も検討するとすると、
(1) SQL 文側では「hex("日本語文字列")」と書いておくと、この部分を「hex十六進文字列」にエンコードする
(2) エラー表示／フィールド名表示の際には「hex十六進文字列」を「日本語文字列」にデコードする
という方式を採用したいと思います。これなら、将来的に (1) の部分は SQLite に組み込んだとしても、既存の SQL を書き換える必要がありません。
　また、16 進文字列にエンコードすることにより、SQLite が大文字／小文字変換をしてもデコードに問題が発生することもありませんし、デコードする際に hex([0-9a-f]+) でエンコードされた文字列を切り出せるので便利です。
　一応、この方式でエンコード／デコードルーチンを作成しますので、ACFinder への組み込みをお願いします。
〔302〕作物・病害虫タブ
 Hidemi Oya WEB  (06/06/19 10:10)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

毎度素早いバージョンアップご苦労様です。

>今回のバージョンから、データベース更新時に作物名、農薬名を全角に変換します。
　やっぱり、全角統一が良いですね。

　ところで、作物名選択について以前から書こうと思ってて書き忘れてたんですが、現在のようなツリー形式のダイアログボックスで複数選択可能にならないでしょうか？

　たとえば、「なす」に登録のある農薬を検索する場合に、「なす%」ではなく、「なす」と「なす（露地栽培）」だけで検索したいとか、あるいはマイナークロップや花などでは、上位分類も含めて一括検索したいということはよくあります。
　このため、ダイアログボックスで複数選択可能にするとともに、テキストボックス内に「"なす", "なす（露地栽培）"」のように書かれていれば、「(sakumotu like "なす" or sakumotsu like "なす（露地野菜）")」と展開するような機能を追加していただけると、非常に使いやすくなります。

　あと、ツールバーの通称モードボタンですが、薬剤タブでも使用するのかと思っていたら、今回の形だと使いそうにないので、作物・病害虫タブ内に移した方が良いかもしれませんね。

　なお、「にがうり」の件は修正されていることを確認しました。
〔303〕薬剤タブ
 Hidemi Oya WEB  (06/06/19 10:41)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>薬剤検索部分を変更しました。
>検索と閲覧的な用途にも使えます。
　いや〜、これはなかなか良いです。以前のバージョンだといまいち使い道が不明でしたが、これは使い出があります。
　左上隅のコンボボックスは何のために用意されてるのでしょう？

>使い方わかりにくいかもしれませんので、インターフェース等、改善案あれば提案お願いします。
　薬剤候補なんですが、今の形なら、種類を左側において先に種類を選択してからキーワード入力の方が、エンターキー一発で検索できるので楽です。
　が、できれば、種類は選択せずにキーワード入力だけで、自動的に
shurui LIKE '%キーワード%' OR shurui LIKE '%きーわーど%' OR meisho LIKE '%キーワード%' OR meisho LIKE '%きーわーど%'
と展開してくれた方が便利ですね。
　条件として有効成分が必要かどうかは微妙です。「２，４−ＰＡ」なんかは後ろに「ジメチルアミン」とか「エチル」とかいろいろ付きますが、それまで必要なことがどの程度あるか…。細かな成分名まで付けて検索しなくても、種類「２，４−ＰＡ」で検索後に確認すれば良さそうですし。
〔304〕定型処理タブ
 Hidemi Oya WEB  (06/06/19 11:12)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>#294の機能を取り入れてみました。
　素早い対応ありがとうございます。こんなに早く組み込まれるとは思ってもみませんでした。

　作物名ボタンですが、現在のままだと選択した作物だけにテキストボックスが書き換えられてしまうので、複数作物登録農薬一覧表のような用途では非常に不便です。このままの方式で行くなら、ダイアログボックス内に「追加」ボタンを追加して、テキストボックスにどんどん作物を追加できるようにする必要があります。
　できれば、２タブにして [#302] で書いたような選択方法と両方使えるとさらに良いですね。特にいろいろな作物を一括して選択する場合は、全一覧から選択できた方が便利です。ひとつ作れば、作物・病害虫タブでも同じものが使えますし…。

　病害虫ボタンは使いやすいです。作物検索語を作物名テキストボックスから自動的に持ってきてくれたり、作物検索語を書き換えてエンターキーを入力すると再検索できたりするともっと良いですが…。現在は、入力ミスで再検索したい場合はダイアログボックスをいったん閉じなければならないので、できれば再検索機能は欲しいですね。

　あと、私のサンプルが横着してたのが悪いんですが(^_^;)、テンプレート選択した後は、アクティブページを処理内容タブにしてくれると使いやすいです。
　それと、サンプルでは設定値にダブルクォートが付いていてもいなくても問題ないよというところを見てもらいたくてダブルクォート付きも添付しましたが、正式リリースの際はダブルクォート無しに統一した方が良いですね。
〔305〕SQLタブ
 Hidemi Oya WEB  (06/06/19 11:28)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>SQLエディタに簡易な入力支援機能を付けました。
　これはなかなか凄いですね。予約語の色分けまで付いているとは…。テンプレートで多用している IN 演算子が予約語として認識されていないので、追加をお願いします。

>SQLタブ内の左側にテーブルとフィールド名を選択する覧があります。
>フォールド名のリストボックスでポップアップメニューが出ますので、適当に試してみてください。
　今のところ、骨格としてはこれくらいあれば十分ですね。これで、作物名／病害虫名などを GUI で設定できるようになれば、もう何もいらないかも…。

　SQL 文と結果は、現行２ペイン制と定型処理のような２タブ制とどちらが良いか微妙ですね。短い SQL 文だと２ペインの方が良いし、長い SQL 文だと２タブの方が良さそうです。
〔306〕Re:成分ごとの総使用回数
 s_kobayashi  (06/06/19 21:08)
引用なし
   ＞Hidemi Oyaさん

>　ところで、イミノクタジン以外で複数の有効成分をまとめてカウントする有効成分をご存じの方は是非お教えください。

　ぱっと思いつくのはラウンドアップ系でしょうか。他は詳しく当たってみないと自信がありません。
〔307〕ACFinder 060619版
 kabe WEB  (06/06/19 21:45)
引用なし
   kabe です。

060619版です・
http://acfinder.kabe.info/

CSV保存、Excel出力、コピー、全てコピーなどの機能が、タブを切り替えた場合も作物、病害虫タブ内のグリッドだけを対象に動作していました。
その他、グリッドのフォント設定などを変更しても、作物、病害虫タブ以外は反映されませんでした。(^^;
気付いた部分は修正しましたが、まだ修正もれがあるかもしれません。

その他、いくつか修正してあります。
#303
>　薬剤候補なんですが、今の形なら、種類を左側において先に種類を選択してからキーワード入力の方が、エンターキー一発で検索できるので楽です。
種類を左側におきました。

#304
定型処理の作物名選択ダイアログに「追加」ボタンを追加しました。
>作物検索語を書き換えてエンターキーを入力すると再検索できたりするともっと良いですが
にしてみました。

#305
>IN 演算子が予約語として認識されていないので、追加をお願いします。
修正しました。
〔309〕Re:作物・病害虫タブ
 kabe WEB  (06/06/19 22:09)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　このため、ダイアログボックスで複数選択可能にするとともに、テキストボックス内に「"なす", "なす（露地栽培）"」のように書かれていれば、「(sakumotu like "なす" or sakumotsu like "なす（露地野菜）")」と展開するような機能を追加していただけると、非常に使いやすくなります。
定型処理タブの作物選択も含めて同じ選択ダイアログを使うようにしたいと思います。
今回作成していただいた定型処理ルーチンを、作物・病害虫タブにも応用して、複数作物検索を実現できないかなと思ってますが、まだ機能がよく理解できていません。(^^;
これについてはなんとか最優先で取り組みたいと思います。
〔310〕Re:薬剤タブ
 kabe WEB  (06/06/19 22:17)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　左上隅のコンボボックスは何のために用意されてるのでしょう？
用途を選択すると該当する用途の通称薬剤が全て表示されるだけです。
検索というよりは、農薬便覧の閲覧みたいな用途を想定していました。

>　が、できれば、種類は選択せずにキーワード入力だけで、自動的に
>shurui LIKE '%キーワード%' OR shurui LIKE '%きーわーど%' OR meisho LIKE '%キーワード%' OR meisho LIKE '%きーわーど%'と展開してくれた方が便利ですね。
この方法に変更したいと思います。
〔311〕Re:SQLタブ
 kabe WEB  (06/06/19 22:25)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>>SQLエディタに簡易な入力支援機能を付けました。
>　これはなかなか凄いですね。予約語の色分けまで付いているとは…。
簡単にキーワードが指定できるようだったので AFEdit コンポーネントを使っています。
ところで拡張メモコンポーネントなんですが D6 + WindowsXP では使えるのでしょうか。
〔312〕Re:成分ごとの総使用回数
 Hidemi Oya WEB  (06/06/19 22:25)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　ぱっと思いつくのはラウンドアップ系でしょうか。他は詳しく当たってみないと自信がありません。
　ありがとうございます。確かに、グリホサートもそうですね。２，４−ＰＡと同様に、有効成分は「グリホサート○○」でも農薬の種類は「グリホサート」にまとめてくれれば何の問題もないんですけどね。あるいは、同一有効成分としてカウントする有効成分のリストを提供してくれるかね。
　現状の Excel データでは、使用基準省令でいう「含有する有効成分の『種類』ごとの総使用回数」を遵守するのは難しいですね。暗に「含有する有効成分ごとの総使用回数」を守れば良いと言ってくれてるのでしょうか？（誤解する人がいるといけないので、これは皮肉ですと補足しておきましょう^^;）
〔313〕Re:日本語フィールド名
 Hidemi Oya WEB  (06/06/19 23:03)
引用なし
   kabe さん、こん＊＊は。HidemiOya です。

>(1) SQL 文側では「hex("日本語文字列")」と書いておくと、この部分を「hex十六進文字列」にエンコードする
>(2) エラー表示／フィールド名表示の際には「hex十六進文字列」を「日本語文字列」にデコードする
　これに基づいたエンコード／デコード関数を作成しましたので、組み込みをお願いします。SQLite の本家サイトを探したんですが、フィールド名の最大長が分かりませんでした。長くなりすぎないように ShiftJIS の文字列をエンコードしていますが、もしかしたら文字数制限に引っかかるかも…。

　エンコード／デコードルーチンで、AnsiToUtf8/Utf8ToAnsi も行ってしまいます。また、エンコード時に「hex("日本語文字列")」、デコード時に「hex十六進文字列」を含まない文字列はほとんどオーバーヘッドなくオリジナル文字列をそのまま返します。ってことで、SQLite に SQL 文を渡す際には現在の AnsiToUtf8 関数の代わりに EncodeHex を、エラー表示やフィールド名表示の際は Utf8ToAnsi 関数の代わりに DecodeHex を常に使ってもらって問題ありません。
　なお、テンプレートの「jp_[field]」の部分は、「hex("[field]")」に変更する必要があります。

function EncodeHex(src: string): string;
var
　t, h: string;
　p: PChar;
begin
　RegExprModifierI := true;
　RegExprModifierS := true;
　Result := ReplaceRegExpr('hex\(\s+("[^"]*")\s+\)', AnsiToUtf8(src), 'hex($1)', true);
　while ExecRegExpr('hex\("[^"]+"\)', Result) do begin
　　t := ReplaceRegExpr('.*?hex\("([^"]+)"\).*', Result, '$1', true);
　　p := PChar(Utf8ToAnsi(t));
　　h := '';
　　while p^ <> #0 do begin
　　　h := h + IntToHex(Ord(p^), 2);
　　　Inc(p);
　　end;
　　Result := ReplaceRegExpr('hex\("' + t + '"\)', Result, 'hex' + h, false);
　end;
end;

function DecodeHex(src: string): string;
type
　THex2 = array[0..1] of char;
　PHex2 = ^THex2;
var
　t, s: string;
　p: PChar;
begin
　RegExprModifierI := true;
　RegExprModifierS := true;
//　Result := src;
　Result := Utf8ToAnsi(src);
　while ExecRegExpr('hex[0-9a-f]+', Result) do begin
　　t := ReplaceRegExpr('.*?hex([0-9a-f]+).*', Result, '$1', true);
　　p := PChar(t);
　　s := '';
　　while p^ <> #0 do begin
　　　s := s + Chr(StrToInt('$' + PHex2(p)^));
　　　Inc(p, 2);
　　end;
//　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f])', Result, AnsiToUtf8(s) + '$1', true);
　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f])', Result, s + '$1', true);
　end;
//　Result := Utf8ToAnsi(Result);
end;
〔314〕Re:ACFinder 060619版
 Hidemi Oya WEB  (06/06/20 0:26)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>060619版です・
　だ〜、早い早い！ [#313] の日本語エンコード／デコード関数が間に合いませんでした(^_^;)。

>種類を左側におきました。
　ありがとうございます。やっぱりこちらの方が使いやすいです。
　一番上は、用途だったんですね。現在のパネル構成では、用途と名称が独立していることがやや分かりづらい感じがします。用途タブと名称タブに分けた方が分かりやすいかなあ…。でも、タブ切替しなくても良いので、今の方が使い勝手は良いような気も…。う〜ん、微妙ですね。[#310] のようになるなら、用途コンボボックスと名称テキストボックスの２つだけなので、やっぱりこのままかなあ。

>定型処理の作物名選択ダイアログに「追加」ボタンを追加しました。
　凄く使いやすくなりました。[#309] のように統一してもらえると完璧です。

>>作物検索語を書き換えてエンターキーを入力すると再検索できたりするともっと良いですが
>にしてみました。
　これも非常に良くなりましたね〜。再検索で検索結果がどんどん追加されていくのは、私の想定以上でした。これで、既設定の作物名がある場合は、それを自動的に持ってきてくれると、もう何も言うことはありません。

>>IN 演算子が予約語として認識されていないので、追加をお願いします。
>修正しました。
　ありがとうございます。

　あと、[#297] の変更は、私の方の Main.pas では、TfrmMain.TemplateToQuery 関数の
　for i := 0 to FTemplate.Count - 1 do begin
　　line := FTemplate.Strings[i];
を
　for i := 0 to FTemplate.Count - 1 do begin
　　line := Trim(FTemplate.Strings[i]);
にしただけなので、対応をお願いします。

　それと、TRegExpr は BSD ライセンスと似ています。「appreciate」の解釈によって強さがかなり変わってしまいますが、ドキュメントかアバウトボックスに TRegExpr の著作権表示をしておいた良さそうです。アバウトボックスなら、原文通りよりは、「Created using TRegExpr Copyright(c) 1999-2004 by Andrey V. Sorokin, http://regexpstudio.com/」ってな感じでしょうかね。他に使用しているコンポーネントがあれば、ドキュメントに使用コンポーネント一覧とその著作権を表示する方法の方が良さそうです。
> If You use this software in any kind of product, it would be appreciated that there in a information box, or in the documentation would be an acknowledgement like "Partial Copyright (c) 1999-2004 by Andrey V. Sorokin, anso@mail.ru, http://RegExpStudio.com"
〔315〕Re:作物・病害虫タブ
 Hidemi Oya WEB  (06/06/20 0:45)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>今回作成していただいた定型処理ルーチンを、作物・病害虫タブにも応用して、複数作物検索を実現できないかなと思ってますが、まだ機能がよく理解できていません。(^^;
　エレメント型メタフィールドを展開する時は、テキストボックスの値を TStringList に CommaText プロパティで放り込んで、TStringList の１行(各要素)ごとに展開しています。
　TfrmMain.TemplateToQuery 関数の下記の部分です。メタフィールドを書き換えるわけじゃないので、for ループの中は単純に
s := s + 'sakumotsu like ("' + list.Strings[j] + '") or ';
でつないでいって、最後に
Delete(s, Length(s) - 3, 4);
s := '(' + s + ')';
としてやれば OK だと思いますが…。

list.CommaText := edtTplSakumotsu.Text;
for j := 0 to list.Count - 1 do dest.Add(ReplaceRegExpr('\[' + CField[f] + '\]', line, list.Strings[j], false));
〔316〕Re:SQLタブ
 Hidemi Oya WEB  (06/06/20 0:53)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>簡単にキーワードが指定できるようだったので AFEdit コンポーネントを使っています。
　特定文字列で始まる行全体を色分けできるような機能があれば、定型処理の説明文の章タイトルを色分けしてくれるとうれしいです。

>ところで拡張メモコンポーネントなんですが D6 + WindowsXP では使えるのでしょうか。
　ユーザの中には、その組み合わせで使っている人もいるようです。ただし、禁則処理などの Asian Language Version Only な機能は一切使えません。既に作者が開発を止めている(^_^;)コンポーネントなので、あえて使う必要はないかと…。
〔317〕Re:ACFinder 060619版
 Hidemi Oya WEB  (06/06/20 0:59)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　ACFinder のサイトではドキュメントも整備されつつあり、いよいよ正式リリースも間近でしょうか…。
　このツリーもかなり巨大になって見通しが悪くなってきたので、暫定版があと２〜３回で正式リリースになる時は正式リリース時に、まだしばらく暫定版が続くようなら次のバージョンから新スレッドにしてください。
〔318〕Re:作物・病害虫タブ
 Hidemi Oya WEB  (06/06/20 1:19)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　次のような方法の方が簡単かな…。
(1) テキストボックス直接入力は、今まで通り like 演算子とワイルドカードを使った検索
(2) 作物名選択ダイアログボックスを使った時は、ダイアログボックス内に複数選択作物表示テキストボックスを作っておいて、その値をそのまま in 演算子に渡して検索

　(2) はリスト型メタフィールドの展開と同じです。ダイアログボックス内の作物リストを sakumotsu_list とすると、単純に
s := 'sakumotsu in (' + QuotedCSV(sakumotsu_list) + ')';
でお終いです。
　定型処理タブでは、sakumotsu_list を edtTplSakumotsu.Text に代入してもらえばすみますし。
〔319〕Re:日本語フィールド名
 Hidemi Oya WEB  (06/06/20 1:34)
引用なし
   kabe さん、こん＊＊は。HidemiOya です。

　EncodeHex 関数を書いている時に確認したんですが、UTF-8 では 0x00〜0x7F は使われないような感じです。したがって、[#280] の
>　UTF-8 文字列を URL エンコードすると、%xx の中に英小文字が散見されるので、恐らく sqlite3.dll はフィールド名を大文字に変換しちゃってるんでしょうね。
は間違いですね(^_^;)。英子文字が散見されたのは ShiftJIS ですね。

　では何故フィールドアリアスに UTF-8 が使えないのかというと、SQLite 側で大文字／小文字変換する際のバグですかねえ？
〔321〕Re:日本語フィールド名
 kabe WEB  (06/06/20 6:35)
引用なし
   ＞Hidemi Oyaさん

kabe です。

早速ありがとうございます。
ちょっと今やってみたのですが、DecodeHex の方がうまくいきません。
DecodeHex を使わない場合
hex("なす")　を SQLite に渡すと
HEX82C882B7
とフィールド名が表示されます。
(SQLite が大文字に変換しているようです)
DecodeHex を使うと、無限ループになっているのか、応答なし状態になってしまいます。
MessageDlg(DecodeHex('HEX82C882B7'),mtInformation,[mbOk],0);
でも同様の症状なので、DecodeHex 関数の問題でしょうか。？
ソースはそのままコピペしただけなんですが、どこかチェックポイントありますか。
〔322〕Re:日本語フィールド名
 Hidemi Oya WEB  (06/06/20 9:16)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>ちょっと今やってみたのですが、DecodeHex の方がうまくいきません。
　あれ〜？ D7 では全く問題なく動作してたんですが…。複数作物登録一覧表とその設定例でできた SQL 文を全部エンコード／デコードできたので、「なす」も動作確認済みです。

>DecodeHex を使わない場合
>hex("なす")　を SQLite に渡すと
>HEX82C882B7
>とフィールド名が表示されます。
　EncodeHex で渡した SQL 文は、SQLite で問題なく動作するわけですね？

>(SQLite が大文字に変換しているようです)
　予測は当たってましたね。UTF-8 なら影響しないはずなんですけどね。
　ちなみに、hex が HEX になっても問題なく Decode できることを確認しています。

>MessageDlg(DecodeHex('HEX82C882B7'),mtInformation,[mbOk],0);
>でも同様の症状なので、DecodeHex 関数の問題でしょうか。？
　ですね。

>ソースはそのままコピペしただけなんですが、どこかチェックポイントありますか。
　D6 と D7 の仕様の違いだとすれば、怪しいのは
　　p := PChar(t);
の部分(D3 でも大丈夫だったような気はするけど…)ですかねえ？ とりあえず、
　　p := @t[1];
だとどうでしょう？
　それと、現状では最初に SHiftJIS に戻してからデコードしてますが、UTF-8 のままデコードして最後に ShiftJIS に戻す方法を残してあります。// でコメントアウトした行を生かして、その下の行をコメントアウトしてください。
　とりあえず、今思いつく範囲ではこんなところです。
〔323〕Re:日本語フィールド名
 Hidemi Oya WEB  (06/06/20 12:09)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>　D6 と D7 の仕様の違いだとすれば、怪しいのは
>　　p := PChar(t);
>の部分(D3 でも大丈夫だったような気はするけど…)ですかねえ？
　EncodeHex で
　　P := PChar(Utf8ToAnsi(t));
が OK ですから、こいつは問題ないですね。
　で、ソースを見直してみたら、フィールド名の書き戻しができないことが判明しました(^_^;)。エラーメッセージのデコードは問題ないはずです。DecodeHex の end; から上に５行目の
//　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f])', Result, AnsiToUtf8(s) + '$1', true);
　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f])', Result, s + '$1', true);
を
//　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f]|$)', Result, AnsiToUtf8(s) + '$1', true);
　　Result := ReplaceRegExpr('hex' + t + '([^0-9a-f]|$)', Result, s + '$1', true);
に書き換えてください。

　SQLite3 の基本エンコードは Unicode のようなので、データベースの内容も SQL のやりとりも全て UTF-16 にしてやれば、問題なく日本語が通るのかもしれません。SQLite 3.3.6 の DLL が日本語データベース名を通してくれないのも、Unicode でなく ShiftJIS だからかも…。
　UTF-8 のフィールド名が正常に使えないのは、UTF-8 を無理矢理 UTF-16 に変換しているせいだと考えれば、理解できるような気がします。
〔324〕Re:ACFinder 060619版
 Hidemi Oya WEB  (06/06/20 20:02)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　定型処理タブなんですが、実行後にテンプレートを読み込むと、処理内容タブがアクティブになるものの、タブ内は検索結果のストリンググリッドのままです。ページコントロールではなく、タブコントロールを使っているんでしょうか？
　それと、実行後に作物や病害虫を書き換えて再度「実行」ボタンをクリックしても、新たな条件で再検索されず、前回実行結果が表示されます。
〔325〕Re:ACFinder 060619版
 kabe WEB  (06/06/20 21:59)
引用なし
   ＞Hidemi Oyaさん
kabe です。

>　定型処理タブなんですが、実行後にテンプレートを読み込むと、処理内容タブがアクティブになるものの、タブ内は検索結果のストリンググリッドのままです。ページコントロールではなく、タブコントロールを使っているんでしょうか？
そうです。
Visible を切り替えるのを忘れてました。

>　それと、実行後に作物や病害虫を書き換えて再度「実行」ボタンをクリックしても、新たな条件で再検索されず、前回実行結果が表示されます。
リスト型は変更されているようですが、エレメント型がクリアされていないようです。
TemplateToQuery　中のメタフィールドを展開する前に
FTemplate.Text := ReplaceRegExpr('.*#template\s*\{\s*(.*?)\s*?\}.*', memTplSource.Text, '$1', true);
を入れるとクリアされるみたいですが、こんな方法で大丈夫でしょうか。
〔326〕Re:ACFinder 060619版
 Hidemi Oya WEB  (06/06/20 22:51)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>リスト型は変更されているようですが、エレメント型がクリアされていないようです。
　ありゃ〜、私のせいだったのね(^_^;)。エレメント型は更新されるけど、リスト型が更新されませんね。すみません、FTplQuery を書き換えるべきなのに、書き換えちゃいけない FTemplate.Text を書き換えちゃってました。
　TemplateToQuery を下記のように、修正してください(う〜む、どうしてもインデントが全角スペースになってしまう)。エレメント型を先に展開して、その後リスト型を展開、リスト型展開ルーチンの FTemplate.Text を全て FTplQuery に置換です。

　// エレメント型メタフィールド展開
　dest := TStringList.Create;
　list := TStringList.Create;
　for i := 0 to FTemplate.Count - 1 do begin
　　line := Trim(FTemplate.Strings[i]);
　　if not ExistElement([sakumotsu..shurui], line) then
　　　dest.Add(line)
　　else
　　　for f := sakumotsu to shurui do begin
　　　　if not ExistElement([f], line) then continue;
　　　　case f of
　　　　　sakumotsu: list.CommaText := edtTplSakumotsu.Text;
　　　　　byochu: list.CommaText := edtTplByochu.Text;
　　　　　yoto: list.CommaText := edtTplYoto.Text;
　　　　　shurui: list.CommaText := edtTplShurui.Text;
　　　　end;
　　　　for j := 0 to list.Count - 1 do dest.Add(ReplaceRegExpr('\[' + CField[f] + '\]', line, list.Strings[j], false));
　　　　break;
　　　end;
　end;
　FTplQuery := ReplaceRegExpr(',(\s+from)', dest.Text, '$1', true);
　list.Free;
　dest.Free;
　// リスト型メタフィールド展開
　if FTplSakumotsu then begin
　　FTplQuery := ExpandList(sakumotsu, FTplQuery, edtTplSakumotsu.Text);
　end;
　if FTplByochu then begin
　　FTplQuery := ExpandList(byochu, FTplQuery, edtTplByochu.Text);
　end;
　if FTplYoto then begin
　　FTplQuery := ExpandList(yoto, FTplQuery, edtTplYoto.Text);
　end;
　if FTplShurui then begin
　　FTplQuery := ExpandList(shurui, FTplQuery, edtTplShurui.Text);
　end;
〔329〕Re:ACFinder 060619版
 kabe WEB  (06/06/20 23:26)
引用なし
   ＞Hidemi Oyaさん

kabe です。
ありがとうございました。
修正しました。

>>リスト型は変更されているようですが、エレメント型がクリアされていないようです。
>　ありゃ〜、私のせいだったのね(^_^;)。エレメント型は更新されるけど、リスト型が更新されませんね。
あれ、逆でしたか。
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.