FAMIC の検索システムが現行システムに戻ってから、病害虫マスター、作物マスターの更新タイミングがデータ更新と同時になっています。で、病害虫マスター関係の cbyochu, gbyochu を spec.db に置く意味が無くなってしまったというか、データ更新のたびに無駄な spec.db の更新が行われています。

　当面、byochu.txt から cbyochu/gbyochu 作成部を分離して、spec.bunrui.txt 辺りに入れておこうかと考えていますが、今の更新タイミングなら cbyochu/gbyochu を acis.db に置いた方が何かと便利そうです。
　ただ、現在の ACFinder では、cbyochu/gbyochu にアクセスするのに spec.cbyochu/spec.gbyochu とデータベース名で修飾しているため、acis.db に置いた cbyochu/ggaichu にアクセスできません。アタッチしたデータベース上のテーブルは、メインデータベースとテーブル名が重複していなければ、データベース名で修飾する必要はありません。単純に cbyochu/gbyochu というテーブル名にしておけば、テーブルが acis.db にあろうが spec.db にあろうが問題なくアクセスできます。
　ってことで、次回 ACFinder 更新時に、SQL 中の spec.cbyohu/spec.gbyochu を全て cbyochu/gbyochu に置換しておいてください。それだけで、いろんなケースに対応できるようになります。

　あと、レンタルサーバ側での acis.db/spec.db の更新がほぼ完成してきました。PC でのデータベース更新時間短縮のため、acis.db/spec.db をそれぞれ zip 圧縮して macs.o-ya.net/data/ で公開することにしました。更新タイミングは、acis.db については MACS 形式 CSV 同様に平日の 9, 12, 15, 18 時、spec.db は毎日３時間置きに実施する予定です。２～３日後から運用開始できると思います。
　ということで、ACFinder 側にこちらのデータのダウンロード機能を追加していただけるとありがたいです。

引用：　当面、byochu.txt から cbyochu/gbyochu 作成部を分離して、spec.bunrui.txt 辺りに入れておこうかと考えていますが、今の更新タイミングなら cbyochu/gbyochu を acis.db に置いた方が何かと便利そうです。　cbyochu は静的に作成しているのでこの方法が使えますが、gbyochu は vtllk102.do から動的に生成しているので、分離しても意味が無いですね。
　vtllk102.do は更新時刻を返してくれないので、更新状況を知る方法がありません。データが更新されたときは、vtllk102.do も更新されているかもしれないということで、データと併せて病害虫マスターも更新しています。
　このため、gbyochu もデータ更新と併せて更新せざるを得ません。現状では、少なくとも gbyochu は acis.db に置いた方が良いという結論になります。

バイナリエディタで acfinder.exe 内の

'from spec.'

を

'from      '

に一括置換したお試しバージョンを作ってみました。cbyochu/gbyochu 以外の spec.db 内のテーブルも全て spec. 修飾なしで使用することになります。
この状態で acis.db に cbyochu/gbyochu を置いて、spec.db からは削除したもので試してみましたが、病害虫タブも問題なく動作します。

spec.cbyohu/spec.gbyochu の件は了解です。
DBファイルのダウンロード、早急に対応するようにします。

DBファイルが公開されると、助かるところもありそうです。
認証プロキシ環境で、acfinder本体ではネット接続できないところもあるらしく、そのようなところでは、ブラウザで DBファイルをダウンロードして使ってもらうこともできます。

引用：DBファイルのダウンロード、早急に対応するようにします。　とりあえず、まだデータページにリンクは張っていませんが、acis.zip, spec.zip をダウンロードできるようにしました。acis.db, spec.db の更新の都合上、cbyohu/gbyochu が acis.db に入っているバージョンです。
　ということで、SQL 文の 'from spec.' を 'from ' に置換する件も併せて、データベースファイルのダウンロード対応をお願いします。

　あと、acis.db は MACS 形式の kihon.csv/tekiyo.csv をそのまま読み込んでテンポラリテーブルを作成し、そこから m_kihon, m_tekiyo, seibun テーブルを抽出する方式で作成しています。通称の抽出も SQLie 側で処理していますが、作物・病害虫マスター関係のテーブル群作成も含めて、レンタルサーバ上で 30 秒かからずにデータ更新できています。
　農薬の種類から個々の有効成分名を切り出す関数を SQLite クラスに追加する必要がありますが、ローカル PC 上でのデータベース更新をもっと高速化できるかもしれません。

データベース直接ダウンロード機能テスト版 exe のみです。
http://acfinder.kabe.info/acfinder130130test_exe.zip

設定＞基本設定＞ダウンロードサイト
で設定してから再起動してください。

作物タブUI修正途中なので、もしかしたら変なところがあるかも。

お疲れ様です。

ダウンロードサイトを切り替えて ACFinder を再起動したら、メモリーエラーになりました。それでもう１回再起動したら、またメモリーエラー。３回目の再起動で、メモリーエラーが出なくなりました。
もしかして、データベースを開いたまま .db ファイルを更新してないでしょうか？ データベースを閉じていないのに acis.db を更新してメモリーエラー、次に spec.db を更新してメモリーエラーという状況を疑っています。

ところで、プロクシ認証が通過できなくて手動でダウンロードする場合、データ更新ダイアログに、ローカルディスク上の acis.zip/spec.zip を指定してデータ更新する機能を付け加える必要がありますね。

ダウンロードした .zip ファイルを削除して再度試したら、やはり 「acis.db更新」とログに表示された瞬間にメモリーエラーが出て、spec.db は更新されませんでした。再起動すると、今度は「spec.db更新」とログに表示された瞬間にメモリーエラーです。

しかし、家の環境では 4MB の acis.zip でも一瞬でダウンロードできちゃうので、データ更新があっという間に終わります。メモリーエラーさえ出なければ、データ更新のストレスがなくて良いですねえ！

話は変わりますが、.zip ファイルを Download フォルダじゃなくて DB フォルダにダウンロードしてるのは何故？

ダウンロードサイトなんですが、MACS CSV の独自接続サイトは無くても良いのではないかと思います。
代わりに、.db の独自接続サイトを設定できるようにして、'http://' で始まっていればインターネットからの HTTP ダウンロード、違う場合は UNC による LAN 内ファイルサーバ(あるいはローカルディスク)からのファイルコピーにするのが良いのではないかと。これなら、プロクシ認証がらみで手動ダウンロードが必要な場合でも、だれかが所定の共有フォルダに新しい .zip データを保存しておけば、あとは ACFinder から自動更新が可能なはずなので、下記は不要になります。
引用：ところで、プロクシ認証が通過できなくて手動でダウンロードする場合、データ更新ダイアログに、ローカルディスク上の acis.zip/spec.zip を指定してデータ更新する機能を付け加える必要がありますね。
ただし、手動ダウンロードの場合、ダウンロードした .zip ファイルのタイムスタンプをオリジナルファイルのタイムスタンプに合わせられないのが問題です。ファイルコピーの場合、データベース更新チェックルーチンから変更が必要になり、.zip フィアル内の .db ファイルのタイムスタンプと、現在使用している .db ファイルのタイムスタンプを比較する必要があります。

事務所の 32bit Windows7 PC でも、自宅の 64bit Windows7 PC と全く同じ症状が発生することを確認しました。

引用：ただし、手動ダウンロードの場合、ダウンロードした .zip ファイルのタイムスタンプをオリジナルファイルのタイムスタンプに合わせられないのが問題です。ファイルコピーの場合、データベース更新チェックルーチンから変更が必要になり、.zip フィアル内の .db ファイルのタイムスタンプと、現在使用している .db ファイルのタイムスタンプを比較する必要があります。手動ダウンロードした .zip ファイルのタイムスタンプをオリジナルファイルに合わせることはできなくても、解凍した .db ファイルのタイムスタンプを手動ダウンロードした .zip ファイルに合わせるのは簡単ですね。
共有フォルダまたはローカルディスクからの .zip ファイルコピーの場合、解凍した .db のタイムスタンプを .zip と同じ値に設定しておけば、現在使用している .db とコピー元の .zip ファイルのタイムスタンプ比較で単純に更新チェックができます。

130130test 版ですが、ダウンロードサイトを切り替えた際に、データベース更新に失敗すると、どちらのデータベースにも cbyochu/ggaichu が存在しないというケースが発生しました。
各種テーブル作成クエリーを調整している際に起きた事故なので、そうそうあるとは思いませんが、できれば byochu.txt を読み込んだら、'spec.' を削除してから実行するように修正をお願いします。

sql := AnsiReplaceText(sql, 'spec.', '');

新しい spec.zip/acis.zip をダウンロードしても、中のファイルを解凍してくれません。ダウンロードサイトを切り替えた時は問題なく解凍してたので、7-zip のオプションの問題ではなさそうです。

やはり、トラブル対策としてデータ更新ダイアログに「SQLite DB」用のタブがあった方が良さそうです。

引用：新しい spec.zip/acis.zip をダウンロードしても、中のファイルを解凍してくれません。これは、自宅の 64bit Windos7 での話だったんですが、事務所の 32bit Windows7 でも同様です。Linux の zip で圧縮した書庫を、7-zip32.dll が解凍できないってことでもないとは思うんですが、一度 dll のエラーコードを確認してもらった方が良いかもしれません。

acis.db/spec.db の更新時にエラーになるのも、.zip をダウンロード後解凍できないのも、根っこは同じではないかと思われます。acis.db/spec.db を開いているために、解凍した .db ファイルを上書きできない状態になっているのではないかと…。
ただ、そうだとすると、FAMIC CSV から .db 直接ダウンロードに切り替えたときだけ解凍できたのが謎なんですけど。

もしかすると、FAMIC CSV 更新時に acis.db を削除できないことがあるのも、原因はこの辺にあるのかも…。ダウンロードサイトの設定にかかわらず、ACFinder 起動時に一度 acis.db を開いてませんか？
もしそうなら、各ファイルの更新チェックの後で、acis.db を開くようにした方が良いかもしれません。ファイル更新チェックはローカルファイルのタイムスタンプとダウンロード元ファイルのタイムスタンプの比較で行っているはずなので、最初に acis.db を開く必要はないはずですから。
というか、kabe さん自身はこういうように変更したつもりだけど、メインフォームの OnCreate/OnShow 辺りに消し忘れた acis.db オープンルーチンが残っているとか…。