Ik gebruik wat regex functies voor het splitsen en/of valideren van strings.
Nu lijkt echter dat wanneer de string langer is dan een x aantal karakters, dat ik een 'error 500 interne server fout' krijg. Met kortere strings is er echter geen probleem
Zowel de preg_match_all als de preg_split geven zo'n fout bij een te lange string.
<?php
$string = "UPDATE `#_module_webpage` SET `content` = 'Lorem ipsum..' WHERE `id` = '3' LIMIT 1;";
Ik weet niet precies hoe het zit, maar die error heeft volgens mij niet met de duur van je uitvoer te maken. Je kan wel proberen om je string in stukjes te knippen. (gebruik hiervoor bijvoorbeeld het script dat strings afkort op een aantal tekens, maar wel de woorden in tact laat. Staat in de script lib)
[edit][offtopic]
@mebus
Het is voor jezelf veel gemakkelijker om gewoon goede namen te kiezen die niet overeenkomen met gereserveerde woorden. Een simpele query kan daardoor toch verkeerd worden gelezen/ begrepen wanneer je hem terugleest, en als je een keer backticks vergeet werkt het niet, bijv:
Een setup voor een tabel met shows die worden gegeven. Waarbij het ook mogelijk is om de weergave van een show te blokkeren, omdat die bijv nog niet vast staat.
TABLE: Show
id
name
description
show (laat zien of niet)
Snap je wat ik bedoel? Als je nu een show (weergave) in MySQL zou willen doen van deze tabel, dan krijg je een query waarin het woord Show nogal vaak voorkomt, wat voor je eigen overzicht niet handig is.
Kies dan als tabelnaam bijvoorbeeld: Show_Info (heb je geen backticks bij nodig, en je tabelnaam beschrijft ook nog eens beter wat voor informatie erin zit)
En voor de kolom show -> maak daar bijvoorbeeld viewable van. Ook hierbij heb je dan geen backticks nodig, en het beschrijft ook het doel van die kolom beter.
Door op zo'n manier met je database om te gaan hou je je tabellen en query's eigenlijk heel eenvoudig. En door juiste namen te gebruiken kan je ook heel snel de bedoeling van een query begrijpen, zonder dat je daar andere informatie dan de query zelf voor nodig bent.
Verder lijkt het me beter maar weer ontopic verder te gaan. :)
[/offtopic][/edit]
De queries vorden verwerkt in een CMS systeem.
Dit CMS hanteerd een tabel-naam-prefix die in queries steeds wordt aangeduid met een hekje.
Deze functie vervangt vervolgens de hekjes met de geconfigureerde prefix.
Om te voorkomen dat hekjes in data niet worden vervangen door de ingestelde prefix, wordt in de query de boel gesplits naar waarden tussen single quotes (data), en alle overige waarden (tabelnamen e.d.). Op deze laatste wordt een str_replace losgelaten die alle hekjes vervangt door de ingestelde prefix.
Op mijn server gaat dat goed, maar op een andere server (waar ik het CMS heb geinstalleerd) treden er problemen op als de query te lang is.
Dit is trouwens de database class die ik gebruik binnen het CMS.
Zie de __setPrefix() functie onderin..
<?php
class Database
{
var $resource; // Stores the resource identifier of the connection to the SQL server.
var $user; // username
var $pass; // password
var $name; // name of the database
var $host; // host (An IP or 'localhost')
var $prefix; // Table prefix (replace "#" for "[prefix]").
var $charset; // communication charset
// Creates a new database
function Database($user, $pass, $name, $host = "localhost", $prefix = false, $charset = false)
{
// Connect to database server
if($this->resource = mysql_connect($host, $user, $pass))
{
// Select a database on the MySQL Server
if(mysql_select_db($name))
{
// Locked to requested database
$this->user = $user;
$this->pass = "**********"; // $this->pass = $pass;
$this->name = $name;
$this->host = $host;
$this->prefix = $prefix;
$this->charset = $charset;
if($charset)
{
// Set communication characterset
$sQuery = "SET CHARACTER SET '" . $charset . "';";
$this->execute($sQuery, __FILE__, __LINE__);
}
}
else
{
// Error while selecting database
exit("Error while connecting to database\nFile: " . __FILE__ . ", Line: " . __LINE__ . ".");
}
}
else
{
// Error while connection to server
exit("Error while connecting to database.\nFile: " . __FILE__ . ", Line: " . __LINE__ . ".");
}
}
// Function to execute a SQL stetement (eg. DELETE/INSERT/UPDATE).
function execute($sQuery, $sFile = false, $iLine = 0)
{
$sQuery = $this->__setPrefix($sQuery);
// Returns the last created record-id (only works after an INSERT-statement).
function getId()
{
return mysql_insert_id($this->resource);
}
// Returns upto 1 record after running a SQL-statement.
// No results will return FALSE.
function getRecord($sQuery, $sFile = false, $iLine = 0)
{
$rsResults = $this->getRecords($sQuery, false, $sFile, $iLine);
// Returns all records after running a SQL-statement.
// The columnnames are stored at index
// No results will return an array with only the columnnames (at index 0).
function getRecords($sQuery, $bAddHeader = false, $sFile = false, $iLine = 0)
{
$sQuery = $this->__setPrefix($sQuery);
$aResults = array();
// Returns true if a column exists, false otherwise.
// Note: Columnnames are CASE SENSITIVE in MySQL!!
function isColumn($sTableName, $sFieldName)
{
// Get all fields withing table
$aFields = $this->getColumns($sTableName);
return in_array($sFieldName, $aFields);
}
// Returns true if a field table, false otherwise.
// Note: Tablenames are CASE SENSITIVE in MySQL!!
function isTable($sTableName)
{
if($this->prefix !== false)
{
if(strcasecmp(substr($sTableName, 0, 1), '#') === 0) // Tablename starts with #
{
$sTableName = $this->prefix . substr($sTableName, 1);
}
}
// Get all tables withing database
$aTables = $this->getTables();
return in_array($sTableName, $aTables);
}
// Print SQL output into a HTML based table.
// Note: This function was added to support the testing of SQL queries.
function printSQL($sQuery)
{
// Execute SQL and retrieve records
$rsRecords = $this->getRecords($sQuery, true, __FILE__, __LINE__);
Backticks zijn in mijn ogen een standaard onderdeel van de SQL syntax..
Net als dat de openingtag van PHP officieel "< ? php" is, en niet "< ?". Toch werken ze allebei ;)
Door backticks voor kolomnamen expliciet te gebruiken worden (in mijn ogen) queries leesbaarder. 't is een questie van smaak, gewoonte en (mogelijk) gemakzucht dan wel het een of het ander te gebruiken..
Tevens worden door gebruik van backticks spaties, speciale tekens en gereserveerde 'keywords' toegankelijk als/in tabelnamen. Niet dat ik hierbij een discussie aan wil gaan of het gebruik van spaties o.i.d. aan te raden is in een tabelnaam.. maar de 'technische beperking' is in ieder geval geen excuus meer..
Ja, dat scheelt nogal een slok op een borrel. Maar misschien is de code van jouw eigen functie wel veel korter dan de source code voor preg_match_all. (vermoed van wel)