Marthaj
asked on
PHP 7.4.0 and Parsing Error
I am using PHP 7.4.0 and I keep receiving this parsing error.
I can not see what the problem is with the line the parser is complaining about.
It does not like the the first echo statement.
This is the error:
This is the coding:
Thank you in advance
I can not see what the problem is with the line the parser is complaining about.
It does not like the the first echo statement.
This is the error:
This is the coding:
// TEST SQL SEVER CONNECTION
$sname = $_SESSION['servername'];
$testconnect = array('UID'=>$_SESSION['uid'],
'PWD'=>$_SESSION['pwd'],
'Database'=>$_SESSION['DB']);
$testconn = sqlsrv_connect($sname,$testconnect);
if(!$testconn)
{
echo '<BR>CONNECTION TEST FAILED TO SQL SERVER';
echo '<BR>ABORTING APPLICATION AND EXITING' ;
die(print_r(sqlsrv_errors(), true));
sqlsrv_close($testconn);
session_destroy();
EXIT;
}else{
echo '<BR>CONNECTION TEST SUCCEED TO SQL SERVER';
echo '<BR>CONTINUING WITH APPLICATION';
}
// END OF TESTING SQL CONNECTION
Could someone take a look and see what is wrongThank you in advance
Looks like you might have made some edits before posting here, because that code works fine. What does the raw code look like? Maybe the raw code has an extra ' or " somewhere?
As @gr8gonzo mentioned, attach your complete file.
So you'll have an opening <?php on line #1, then you'll have at least 31 lines of code, as error you've posted relates to line #31... and code you posted only contains 26 lines of code...
So you'll have an opening <?php on line #1, then you'll have at least 31 lines of code, as error you've posted relates to line #31... and code you posted only contains 26 lines of code...
ASKER
I apologize for my sloppy posting. I cleaned up the coding and reposted it.
Regardless of the line number, it does the same thing - parse error on the same echo statement
I can not attach the complete file because of sensitive info.
If I comment out, the section testing the SQL connection, the application executes just fine.
But I want to test the SQL connection. I have posted from the top, and a bit more.
I did find one error-where I close the connection - wrong var name.
But the error always occurs at the same echo statement regardless of the line numbering.
Regardless of the line number, it does the same thing - parse error on the same echo statement
I can not attach the complete file because of sensitive info.
If I comment out, the section testing the SQL connection, the application executes just fine.
But I want to test the SQL connection. I have posted from the top, and a bit more.
I did find one error-where I close the connection - wrong var name.
But the error always occurs at the same echo statement regardless of the line numbering.
|
---|
<?php
session_start();
include 'includes/masticsconfig.php';
//AWS
require 'aws-autoloader.php';
use Aws\S3\S3Client;
use Aws\S3\Exception\S3Exception;
// NEXT LINE FOR DEVELOPMENT
//error_reporting(E_ERROR | E_PARSE | E_NOTICE);
error_reporting(E_ALL); ini_set('display_errors', 1);
// TEST SQL SEVER CONNECTION
// DEFINE CONNECTION
$servername = $_SESSION['servername'];
$connectionInfo = array('Database'=>$_SESSION['DB'], 'UID'=>$_SESSION['uid'], 'PWD'=>$_SESSION['pwd']);
$connect = sqlsrv_connect($servername,$connectionInfo);
if(!$connect)
{
echo '<BR>CONNECTION TEST FAILED TO SQL SERVER';
echo '<BR>ABORTING APPLICATION AND EXITING';
die(print_r(sqlsrv_errors(), true));
sqlsrv_close($connect);
session_destroy();
EXIT;
}else{
echo '<BR>CONNECTION TEST SUCCEED TO SQL SERVER';
echo '<BR>CONTINUING WITH APPLICATION';
}
// END OF TESTING SQL CONNECTION
// SET EXECUTION TIME
//ini_set('max_execution_time', 300);
// NEXT LINE FOR PRODUCTION
//error_reporting(E_ERROR | E_PARSE);
AND SO FORTH...
I can not attach the complete file because of sensitive info.This is a common issue. This is going to take a little work on your part, but will make it easier to troubleshoot. Create a complete, short test case using only enough code to demonstrate the issue and it should create the similar error in your larger code, but pointing to the exact line number in your test case.
I find sometimes just setting up my question with a test case often answers my own problem. More importantly, it makes it easier for others to help.
With PHP, it is easy to get an error and you think it is on that line, but it is really from somewhere else. Common is forgetting to add a semi-colon at the end of a line which presents an error on the next line.
You can be mostly confident that examples on php.net will work. Start out with copy and paste https://www.php.net/manual/en/function.sqlsrv-connect.php
I would also suggest sticking with the pdo. For one thing you can easily switch out your MSSQL database with MySQL probably with minimal changes if any.
Note that 'die' and 'exit' are identical functions that stop the execution at that point. In addition, EXIT should be "exit();" because it is a function.
I think this line
I think this line
die(print_r(sqlsrv_errors(), true));
is the wrong syntax. See https://www.php.net/manual/en/function.exit.php and https://www.php.net/manual/en/function.print-r.php . Adding 'true' causes it to return a value, not print it.
ASKER
Thank you all for responding.
I have it fixed - there must have been some invisible character in the echo statement that kept causing the parsing error.
The reason I think that is because I copied the echo statement after the else - changed it to the correct verbiage for if it fails.
And the parsing error disappeared and all is well. Just strange.
Yep, die and kill - one or the other but don't need both. Good catch.
And as I understand it, the exit statement can be constructed several way, i.e. exit(); exit; and so forth.
And yes, David, you are correct, it is actually a function. Good to know. Thank you. I didn't realize I could throw out a statement with it as it exited. Cool !
And I probably don't need the close either - you can't close what isn't open or connected - right !..
I often do little scripts to testing coding before integrating them into the main application.
Easier. And that is what I had done this time except something went screwy when copying and pasting.
I have a big folder with little scripts that I have used and may again the future.
And yep, working on a second version of this application using PDO calls, which I am new to constructing the PDO syntax.
It's a work-in-progress.
Again, thank all of you for responding and being so patience .
I have it fixed - there must have been some invisible character in the echo statement that kept causing the parsing error.
The reason I think that is because I copied the echo statement after the else - changed it to the correct verbiage for if it fails.
And the parsing error disappeared and all is well. Just strange.
Yep, die and kill - one or the other but don't need both. Good catch.
And as I understand it, the exit statement can be constructed several way, i.e. exit(); exit; and so forth.
And yes, David, you are correct, it is actually a function. Good to know. Thank you. I didn't realize I could throw out a statement with it as it exited. Cool !
And I probably don't need the close either - you can't close what isn't open or connected - right !..
I often do little scripts to testing coding before integrating them into the main application.
Easier. And that is what I had done this time except something went screwy when copying and pasting.
I have a big folder with little scripts that I have used and may again the future.
And yep, working on a second version of this application using PDO calls, which I am new to constructing the PDO syntax.
It's a work-in-progress.
Again, thank all of you for responding and being so patience .
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ah yes... the evil invisible characters...
Good catch.
In the future, you can find these by using this command.
1) vi $file
2) Type ":set list" <CR>
3) All invisible characters will be shown.
Glad you got this working!
Good catch.
In the future, you can find these by using this command.
1) vi $file
2) Type ":set list" <CR>
3) All invisible characters will be shown.
Glad you got this working!
@Dave
Syntax on the print_r is correct.
die() takes a string argument - terminates and displays the string
print_r() outputs directly to the output stream unless the second parameter is true in which case it returns a string.
When using the result of a print_r in die() you need to return it as a string same as
Syntax on the print_r is correct.
die() takes a string argument - terminates and displays the string
print_r() outputs directly to the output stream unless the second parameter is true in which case it returns a string.
When using the result of a print_r in die() you need to return it as a string same as
$result = print_r($value, true);
die($result);
@Julian, Ok. But nothing after the 'die' line above will be executed. ??
But nothing after the 'die' line above will be executed. ??
Correct - die - kills any further execution - so the incorrect EXIT and destroying the session and closing the query are in the void.
ASKER
Thank you Julian and David. The explanations are good as is the help. And I have to laugh at myself, it's the only spot in my application that I did such a thing - all the rest just have die....:}
I removed the unneeded extra commands -
I removed the unneeded extra commands -
sqlsrv_close($connect);
session_destroy();
EXIT;
You're welcome!
Glad you're making progress!
Glad you're making progress!