PHP SQL文（DELETE）がうまく動作しない

Question

前提・実現したいこと

フォームで受け取ったデータをSQL文に入れて一致したデータを削除するといった感じに動かしたいです
UtilConnDBの->Connect()はクラスの変数に入っているPDOの接続情報をreturnで返すものです。

発生している問題・エラーメッセージ

DELETEは実行されていて、$contでは１が帰ってきているのですが、DB上では情報が消されておらず何度実行してもうまくいきません、

該当のソースコード

<?php
require_once 'Include/utilConnDB.php';
$util = new UtilConnDB();
try{
    $pdo = $util->connect();
    $sqlword = 'delete from `skill` where syainbangou = '.$_REQUEST['id'].' and sikakucode = '.$_REQUEST['code'].';';
    $cont = $pdo->exec($sqlword);
    if($cont == 1){
        echo $cont.'<a href="jouhouhenkou.php?id='.$_REQUEST['id'].'">exit</a>';
        
        //header('Location:jouhouhenkou.php?id='.$_REQUEST['id']);
    }else{
            echo 'エラーが発生';
            echo $sqlword;
            //header('Location:jouhouhenkou.php?id='.$_REQUEST['id']);
    }
}catch(PODException $e){
    echo 'PDOエラー <a href="/Home/">戻る</a>';
}
?>

試したこと

exec()のほかにも、prepare()や、query()も試したのですが同じ結果になりました。
Select文は同じ記述でも普通に出力されるのですが
DELETEと同様にUPDATE文でも同じことが起こっています。

補足情報（FW/ツールのバージョンなど）

エディタはVisualStadioもしくは、VScodeで書いています。文字コードはUTF-8です。
SQL文はphpMyAdminの方では正常に動作していました。
使用DBはmySQLです

Comments

[m.ts10806]

PDO利用時のエラーモード設定はどうなってますか？
https://www.php.net/manual/ja/pdo.error-handling.php
設定無しだとExeptionはthrowされませんし、throwされるようにしても捕捉したExeptionを出力してないのでエラーが起きていても確認できる実装になっていません。

[m.ts10806]

あと、SQLインジェクションが可能なので、そこはなんとかしたほうが良いです。

[Chihaya]

PDO::ATTR_ERRMODE =>PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
これで合っていますか？無責任だと思うのですが、正直理解できていないです。
SQL文に関しては動きが確認でき次第bindValueで対策をとる予定です。
回答ありがとうございます！少しPDOのエラーについて調べてみます。

[m.ts10806]

理解できないことは無責任とは言わないのでは。

[Chihaya]

少し丸投げ感があったのでそう思いました。とくに深い意味はないです。

Answer 1

使用している DB が不明ですが、単純に
「commit していない」
からでは。

Comments

[m.ts10806]

タグとphpMyAdminというところからの推測にはなりますが、実装でどうなってるか、バージョンや環境、設定（オートコミットの有無）までは確かに不明ですね。

[tacsheaven]

delete の exec 結果行数が 1 だといっているので、SQL 自体は正常に動いている。
とすると、コミットくらいしかないですからねえ。

[Chihaya]

SELECT文に関しては正常に動いているのですがこれはコミットできていることになりますか？
SELECTとDERETEでプログラムの文法はあまり変えていないです。

[tacsheaven]

コミットが必要になるのは「データの変更が発生したとき（追加・更新・削除）」です。
SELECT は変更を伴わないので関係ありません。

※他のセッションで更新（トランザクションをかけている場合）したときにSELECTがどういう挙動をするかは設定によります。これは DB でのトランザクション制御の根幹部分ですのできちんと調べて理解しておきましょう

[Chihaya]

$pdo->commit();を追加したところ、動作しました
ありがとうございます！

[m.ts10806]

やはり、今提示されてる内容だけだとエスパーになってしまいますね。
MySQLのデフォルトはオートコミットですし。

Answer 2

$pdo->Commit();をexec($sqlword);の後に入れたら、無事反映されました。

Answer 3

本件と関連があるかどうかは別として、アプリケーションからDBに対してexecuteする場合、SQLは一本ずつしか実行できないので、終端はつける必要がなく、言語や機能によっては終端が自動でつけられた上で実行されるため自前でつけてしまったためにエラーが起きるということはありえます。

まあひとまず、エラーハンドリングするにしても、エラーをthrowされる設定にしないとthrowしてくれませんし、catchしてもExeptionを出力せず握りつぶす実装になっているので、何が起きても知る術がないようになっています。

SQLインジェクションへの考慮は必須です。

そんなときに参考したいまとめ記事はこれ。
PHPでデータベースに接続するときのまとめ

一通り対策しても変化がない場合、
実行されるSQLを取得し直接実行してみてください。

それでも変化がない場合、
接続時や実行前にオートコミットオフにしてたりしないかとか、既に回答で言及のあるコミットをしてみるとか（トランザクション開始はしましょう）、確実に実行されるような実装にしてみてください。

返却値も固定値で条件式通ったものを「1が返ってきてる」と根拠とするのではなく、var_dumpして返却値そのものを確認してください。
PHPマニュアルで確認すると分かりますが、返るのは行数だけとは限りませんし、警告にあるように比較が==では弱いです。

Comments

[Chihaya]

エラーの設定はExceptionになっていました。
DB接続のまとめも確認してみたのですが、見た感じ引っかかる項目はないと思いました。
var_dumpは使用していないのですが、echoで出力は出しています。別の場所でecho $cont;と行ったりはしていて、存在しないキー値を送信した場合は０が返りif文のelseの部分を通ることも確認できています。
try,catchは、まだ理解が浅いので調べてみます。

[m.ts10806]

質問に現状追記してください。
文章だけではこちらの意図が伝わった実装なのかわかりません。
echoよりvar_dumpのほうがデバッグとしては好ましいです。型も出してくれますから。
あと、utilConnDB.phpのコードも追記してください。

[m.ts10806]

>見た感じ引っかかる項目はないと思いました。

この短時間で読み切って理解できる分量ではないと思いますがSQLインジェクションでおもいきり引っかかってますよ。
https://qiita.com/mpyw/items/b00b72c5c95aac573b71#select--from-users-where-id--id-%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E5%A4%89%E6%95%B0%E5%B1%95%E9%96%8B%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6sql%E6%96%87%E3%82%92%E7%B5%84%E3%81%BF%E7%AB%8B%E3%81%A6%E3%81%A6%E3%81%84%E3%82%8B

ここも
https://qiita.com/mpyw/items/b00b72c5c95aac573b71#_postid-%E3%81%AA%E3%81%A9%E3%81%AE%E5%A4%96%E9%83%A8%E5%85%A5%E5%8A%9B%E3%81%8B%E3%82%89%E3%81%8D%E3%81%9F%E5%A4%89%E6%95%B0%E3%81%8C%E5%AE%9A%E7%BE%A9%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%9D%E3%82%8C%E3%82%89%E3%81%8C%E6%96%87%E5%AD%97%E5%88%97%E3%81%A7%E3%81%82%E3%82%8B%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%92%E3%81%97%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%81%9D%E3%82%8C%E3%82%89%E3%82%92%E5%87%BA%E5%8A%9B%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB-htmlspecialchars-%E9%96%A2%E6%95%B0%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84

[m.ts10806]

後回しにするとできなくなるのが人間の性です。
それに実装方法がそもそも変わるので似たような確認を何度もしなければならなくなり非効率です。

[Chihaya]

インジェクションは、とりあえず後回しにしています。動作が確認でき次第bindValueで対策をとる予定です。
あと、１週間くらいこれに躓いてたので
GoogleでPHP SQL DELETE 反映されない
や、動かない　記述法　などでヒットする部分については一通り確認したつもりです。
セキュリティの部分も見直さないといけないのですが、
とりあえず今は挙動のほうを重視してバグと格闘しています。

[m.ts10806]

質問に現状追記してください。
文章だけではこちらの意図が伝わった実装なのかわかりません。

[Chihaya]

非効率ですが、動きが確認できたらもう一度コードを書き直す予定です。（時間は結構あるので。）
いろいろリンクを送ってくださりありがとうございます。
もう一度見て回ってみます。

[m.ts10806]

utilConnDB.phpのコードも追記してください。

もしかしたら気づいてるかもしれないので老婆心ですが、現状のコードをなんとかしようと格闘するより提示したまとめ記事をきちんと理解するようにしたほうが、同じ1週間かけるとしても何倍も有用です。
プログラムは書いたとおりにしか動かないので「惜しい」という概念はないです。
それならより望ましい実装方法をはじめから覚えたほうが後々活きます。

どうしたいかは個人の自由なのでこのあたりにしておきますが、1エンジニアの先輩として思うところは伝えました。

[m.ts10806]

誤解して伝わってたら申し訳ないので補足しますと、
決して「この1週間は無駄だった」というつもりではなく、「次の1週間どう過ごすとより成長できるか」にフォーカスをあててもらえたらと思います。

それにSQLインジェクションについてはずっと突っ込まれ続けることになりますし、プリペアドステートメント使った実装で作り直しになるのは分かってるので、同じような確認、似たような問題を抱えるならはじめから好ましい実装をしておいたほうが時間が無駄にならないよねと言うことを伝えたいです。
時間が確保できるかどうかではなく、同じ時間を使うならよりよい使い方をしたほうが今後の成長にも大きく関わるのです。