considera Dichiarazioni preparate
utilizzato con concat()
come spesso accade.
DROP PROCEDURE if exists myStoredProc101;
DELIMITER $$
CREATE PROCEDURE myStoredProc101
( pSanitized VARCHAR(124)
)
BEGIN
set @mySql:=concat("SELECT DISTINCT ID FROM user where match(name) against ('* *",pSanitized,"* *')");
PREPARE stmt1 FROM @mySql;
EXECUTE stmt1;
DEALLOCATE PREPARE stmt1;
END
$$
DELIMITER ;
Il tuo processo memorizzato non ha avuto possibilità di funzionare in quanto non utilizzava nemmeno il tuo parametro. Quello che hai fatto è stato seppellire qualcosa all'interno di una stringa letterale. Inoltre, varchar(124) è un po' strano :p
L'unico successo che le persone hanno con le istruzioni preparate è l'utilizzo di una variabile utente (con un @ ) rispetto ai tentativi falliti di utilizzare le variabili locali (da DECLARE). Quindi, questo potrebbe farti risparmiare qualche ora di headbanging in futuro.
Dalla pagina del manuale PHP Procedure archiviate :
Per quanto riguarda la chiamata del processo memorizzato da mysqli , dai un'occhiata alla Risposta
di Pablo Tobar. Non sembra particolarmente piacevole con molte variabili, ma sembra che sia così. Avviso spoiler:usa variabili MySQL, non variabili PHP.
Certo, Pablo non stava restituendo un set di risultati, ma piuttosto scrivendo a un OUT var nel proc memorizzato. Forse devi fare quello che ha fatto per IN parametri e chiama multi_query() , quindi un store_result() , quindi un fetch_all() (in breve, il PHP fa riferimento a una pagina su).
In alternativa, una chiamata potrebbe essere effettuata da Palladium qui .
In entrambi i casi, è necessario prendere in considerazione per evitare la vulnerabilità nota del passaggio di SQL Injection oltre alle routine di stored procedure.
