sql >> Database teknologi >  >> RDS >> Mysql

Debug PDO mySql indsæt NULL i databasen i stedet for tom

Dette forekommer mig at være en (n urapporteret?) fejl i PDO's forberedte erklæringsemulering:

  1. implementeringen af PDOStatement::execute() til sidst påkalder pdo_parse_params() ;

  2. som til gengæld forsøger at citere/undslippe værdier baseret på den relevante parameters datatype (som angivet af $data_type argumenter til PDOStatement::bindValue() og PDOStatement::bindParam() -alle parametre angivet som $input_parameters til PDOStatement::execute() behandles som PDO::PARAM_STR , som angivet i dokumentationen for den funktion);

  3. streng-type værdier er escaped/citeret af opkald den relevante databasedrivers quoter() metode, uanset om de er null :i tilfælde af PDO_MySQL er det mysql_handle_quoter() , som (til sidst) sender værdien til enten >mysqlnd_cset_escape_quotes() eller mysql_cset_escape_slashes() , afhængigt af serverens NO_BACKSLASH_ESCAPES SQL-tilstand;

  4. givet en nul argument, returnerer begge disse funktioner en tom streng.

Min mening er, at før aktiverer parameterens type (i trin 2 ovenfor), pdo_parse_params() skal indstille typen til PDO::PARAM_NULL hvis værdien er null . Nogle vil dog hævde, at dette ville forhindre typespecifik håndtering af null værdier, hvor det er relevant, i hvilket tilfælde strengcasen (i trin 3 ovenfor) burde helt sikkert håndtere null værdier, før du fortsætter med et kald til førerens quoter() metode.

Som en midlertidig løsning er deaktivering af forberedt sætningsemulering normalt alligevel det bedste:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);



  1. Oracle finder en begrænsning

  2. MySQL-forbindelse virker ikke:2002 Ingen sådan fil eller mappe

  3. nul pointer undtagelse, når du forsøger at få adgang til DatabaseHelper i en kopieret database fra aktiver til data\data\

  4. hvad sker der i adoptionsfasen forberede