'select all' selects all NOOOOOOO!

perplexed · #16 (**permalink**) 18-05-09, 12:06 AM

Did that and it's now giving the error message,

parse error, unexpected T_STRING

As a result i've scoured my script for matching {} and " " all are there. I also searched for any missing ; and didn't find any.

I can paste my script here but the only thing that throws me is that the error refers to line 27, however when pasting here i'm pretty sure the number of lines will be at odds to those on my script page.

In order to be sure of where line 27 was (initially it gave line 30) i got rid of all the empty white space lines that i insert to make reading a script easier.

However, despite that, i can open in notepad my script - which has no empty lines - right-click and copy, then paste into a newly opened notepad and it will add empty white space lines, spacing the script out. This obviously affect the line numbering. As does whether i edit the script in a fully open notepad window or any intermediate size.

I'm once again getting very frustrated as i can't see where on earth the unexpected T_string error is coming from.

I can paste the script and (as it will present in a different number of lines to the actual one) number the lines as they are in the actual script.

Your continued help is appreciated and, as with every forum of this kind, i'm sure it will help many others in the future with the same problem.

perplexed · #17 (**permalink**) 18-05-09, 12:46 AM

OK officially going insane now. I've just gone to paste the script here using the forum's code tags, as i did earlier with no problem.

However, it presents a mixture of the code as written and part code with blank spaces for the codes results etc a right messy mixture. I've tried inserting code tags on each line with no joy.

**Dan** · #18 (**permalink**) 18-05-09, 06:08 AM

I'm not a true expert in PHP but for a T_STRING error I usually replace all " on the line with ' except the parent quotes.

black-dog · #19 (**permalink**) 18-05-09, 07:07 AM

Quote:

Originally Posted by perplexed

OK officially going insane now. I've just gone to paste the script here using the forum's code tags, as i did earlier with no problem.

I'm not surprised you are going insane if you are trying to develop code without line numbering or syntax highlighting. Download a copy of notepad++ and open your code in that. Make sure 'language' is set to php.

To paste php here use [ php ] ,[ /php ] tags

perplexed · #20 (**permalink**) 18-05-09, 10:05 PM

The Notepad++ was something i've never seen before so many thanks for putting me on to that. I've opted for the Unicode version, hopefully that's the right decision?.

The main reason for that was seeing mention of a 'save as Unicode without BOM'. At the moment that means bleep all to me except that this BOM may be the culprit in preventing even simple web pages of my site displaying on many browsers.

See (if you dare) the posts numbered 7,8 and 13 in the thread titled,

What's different? transfer to WHUK simplest codes and scripts not working

Anyway back to the matter in hand, after much more tinkering within the script for various reasons (you don't want to know lol) i now get the message

'Fatal error: Function name must be a string in E:\inetpub\vhosts\website.com\subdomains\xxxx\http docs\xxxx.php on line 21' Line 21 refers to the $error reporting(E_ALL)

I've come across this scenario many times where as one appears to correct one problem it throws up another.

If writing a script nowadays i will use CSS for styling, the script below is one when i was barely aware of basic HTML let alone php/Mysql. So forgive the odd spacing of the bold tag etc. however, it did the job.

PHP Code:


			
<html>

<head><title>xxxx.php</title></head>



<body bgcolor="#ffffff"><b>



Today's Date is: <?php

$differencetolocaltime=1;

$new_U=date("U")-$differencetolocaltime*3600;

echo date("l, d, F, Y");

?>

<br>



The time is now: <?php

$differencetolocaltime=1;

$new_U=date("U")-$differencetolocaltime*3600;

echo date("H:i", $new_U); 

?><br><br>





<?php

$error_reporting(E_ALL); 

$conn=@mysql_connect("localhost", "xxxx", "xxxx") or die("could not connect");

$rs=@mysql_select_db("xxxx", $conn) or die("could not connect to database");

$a=mysql_real_escape_string($_POST['a']);

$b=mysql_real_escape_string($_POST['b']);

$c=mysql_real_escape_string($_POST['c']);

$sql=("SELECT * FROM table_name WHERE '$a' LIKE '%$b%' ORDER BY '$c'");



$rs=mysql_query($sql, $conn) or die("could not execute query because ".mysql_error());



$list="<table border=\"1\" cellpadding=\"2\">";



$list.="<tr><th>SONG</th>";



$list.="<th>FOLDER</th>";



$list.="<th>INSTRUMENT</th>";



$list.="<th>ARTIST</th></tr>";

while($row=mysql_fetch_array($rs))

{

$list.="<tr>";

$list.="<td>".$row["SONG"]."</td>";



$list.="<td align=center>".$row["FOLDER"]."</td>";



$list.="<td>".$row["INSTRUMENT"]."</td>";



$list.="<td>".$row["ARTIST"]."</td>";



$list.="</tr>";



}$list.="</table>";



echo($list);



echo($sql);

?>



<font color="red"><u>Interaction Successful</u></font> ~~~ <b>Now choose where to go to from here.</b><br>



<a href="xxxx.php">FIND</a><br>



<a href="xxxx.php">ENTER NEW RECORD</a><br>



<a href="xxxx.php">ENTER MULTIPlE NEW RECORDS</a><br>



<a href="xxxx.php">CHANGE</a><br>



<a href="xxxx.php">DIRECT INTERACTION</a><br>







</b>



</body>

</html>

black-dog · #21 (**permalink**) 18-05-09, 10:26 PM

Quote:

Originally Posted by perplexed

'Fatal error: Function name must be a string in E:\inetpub\vhosts\website.com\subdomains\xxxx\http docs\xxxx.php on line 21' Line 21 refers to the $error reporting(E_ALL)

It's a function. It shouldn't have a $ sign, that's just for variables.

perplexed · #22 (**permalink**) 19-05-09, 04:47 AM

Yes i saw that myself and removed it. It got accidentally inserted when playing around with the script.

What is happening now with the script (exactly as above minus the errant $) is that it will display the table headings and echo the query as

SELECT * FROM table_name WHERE 'artist' LIKE '%beatles%' ORDER BY 'song'

Unfortunately, no results appear under the respective table headings.

black-dog · #23 (**permalink**) 19-05-09, 07:11 AM

Quote:

Originally Posted by perplexed

Yes i saw that myself and removed it. It got accidentally inserted when playing around with the script.

What is happening now with the script (exactly as above minus the errant $) is that it will display the table headings and echo the query as

SELECT * FROM table_name WHERE 'artist' LIKE '%beatles%' ORDER BY 'song'

Unfortunately, no results appear under the respective table headings.

Good, progress. That means you have no syntax errors and that your query is executing successfully. Unfortunately it is returning no results.

The first thing that strikes me is the name of your table. Is it really called 'table_name'? That looks more like a place holder.

Secondly there is an inconsistency in your column headers. You have ORDER BY 'song' and yet later on in your script you have $row["SONG"]. PHP is case sensitive, is your column header 'song' or 'SONG'? Go to phpMyAdmin to check. (I doubt this is the problem, but you should make a habit of being consistent)

You can also copy and paste the SQL query into the SQL window and test it. Once you have it working properly there you can make sure that your PHP is generating a properly formatted query that will return results.

However, the main problem is the single quotes around artist and song. They should either be removed or replaced by backticks (top left hand key on your keyboard) They are NOT the same as single quotes.

Try

PHP Code:


			
$sql=("SELECT * FROM table_name WHERE `$a` LIKE '%$b%' ORDER BY `$c`");

This must be something you've changed, I can't see how it would ever have worked as it was.

perplexed · #24 (**permalink**) 19-05-09, 08:18 AM

I best clear up some confusion first on a couple of counts.

Despite the database being hosted on my website it's solely for private use. However, i was alarmed to read that my basic script could have security loopholes etc. In view of that solely for the purpose of displaying in this forum i've been replacing information with 'xxxx' and renaming files and fields referred to within the script, however, the actual scripts on my site have NOT changed. Obviously, in all these years it has been operating faultlessly i wasn't employing any 'reserved' names within php/MySql.

Regarding the changing query throughout this thread, sorry, although it hasn't made any difference to the problems presenting themselves. The actual web page that interacts with the database has several combinations of search fields that can be used.

In the last example i've cut the SQL query down to the minimum number of fields. As i select artist 'whoever' order by 'song'. Alternatively, i may have referred to select song '%love%' order by 'artist'. I use radio buttons on the form so that's why the field names may have varied in my displaying examples, but the key thing is that it made no difference to the examples.

Likewise, i can assure you that case sensitivity is fine and has passed the test for near a decade. The 'song' example is explained by the fact that the capitalized version is for the visually displayed pages header sections, and the small version is as referred to in the form and database. I actually made a point of capitalizing one and not the other so as not to confuse myself when compiling scripts.

I'll show you one section of the web page form that targets the script below.

I'm totally taken aback by your comments on using backward ticks. In the years when i was actively compiling php/MySql i only ever saw single and double quotes as a means of coding. I can't remember being told to use backward ticks, is that a new thing, or not at all???.

I did indeed try as you suggested using the ticks but it throws up an 'unknown column' error when i use them. I also had already spent hours trying every combination of single/double/no quotes and brackets/no brackets. I'm not being lazy waiting back for answers i am plugging away with every suggestion offered and trying new things as well.

If it helps this is what is feeding the query (please don't be put off if field names don't match something previous, i can assure you in the actual forms and database nothing has changes in nearly 10 years - the 'ID' field is one i use for displaying most recent entries)

HTML Code:

<form method="POST" action="xxxx.php">
<a name="first">
<font color="#000099"><center>VARIABLE ONE FIELD SEARCH~~~AUTOMATIC WILD-CARD</center></font>
<dl>
<dt><font color="#000099">SELECT ALL WHERE </font> <br>
<dd><input type="radio" name="a" value="song"><b>SONG</b><br>
<dd><input type="radio" name="a" value="folder"><b>FOLDER</b><br>
<dd><input type="radio" name="a" value="instrument"><b>INSTRUMENT</b><br>
<dd><input type="radio" name="a" value="artist"><b>ARTIST</b><br><br>

<dt><font color="#000099">LIKE </font><br>
<dd><input type="textarea"  name="b" rows="1" cols="50"> <font color="#ff0000">If you don't know the exact wording, enter what you know.<br>  As the Search employs an automatic Wild-Card system.</font><br><br>

<dt><font color="#000099">ORDER BY</font> <br>
<dd><input type="radio" name="c" value="song"><b>SONG</b><br>
<dd><input type="radio" name="c" value="folder"><b>FOLDER</b><br>
<dd><input type="radio" name="c" value="artist"><b>ARTIST</b><br>
<dd><input type="radio" name="c" value="id"><b>ID</b><br><br>

<input type="submit" value="SEARCH"><input type="reset" value="RESET">
</form>
</dl>
<hr size="3" width="100%" color="#00ff00">

Code:

<form method="POST" action="xxxx.php">
<a name="first">
<font color="#000099"><center>VARIABLE ONE FIELD SEARCH~~~AUTOMATIC WILD-CARD</center></font>
<dl>
<dt><font color="#000099">SELECT ALL WHERE </font> <br>
<dd><input type="radio" name="a" value="song"><b>SONG</b><br>
<dd><input type="radio" name="a" value="folder"><b>FOLDER</b><br>
<dd><input type="radio" name="a" value="instrument"><b>INSTRUMENT</b><br>
<dd><input type="radio" name="a" value="artist"><b>ARTIST</b><br><br>

<dt><font color="#000099">LIKE </font><br>
<dd><input type="textarea"  name="b" rows="1" cols="50"> <font color="#ff0000">If you don't know the exact wording, enter what you know.<br>  As the Search employs an automatic Wild-Card system.</font><br><br>

<dt><font color="#000099">ORDER BY</font> <br>
<dd><input type="radio" name="c" value="song"><b>SONG</b><br>
<dd><input type="radio" name="c" value="folder"><b>FOLDER</b><br>
<dd><input type="radio" name="c" value="artist"><b>ARTIST</b><br>
<dd><input type="radio" name="c" value="id"><b>ID</b><br><br>

<input type="submit" value="SEARCH"><input type="reset" value="RESET">
</form>
</dl>
<hr size="3" width="100%" color="#00ff00">

black-dog · #25 (**permalink**) 19-05-09, 09:09 AM

Quote:

Originally Posted by perplexed

Despite the database being hosted on my website it's solely for private use. However, i was alarmed to read that my basic script could have security loopholes etc.

Yes, your script would have been open to SQL injection (Google it)

Quote:

Originally Posted by perplexed

In view of that solely for the purpose of displaying in this forum i've been replacing information with 'xxxx' and renaming files and fields referred to within the script, however, the actual scripts on my site have NOT changed. Obviously, in all these years it has been operating faultlessly i wasn't employing any 'reserved' names within php/MySql.

I realise you were changing things, but I have no idea what is a change and what is a mistake.

Quote:

Originally Posted by perplexed

Regarding the changing query throughout this thread, sorry, although it hasn't made any difference to the problems presenting themselves. The actual web page that interacts with the database has several combinations of search fields that can be used.

In the last example i've cut the SQL query down to the minimum number of fields. As i select artist 'whoever' order by 'song'. Alternatively, i may have referred to select song '%love%' order by 'artist'. I use radio buttons on the form so that's why the field names may have varied in my displaying examples, but the key thing is that it made no difference to the examples.

I understand all that

Quote:

Originally Posted by perplexed

Likewise, i can assure you that case sensitivity is fine and has passed the test for near a decade. The 'song' example is explained by the fact that the capitalized version is for the visually displayed pages header sections, and the small version is as referred to in the form and database. I actually made a point of capitalizing one and not the other so as not to confuse myself when compiling scripts.

Nevertheless for the purpose of others reading this thread I have to point out that it is bad practice. MySql may be case insensitive, but PHP isn't.

Quote:

Originally Posted by perplexed

I'll show you one section of the web page form that targets the script below.

The web form is not the problem

Quote:

Originally Posted by perplexed

I'm totally taken aback by your comments on using backward ticks. In the years when i was actively compiling php/MySql i only ever saw single and double quotes as a means of coding. I can't remember being told to use backward ticks, is that a new thing, or not at all???.

Backticks are a way of enabling you to use reserved words as column names. You can remove them if you are not, but you can't use ordinary (single or double) quotes.

Quote:

Originally Posted by perplexed

I did indeed try as you suggested using the ticks but it throws up an 'unknown column' error when i use them. I also had already spent hours trying every combination of single/double/no quotes and brackets/no brackets. I'm not being lazy waiting back for answers i am plugging away with every suggestion offered and trying new things as well.

I'm not suggesting you are being lazy. Have you looked at phpMyadmin yet? What does the SQL look like that produces the unknown column error?

black-dog · #26 (**permalink**) 19-05-09, 09:47 AM

It occurs to me that this is going beyond what might interest a general forum reader. I feel sure that the only problem with your original script was the register global issue which should be simple to resolve. If you have your original script, please mail it to me (take out passwords of course) and I'll have a look.
Mail to bl(at)ckdog.co.uk

perplexed · #27 (**permalink**) 19-05-09, 03:45 PM

In the brain burning haze of coding problems i had quite forgotten about the register global issues. Having said that i did mention in an earlier post 'I've looked under 'Server variables and settings' and in a very long list can find no mention whatsoever of 'global_variables'...so are they on or off? haven't got a clue and before i smash my computer against the wall...i'm walking away and will try again tomorrow.' LOL

Like i say i compiled these scripts nearly ten years ago and left them running. Clearly things have changed - although having said that, Lycos upgraded php and MySql every time it was changed. The last version i was using had a very similar number to this latest one in use by WHUK.

Sorry wasn't inferring at all that you were indicating i was lazy, i was just assuring you i am toiling away on this.

I've not tried the SQL window yet not had time, obviously i will do later. Also, whilst (if i can get my scripts working) i am delighted to have left Lycos and moved to WHUK, a major bugbear is the Plesk interface in that it takes an eternity to go from page to page and during the evening hours simply doesn't load at all.

I'll wait until the early hours in the hope the interface will run quicker and search again for mention of this global variables. I possibly gave up last time it was mentioned due to the awful delay in going from page to page. If it helps, i presume i am in the same boat as any other WHUK user, therefore, that will answer whether or no the globals are on or off.

If with Lycos they were the opposite, then what changes are needed in a script?

I'll have another stab at the whole thing before troubling you by email. Incidentally, i'm hopeful that i have somewhere (certainly in printed form) the data sheet of php/MySql i used with my previous host and i know for a fact it does clearly refer to global variables status. I'll have a good rummage and find that.

Many thanks assistance much appreciated.

black-dog · #28 (**permalink**) 19-05-09, 05:35 PM

Quote:

Originally Posted by perplexed

In the brain burning haze of coding problems i had quite forgotten about the register global issues.

Well I hadn't. That's what

$a=mysql_real_escape_string($_POST['a']);
$b=mysql_real_escape_string($_POST['b']);
$c=mysql_real_escape_string($_POST['c']);

was all about.

register_globals was a setting in earlier versions of PHP where a value from a form would automatically become a variable in the receiving script. This can be a security issue in badly written scripts ans so was set to off in later versions of PHP. It's been coming for years and so most scripts will have been changed. For good measure I escaped the variables because you can't trust user input when you are forming database queries (Google SQL injection)

perplexed · #29 (**permalink**) 20-05-09, 03:37 AM

Regarding the snippet you provided below, yes i've inserted that into the script and will be adding it to every single script i have.

PHP Code:


			
$a=mysql_real_escape_string($_POST['a']);

$b=mysql_real_escape_string($_POST['b']);

$c=mysql_real_escape_string($_POST['c']);

If i can get Plesk operating, i'll mess around with the SQL window and plough through the php and MySql documentation. I'll compare it to the Lycos php info and see if i can spot any differences in settings. If that fails i'll email you the scripts.

perplexed · #30 (**permalink**) 20-05-09, 05:15 AM

I don't care that i'm likely to get a few bumps on my head as i stumble about the room with severe sleep deprivation. Why not? because the euphoria of nailing a coding problem is something i forgot about. When all the total frustration and despair is vanquished...yep i got that joyous and triumphant feeling now.

I went to access the SQL window and documentation etc, but as has always been the case, simple links to pages were taking ten minutes to load or not at all.

Now one of the things i have been mightily impressed with since moving to WHUK is the 'Live Chat' facility. The operatives are head and shoulders over those in any service centre. I've reccommended WHUK to lots of people because of the ease in which one can obtain live help.

So i got in touch with them, now hopefully it's not a temporary fix because the servers will have a lighter load in the early hours but, they cleared some sort of jam causing the server to load slowly.

That meant i was able to just get right in there and work my socks off trying a myriad of combinations of quotes and brackets and syntax in the SQL window.

At first i thought this is insane as i pasted queries from the internal interface after using it's search/select facility and everything failed. To make matters worse was the bizzarre wording referring to terms i have never seen in php queries such as latin1_swedish_ci etc, also the operatives CONVERT and USING were inserted into the query - example below. It totally threw me.

SELECT *
FROM `table`
WHERE `SONG` LIKE CONVERT( _utf8 'love'
USING latin1 )
COLLATE latin1_swedish_ci
AND `ARTIST` LIKE CONVERT( _utf8 'beatles'
USING latin1 )
COLLATE latin1_swedish_ci
LIMIT 0 , 30

Anyway, once i catch up with things i have to do and get some sleep, i'll report back tomorrow with the solutions. It's a right old mix of removing quotes etc. and leaving some in there.

Many, many thanks for all help provided.