Function DatabaseConnector->query_parameterised

Definitions

Do a named-parameter query, like "SELECT * FROM foo WHERE " . db_string_equal_to('a', '{value}') . ";" with ['value' => 'b'].Assumes nothing looking like {example} is in the query already.Also supports {prefix} for encoding the table prefix.You must still use db_string_equal_to and db_string_not_equal_to in the query where applicable.Lots of programmers like to do queries like this as it reduces the chance of accidentally forgetting to escape a parameter inserted directly/manually within a longer query.Usually we use APIs like query_select, which avoids the need for SQL all-together, but this doesn't work for all patterns of query.
Visibility: public
Is abstract?: No
Is static?: No
Is final?: No
Return: N/A

Name	Type	Default	Set	Range	Description
$query	string	required parameter	N/A	N/A	The complete parameter-ready SQL query
$parameters	array	required parameter	N/A	N/A	The query parameters (a map)
$max	?integer	Null	N/A	N/A	The maximum number of rows to affect (null: no limit)
$start	integer	0	N/A	N/A	The start row to affect
$fail_ok	boolean	False	N/A	N/A	Whether to output an error on failure
$skip_safety_check	boolean	False	N/A	N/A	Whether to skip the query safety check
$lang_fields	?array	Null	N/A	N/A	Extra language fields to join in for cache pre-filling / Tempcode, perhaps via the find_lang_fields function. You only need to send this if you are doing a JOIN and carefully craft your query so table field names won't conflict (null: auto-detect, if not a join)
$field_prefix	string	Blank (empty string)	N/A	N/A	All the core fields have a prefix of this on them, so when we fiddle with language lookup we need to use this (only consider this if you're setting $lang_fields)