SQLiteにおける=とlikeの違い


iPhoneアプリ(objective-c)でライブラリFMDBを用いて、SQLiteを操作する際の話です。

あるテーブルでWHERE句を1個だけ含む簡単なSQLを呼んだ際に、`=`と`like`で結果が異なります。  
具体的には`like`では結果が返ってきますが、`=`では結果が返ってきません。

例：  
テーブル「`table1`」が以下の時、

[code]

    id(text) val(text)
    00001 test1
    00002 test2
    00003 test3
    
[/code]

`SELECT * FROM table1 WHERE val = 'test1'`  
では1行も返ってきませんが  
`SELECT * FROM table1 WHERE val like 'test1'`  
では1行返ってきます。

空白や不可視の文字が入っていた場合など逆の結果ならばまだ分かるのですが、`like`のみで出る理由が分かりません。

このような動きをする原因について何か分かる方いますか？  
SQLiteを使用するのは今回が初めてなので根本的な理解不足があるかもしれません。

同じSQLiteファイルをWindowsやmacのDB browser for sqliteで試すと上記に反して正常に結果が返るため、  
文字コード(linux:utf-8,
ios:utf-16)の違いかあるいはFMDBの問題かと想像していますが、調べてもそれらしい情報を見つけられなかったので質問しました。

[環境]  
SQLiteファイルはサーバー上のphpにてPDO(sqlite:)で生成しており、iPhoneアプリでダウンロードし読み込もう(ライブラリ:FMDB)としています。  
サーバー: CentOS 7.9, php 7.1, pdo_sqlite 3.7.17  
端末: iPhone SE2, iPhone SE3, iPhone 13, iPhone 14 Pro, iOS 16, XCode 14.2,
objective-c




解決しました。  
コメントの通り、TEXT型で定義されてる列にデータがBLOBでセットされていた事が原因でした。

[code]

    SELECT typeof(id) FROM MHYJS WHERE val like 'test1';
    result:blob
    
[/code]

列の定義とは異なる型が入ってしまうんですね。  
likeは文字毎比較だったと思うので、結果的に文字毎でエンコードされて認識されたという事でしょうか。

サーバー上では

[code]

    $sqlite_stmt->bindValue(':val', "hogehoge", SQLITE3_TEXT);
    
[/code]

とやっているんですが、何故BLOBで入ったんだろうか…

* * *

追記：  
BLOBで入ってしまった理由が分かりました。  
実に愚かで恥ずかしい話ですが、phpでPDOからSQLiteを使っているのにも関わらず、引数に与えた型を表す定数が通常のSQLite3クラスの物でした。単なる定数間違いです。

以下が正しいです  
`$sqlite_stmt->bindValue(':val', "hogehoge", PDO::PARAM_STR);`

間違ってSQLite3クラスの定数をPDOで呼んだSQLiteに型の引数として与えると、noticeレベルのエラーも吐くことなくとりあえず全てblobで動作するようです。

要らない知見かもしれませんが、追記しておきます

