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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
65 / 114 ツリー <前へ | 次へ>

〔463〕ACFinder 060828版 kabe (06/08/28 23:07)
〔464〕Re:ACFinder 060828版 Hidemi Oya (06/08/29 17:14)
〔465〕ACFinder 060830版 kabe (06/08/30 1:57)
〔466〕Re:ACFinder 060830版 Hidemi Oya (06/08/30 10:57)
〔467〕要望ほか Hidemi Oya (06/08/30 12:52)
〔471〕Re:要望ほか Hidemi Oya (06/08/31 16:58)
〔468〕通称の代表適用の変更機能 Hidemi Oya (06/08/30 23:30)
〔470〕Re:通称の代表適用の変更機能 Hidemi Oya (06/08/31 16:42)
〔472〕Re:通称の代表適用の変更機能 kabe (06/08/31 20:05)
〔473〕Re:通称の代表適用の変更機能 Hidemi Oya (06/08/31 22:40)
〔476〕解決:定型処理での対策 Hidemi Oya (06/09/01 9:09)
〔478〕Re:解決:定型処理での対策 Hidemi Oya (06/09/02 0:08)
〔469〕データベース自動更新機能 Hidemi Oya (06/08/31 0:14)

〔463〕ACFinder 060828版
 kabe WEB  (06/08/28 23:07)

引用なし
   kabeです。

060828版です。
http://acfinder.kabe.info/
修正内容はACFinderサイトを参照してください。

プログラム内部で使用している SQLite用の Delphi ライブラリを Hidemi Oya さん作成のものに変更しました。
ライブラリは追って Hidemi Oya さんのサイトで公開される(?)ものと思いますが、Delphi で SQLiteを扱うにはとても便利です。
ACFinder がアプリケーション第1号かな。

なお今回のバージョンですが、起動時のデータ更新チェック機能にバグがあります。
今まで、私の手抜きで、「2006年8月16日登録反映」などの登録更新情報部分のみ Shift-JIS でデータベースに保存していました。
060828版では全てのデータを UTF16で扱いますが、Shift-JISのデータを読むと文字化けするため、新しいデータがあると勘違いしてデータ更新を促します。
数日中に8/28登録反映データが更新されると思いますので、その際にデータ更新を行うと直りますが、気になる場合は、手動で XLS->データベース更新を1回実行してください。

〔464〕Re:ACFinder 060828版
 Hidemi Oya WEB  (06/08/29 17:14)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

 060828 版ですが、
>プログラム内部で使用している SQLite用の Delphi ライブラリを Hidemi Oya さん作成のものに変更しました。
のバグのせいで成分2が表示されなかったりなどの不具合があります。
 昨夜(というか今朝というか)送ったバグフィックスバージョンは、この不具合は解消されていますが、集約関数が型未定義のためエンコーディング変換されずに表示されてします。集約関数の結果を正常に取得できるようにしたら、今度は concat 関数が妙な挙動をするようになってしまいました。
 てなわけで、このバージョンはしばらくお待ちください。なお、acfindef.kabe.info に関しては、勝手にダウンロードできなくしちゃいました。

〔465〕ACFinder 060830版
 kabe WEB  (06/08/30 1:57)

引用なし
   kabe です。

修正版をアップしました。
http://acfinder.kabe.info/

〔466〕Re:ACFinder 060830版
 Hidemi Oya WEB  (06/08/30 10:57)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

>修正版をアップしました。
 バグフィックス版 SQLite ライブラリを送ったのが深夜だったのに、素早い対応ありがとうございました。ライブラリの方は、あといくつかプリプロセッサ関数を追加する予定ですので、またよろしくお願いします。

>今度は concat 関数が妙な挙動をするようになってしまいました。
 これの原因解明に何時間もかかってしまったんですが、実はライブラリ側は全く問題なく、単純にテストプログラムの SQL が Memo コンポーネントで勝手に改行されてしまっていたのが原因でした。まったく、しょうもないことで躓いたものです。

〔467〕要望ほか
 Hidemi Oya WEB  (06/08/30 12:52)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

 060820 版で、当初からの TODO リストもほぼチェック済みになりました。大きな改変が必要なもので残っているのは、任意行/列の削除機能くらいでしょうか…。
 こちらは、ゆっくり対応していただくとして、ちょっと細かな気づいた点を。

 MACS for ACIS でもまだ修正していませんが、抜け切れていない屋号に「トクソー」がありました。
 SQL タブで、http://www.sqlite.org/lang_expr.html にある標準のスカラー関数、集約関数で色分けされないものがあります。スカラー関数などは ACFinder で全く使わないようなものもあるので全て色分けする必要はありませんが、集約関数に関しては色分けしてもらえるとありがたいです。データから数値だけを抜き出す関数を追加すれば、使用回数等で SUM とかも使えるようになりますから。ついでに、http://www.sqlite.org/pragma.html にあるプラグマの内、index_info, index_list あたりも色分けされた方が良いかなという感じはします。

 薬剤タブで成分名等による Google 検索をできるように要望しようと思っていたら、これは今バージョンから対応してましたね。

〔468〕通称の代表適用の変更機能
 Hidemi Oya WEB  (06/08/30 23:30)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

 7/19 の登録変更で、いくつかの作物で TPN の総使用回数が拡大されています。きゅうりでは、散布で4回だったのが8回と倍増しています。
 ところが、ダコニール1000では、無印・クミアイ・武田・STと4剤ある中で、STのみが本剤の総使用回数が4回のままになっていて(JPP-NET でも同様です)、通称モードではSTダコニール1000の適用が表示されます。このため、通称モードばかり使用していると、登録変更されたことに気づきにくいです。
 この例では、使用回数が少ない方が表示されているので大きな問題にはなりませんが、逆に総使用回数の削減や希釈倍数の低濃度化への変更があって、多い方や濃い方が通称の代表適用として表示されると、我々の用途ではちょっと厳しいです。

 現在は、登録番号が若いものが代表適用として使用されるようですが、これを逆に古いものにするか、屋号なし農薬名があるものは屋号なしを代表適用とした方が原体メーカーの可能性が高く、登録変更もきちんと変更される確率が高いのではないかと思います。
 できれば、こういった事例に気がついた段階で、ユーザが指定した剤で通称の代表適用を書き換えるような機能があると良いですね。さらに、指定した剤を ACFinder のサイトに集積できるような機能が付けて、他のユーザもそれを利用できるようになるともっと便利になりそうです。

P.S.
 しかし、同じ住友武田で、武田ダコニール1000と武田ダコニール粉剤・STダコニール粉剤は変更されてて、STダコニール1000だけ変更されてないってのはどういうことなんでしょうね? 粉剤の方が昔のままってのなら、ADI 絡みかなとも思えますが…。
 JPP-NET を見ても同様で、しかもSTダコニール1000のみ最終登録変更日が 8/16 と他の剤よりもあとなので、データのバグでもなさそうです。

〔469〕データベース自動更新機能
 Hidemi Oya WEB  (06/08/31 0:14)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

 これまでも何度かありましたが、060830 版でもデータベース構成が変わったために、データベース部分のみの更新が必要となりました。これをいちいちユーザに指示してやってもらうのもなかなか難しいですし、ファイルサーバにあるデータベースを使う場合も管理者が手動更新しなければなりません。
 まあ、そう頻繁に実施しなければならないものではありませんが、自動化できるなら自動化してもらった方が便利です。

 データベースに、このデータベースを作成した ACFinder のバージョンを保存しておけば、データベースの更新が必要かどうかは判断できるので、データベースのみの更新も自動化することが可能です。次にデータベース構成が変わる時にでも、データベース自動更新機能を追加してもらえるとうれしいです。

 さらに、8/16 登録更新のような ACFinder 本体のアップデートが必要な際には、これも自動的にアップデートしてくれる機能があると申し分ないですね。今のままでは無理ですが、データアップデータと検索部分を分離して別 exe にすれば、検索部分に制御が移った段階でデータアップデータを更新するという手法が使えそうです。
 早急にということではないですが、将来の TODO リストに加えてもらえるとうれしいなあ…。

〔470〕Re:通称の代表適用の変更機能
 Hidemi Oya WEB  (06/08/31 16:42)

引用なし
   自己レスです。

> 現在は、登録番号が若いものが代表適用として使用されるようですが、これを逆に古いものにするか、
 vTsushoTekiyo を登録番号の逆順に並び替えたらできるかなと思って、私のチェックシステム上で vTsushoTekiyo の最後に「ORDER BY bango DESC」を追加してみたら、登録番号の古いものが選択されるようにはなりました。検索速度がやや遅くなるという副作用がありますけど。

>屋号なし農薬名があるものは屋号なしを代表適用
 こちらについても、上記と同様に vTsushoTekiyo の最後に「ORDER BY LENGTH(meisho) DESC」を追加するといけそうです。ただし、これはかなり検索に時間がかかります。

> できれば、こういった事例に気がついた段階で、ユーザが指定した剤で通称の代表適用を書き換えるような機能があると良いですね。
 考えてみたら、vTsushoTekiyo は実テーブルではなくビューなので、これは無理ですね(^_^;)。UTF-16 対応によっていくらかデータベースサイズが削減できたので、vTsushoTekiyo をビューではなく実テーブルにするという手もアリかなという気はしますが…。

 話は変わりますが、現在 vTekiyo, vTsushoTekiyo は tekiyo のビューとして作られているので、ビューのビューになります。vTekiyo, vTsushoTekiyo を使うと tekiyo に比べて圧倒的に検索が遅くなるのは、これが原因のようです。vTsushoTekiyo を下記のように作ると、検索速度が劇的に改善します。最後に「ORDER BY m_tekiyo.bango DESC」を追加しても、従来の vTsushoTekiyo を使った場合より速いくらいです。
 ビューのビューはサブクエリと同じになるせいですかねえ? あるいは、ビューのビューではインデックスが使えないとか? 詳細は不明ですが、いずれにしてもネストしたビューは可能な限り避けた方が良さそうです。

CREATE VIEW vTsushoTekiyo AS
SELECT
 sakumotsu, byochu, mokuteki, shurui, tsusho,
 jiki, baisu, ekiryo, hoho, basho, jikan, ondo, dojo, chitai,
 tekiyaku, kongo, kaisu,
 seibun1, kaisu1, seibun2, kaisu2, seibun3, kaisu3,
 seibun4, kaisu4, seibun5, kaisu5, yoto, zaikei
FROM m_tekiyo
LEFT JOIN m_kihon ON m_tekiyo.bango = m_kihon.bango
--ORDER BY m_tekiyo.bango DESC
--ORDER BY LENGTH(meisho) DESC

〔471〕Re:要望ほか
 Hidemi Oya WEB  (06/08/31 16:58)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

 SQL タブのフィールドペインの右クリックでフィールドがノーチェックまたは全チェックの場合は「select * from」が選択できるように要望するのを忘れてたなと思って確認したら、いつの間にか対応してました。チェンジログに出てこない細かな修正が結構されてたんですね。

 SQL タブのエディタの右ボタンクリックで、「切り取り」が単なる削除になっていて、クリップボードに切り取ったテキストが入りません。現行「切り取り」は「削除」にして、クリップボードに入る一般的な「切り取り」を追加して欲しいです。
 あと、エディタの右ボタンメニューに、「全選択」と「全消去」があると便利かな。

〔472〕Re:通称の代表適用の変更機能
 kabe WEB  (06/08/31 20:05)

引用なし
   >Hidemi Oyaさん

kabe です。

>通称モードではSTダコニール1000の適用が表示されます。このため、通称モードばかり使用していると、登録変更されたことに気づきにくいです。
というか、全ての適用内容が同じだと、重複を省いて表示しますが、ひとつでも異なると、同一の農薬通称で異なる適用内容が表示されます。
例えば作物タブで「きゅうり」「褐斑病」を検索した場合、農薬の種類か農薬通称でソートするとわかりますが、TPN水和剤、ダコニール1000の表示が2件出てきます。どこが異なるのかはひとつひとつ項目を確認しないとわかりませんが、使用回数をみると8回と4回の2種類の登録があることがわかります。ここで、どうやらメーカーによって登録内容が違うらしいと気付いて、薬剤タブで確認できればいいのですが、いずれにしても、気づきにくいことに変わりはありませんね。

このような場合を想定すると、とりあえずの対策としては検索時のソート項目を農薬の種類か、農薬通称で並べ替えるようにした方が良さそうですね。
(あるいはユーザーがソート条件を設定できるようにするか)

>現在は、登録番号が若いものが代表適用として使用されるようですが
代表適用というよりは、その農薬通称の最大限の登録適用が表示されます。なので
メーカーによっては通称モードで表示された登録が存在しないこともありえます。

ここらへんの注意点は、ACFinder サイトにまとめページを作りますか。

〔473〕Re:通称の代表適用の変更機能
 Hidemi Oya WEB  (06/08/31 22:40)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

>というか、全ての適用内容が同じだと、重複を省いて表示しますが、ひとつでも異なると、同一の農薬通称で異なる適用内容が表示されます。
 そうか、作物タブ・病害虫タブではそうなっていますね。ここんとこ定型処理ばかり使ってたので、作物タブ・病害虫タブでも同じだと思ってました。
 なるほど、SELECT DISTINCT の秘密はここにあったんですね。う〜む、こういう便利な使い方があるとは全く気づいてませんでした。実は、1月以上前から複数作物農薬一覧で適用作物が多い順に並べ替えられるようにしたいと思って、通称ごとの対象作物数のカウント方法をサブクエリーなどいろいろトライしてまして、今日
 COUNT(DISTINCT sakumotsu)
という実に簡単な方法でいけることに気がついたばかりでした。なかなか奥が深いですね、DISTINCT は。

 しかし、集約関数を使った定型処理では、通称でグルーピングしたデータを集約関数に渡すのが基本になるので、SELECT DISTINCT を使っても意味がありません。何かほかの手だてを考えなければなりませんが、さてどうやって回避したらいいんだろう…。

>ここで、どうやらメーカーによって登録内容が違うらしいと気付いて、薬剤タブで確認できればいいのですが、いずれにしても、気づきにくいことに変わりはありませんね。
 そういや、先日私の直属の上司が ACFinder 使ってて「ダコ1000が2つ出るけど?」っていってたので、「右ボタンクリックで薬剤タブで検索して、製剤ごとの登録を見てください」と話したところでした。

>ここらへんの注意点は、ACFinder サイトにまとめページを作りますか。
 注意点をまとめるというより、使用方法等も含めて FAQ か逆引きマニュアルのようなものがあるといいかもしれませんね。
 ここんとこ、事務所内で「こんなことできないの?」「これでできますよ」「こんな機能もあったんだ」というような会話が多いです。機能が豊富すぎて、なかなか全ての機能をみんなに知らせることもできませんし。

〔476〕解決:定型処理での対策
 Hidemi Oya WEB  (06/09/01 9:09)

引用なし
   自己レスです。

> しかし、集約関数を使った定型処理では、通称でグルーピングしたデータを集約関数に渡すのが基本になるので、SELECT DISTINCT を使っても意味がありません。何かほかの手だてを考えなければなりませんが、さてどうやって回避したらいいんだろう…。
 meisho でグルーピングしたデータを従来の SELECT 文に渡し、それをさらに SELECT DISTINCT * に渡せば OK でした。従来の SQL よりは若干速度低下しますが、気になるほどではありません(結果のレコード数が多いと顕著な速度低下があるかもしれませんが)。

SELECT DISTINCT * FROM (SELECT 従来設定 GROUP BY meisho)

〔478〕Re:解決:定型処理での対策
 Hidemi Oya WEB  (06/09/02 0:08)

引用なし
   さらに、自己レスです。

>SELECT DISTINCT * FROM (SELECT 従来設定 GROUP BY meisho)
 これって、結局
SELECT DISTINCT 従来設定 GROUP BY meisho
と同じですね(^_^;)。

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
65 / 114 ツリー <前へ | 次へ>
ページ:  ┃  記事番号:   
(SS)C-BOARD vv3.8 is Free.