蔵書管理からのランチャーソフトですもんで「ファイルが有る前提」というスタンスが難しい所なんですよね。
以下、list_view の実態である main_table で考察してみました。
tkSQLite とか DB Browser for SQLite とかで実験すると手軽で見易いです。
判りやすいようプライマリキー、ファイル名本体、拡張子 のみ抽出しています。
CatShanty2のクエリにするにはいつもの通り、SELECT * list_view 〜〜に置き換えればOKです。
(しかし file_title って命名がまた・・ねぇ・・ 今なら file_body にするだろう・・)
----
ファイル名本体がプライマリキー(フルパス)のと異なるものを探すなら、
単純にフルパス中にファイル名本体が含まれるか否かで調べるというのはどうでしょうか。
SELECT file_name, file_title, file_ext FROM main_table WHERE
file_name NOT LIKE '%' || file_title || '%'
イメージの取り込み先が必ず何かしらのディレクトリ下にあるのなら "\ファイル名" として条件を厳しくするのもアリかも。
SELECT file_name, file_title, file_ext FROM main_table WHERE
file_name NOT LIKE '%\' || file_title || '%'
----
拡張子に . が混ざっているのは気づきませんでした。バグですな(^^;
自分の DB も調べたら確かに 2009〜2010年頃に取り込んだものに、幾つか入ってました。
SELECT file_name, file_title, file_ext FROM main_table
WHERE file_ext LIKE '.%'
どこの処理で入るのか、今は入らなくなったのか、チョッチもう調べる気力がありまへんので(ォィ
根本的解決ではありませんが以下のSQLで修正できるかと思います。
!!追記:あ、バックアップは取ってからやってくださいね!!
UPDATE main_table SET file_ext = replace(file_ext, ".", "")
WHERE file_ext LIKE ".%"
----
ActiveBasic じゃなく HSP が正解だったか.. orz
# 整合性と言えば、他のテーブルのプライマリキーとの整合性、トリガを仕掛けていたと思っていたら抜けていたかも知れない・・。
SQLiteは1ファイルコピーするだけでバックアップも取れるしイイですよね。