Parse error: syntax error, unexpected T_ENCAPSED_AND WHITESPACE, expecting T_STRING

[rhys]

Can you post the code again without quoteing it in PHP tags so I can copy it to my editor otherwise I have numbers down the side.

You guys are the greatest!! I guess I have friends I don't even know.

The problem still exists -- I have found no string issues in my code yet -- and it's not caused by comments only present in my example.

I will post another version of the problem code, without code tags to confuse editors, and most carefully, so as to avoid pesky typos!! This sample will be slightly more complete too.

[code=php]$presult = mysql_query("se lect * from mrb_pipe
where pproj = '$proj'");
while ($pipe = mysql_fetch_ass oc($presult)) {
if ($pipe["pins"] == "N") break;
$tpbidit = $pipe["pbidit"];
$tpsys = $pipe["psys"];
$stresult = mysql_query("se lect * from mrb_stot
where sbidit = '$tpbidit'
and ssys = '$tpsys'");
if (mysql_num_rows <> 1) {
mysql_query("in sert into mrb_stot (sbidit,
ssys, inssf, inslf, imatl, ilab, imhs,
mmatl, mlab, mmhs, sexp, slab, smhs) values
('$tpbidit', '$tpsys', 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)")
or die("subttl no workie");
$stresult = mysql_query("se lect * from mrb_stot
where sbidit = '$tpbidit'
and ssys = '$tpsys'");
$ttlmhs = 0.0;
}
$subt = mysql_fetch_ass oc($stresult);
mysql_free_resu lt($stresult);
getSurf(1, $pipe["psize"], $pipe["pthk"]);
$actstr = $pipe["pstr"];
$strbdsf = $actstr * $psfmlt;
$winssf = $subt["inssf"];[/code]

[Added CODE tags for readability. To view the source code without line numbers, click the 'Reply' button. Thanks! -- pbmods]

At this point -- the last line -- is when I get the T_ENCAPSED_ parse error. It makes it through all the previous code. I'd put more error-checking in, but I've got to clear the parser first!!

Thank you again for your indulgence, and please pardon my occasional absence -- gotta make the donuts. I hope your eyes are sharper than mine!! -- Rhys

[rhys]

Heya, Anthony.

Posting without using CODE tags is not allowed in technical forums. However, if you click the Reply button, you can see the code without line numbers.

Dang it, i provided a tagless sample -- AGAIN -- as requested -- BEFORE i saw this post. Rest assured I reviewed my code closely first, I WON'T do it again, and please forgive this old newbie!! -- Rhys

[pbmods]

Heya, Rhys.

Don't worry about it. This is an unusual case.

You got me stumped. My first impulse is that you missed a quote somewhere before the snippet you posted, except then you should have gotten this error before the last line of your code.

I hate to ask an obvious question, but I just need to make sure. The line number referenced in the error code definitely matches up with the last line that you posted, correct?

[rhys]

Heya, Rhys.

Don't worry about it. This is an unusual case.

You got me stumped. My first impulse is that you missed a quote somewhere before the snippet you posted, except then you should have gotten this error before the last line of your code.

I hate to ask an obvious question, but I just need to make sure. The line number referenced in the error code definitely matches up with the last line that you posted, correct?

I checked that specifically. insert a blank line above it, it moves down. Take that blank line out and insert a blank line below it, it is the same. Were it a later line it would stay the larger value. i have pored over the getSurf function it calls shortly before this, to see if anything amiss there -- not apparently.

It's a Doozie all right!! They'll call it the Rhys Bug. Old school meets Hi Tek. Thx again for your attention!! -- Rhys

[rhys]

Heya, Rhys.

Don't worry about it. This is an unusual case.

You got me stumped. My first impulse is that you missed a quote somewhere before the snippet you posted, except then you should have gotten this error before the last line of your code.

I hate to ask an obvious question, but I just need to make sure. The line number referenced in the error code definitely matches up with the last line that you posted, correct?

I hope i haven't lost your interest. This puzzle continues to vex me. I try to think of alternative approaches, but really need to do it this way, i think.

I guess i don't seek a specific solution to this particular problem, as much as an answer to a more general question: Am i violating any basic tenets or precepts of MySQL by structuring my queries and result sets such that i have? I had hoped to have the result sets of several queries available at any given time, and maybe the problem has to do with my assignment of variables. At any rate, this parse error makes little sense to me, in its specific location.

Another question arises: Does the parser process the source sequentially, or does it parse functions as they are encountered? The reason I ask is, it doesn't complain about a variable returned from a function and previously unreferenced, yet another previous function (Init()) contains math calculations involving subscripted(tab le element) arguments which I thought illegal. If the parser saw these, it should have coughed. This could make a difference in my debugging approach.

I really hope this turns out to be a simple syntax or assignment issue, and not a fundamental flaw in my logic and its feasibility with MySQL. I wait with bated breath, for any solutions or suggestions, if anyone is still interested. In the meantime, I won't quit my night job!!

I thank any and all for their time and attention!! -- Rhys

[pbmods]

Heya, Rhys.

When PHP prepares to execute a script, the first thing it does is run through and parse the script to make sure that there are no syntax errors. This scan is sequential, so if an error is detected, the parser stops and reports the line number. Note that an error's 'location' (within a function, class method, etc.) is unimportant because the parser is merely running through line-by-line to check your syntax.

There are run-time errors that can occur that can not be readily detected via a syntax check, but your script is not getting any of those.

It is important to note that until the syntax error is fixed, your script never gets executed, so you can rule out any MySQL-related problems right now because your script never actually connects to the MySQL database server.

Are you using eval() anywhere in your script? Are you sure that you are looking at the correct file? If you comment out the line that causes the error, what happens?

[rhys]

Heya, Rhys.

When PHP prepares to execute a script, the first thing it does is run through and parse the script to make sure that there are no syntax errors. This scan is sequential, so if an error is detected, the parser stops and reports the line number. Note that an error's 'location' (within a function, class method, etc.) is unimportant because the parser is merely running through line-by-line to check your syntax.

There are run-time errors that can occur that can not be readily detected via a syntax check, but your script is not getting any of those.

It is important to note that until the syntax error is fixed, your script never gets executed, so you can rule out any MySQL-related problems right now because your script never actually connects to the MySQL database server.

Are you using eval() anywhere in your script? Are you sure that you are looking at the correct file? If you comment out the line that causes the error, what happens?

Thanks again for caring!! Here is what I have discovered:

I think my current-result-set suspicions have some merit... I found that when i move all references to the first result set -- $pipe -- to occur before the second -- $subt -- happens, store them in regular variables for later use, then subsequent assignment of subscripted mysql table elements to regular $variables works, as long as it is the current result set. The assignment command which failed worked just fine, in its same syntax, once I moved all references to the previous result set back outside the current query result. Now I'm not sure if my failed math commands and function calls containing subscripted elements failed because it didn't like the subscripts, or it just wasn't the current result set. Maybe the latter, but I have replaced those references with $variables which work, and more research is necessary.

The point is moot, at the moment. I think I have discovered the essence of my woes, and discovered how to deal with it. Thank you for reassuring me it was not a mysql bug, and piquing my curiosity enough to try different approaches. I hope to not pollute this fine forum with my trivia again, but it is reassuring to know it's here. Thanks again for your time and concern!! -- Rhys

[pbmods]

Heya, Rhys.

Glad to hear you got it working! Good luck with your project, and if you ever need anything, post back anytime :)

[rhys]

Thanks again for caring!! Here is what I have discovered:

I think my current-result-set suspicions have some merit... I found that when i move all references to the first result set -- $pipe -- to occur before the second -- $subt -- happens, store them in regular variables for later use, then subsequent assignment of subscripted mysql table elements to regular $variables works, as long as it is the current result set. The assignment command which failed worked just fine, in its same syntax, once I moved all references to the previous result set back outside the current query result. Now I'm not sure if my failed math commands and function calls containing subscripted elements failed because it didn't like the subscripts, or it just wasn't the current result set. Maybe the latter, but I have replaced those references with $variables which work, and more research is necessary.

The point is moot, at the moment. I think I have discovered the essence of my woes, and discovered how to deal with it. Thank you for reassuring me it was not a mysql bug, and piquing my curiosity enough to try different approaches. I hope to not pollute this fine forum with my trivia again, but it is reassuring to know it's here. Thanks again for your time and concern!! -- Rhys

These are my first real forays into PHP and MySQL with my real database -- formerly PostGreSQL, formerly C-ISAM -- after the tests had me convinced I knew what I was doing. Obviously I have some of the nuances yet to learn. And I'm sure the way I nest my queries belies my old-school background.

I have yet to make it through the parser, waited until it grew too large to try. But I'm learning!! And there's lots more of this program to come, but I thought I'd clean this up first. And it doesn't parse yet, though hopefully its remaining issues are well in hand.

Even when it parses, as you point out, that is no guarantee of proper - or desired - execution. I'm just hoping I haven't offended the MySQL gods too much, and that the main "while" loop -- dependent on the first result set -- has not gotten confused by the intervening query/results. "Endless Loop" time? I'll design my future tests to test that theory, but I've got some coding to do first.

In the meantime I'm off to the races, with your help and encouragement. Thank you again and again!! -- Rhys

[rhys]

These are my first real forays into PHP and MySQL with my real database -- formerly PostGreSQL, formerly C-ISAM -- after the tests had me convinced I knew what I was doing. Obviously I have some of the nuances yet to learn. And I'm sure the way I nest my queries belies my old-school background.

I have yet to make it through the parser, waited until it grew too large to try. But I'm learning!! And there's lots more of this program to come, but I thought I'd clean this up first. And it doesn't parse yet, though hopefully its remaining issues are well in hand.

Even when it parses, as you point out, that is no guarantee of proper - or desired - execution. I'm just hoping I haven't offended the MySQL gods too much, and that the main "while" loop -- dependent on the first result set -- has not gotten confused by the intervening query/results. "Endless Loop" time? I'll design my future tests to test that theory, but I've got some coding to do first.

In the meantime I'm off to the races, with your help and encouragement. Thank you again and again!! -- Rhys

Oh yeah -- a confusing aspect of this problem was its manifestation: calls to prior result sets worked, even in a new result set, but then calls to the current result set failed. Only when prior calls to the senior result set were moved outside the current result set, did calls to it work. Interesting, eh?

[rhys]

Oh yeah -- a confusing aspect of this problem was its manifestation: calls to prior result sets worked, even in a new result set, but then calls to the current result set failed. Only when prior calls to the senior result set were moved outside the current result set, did calls to it work. Interesting, eh?

I SPOKE TOO SOON!! The same parse error has returned. I was moving through my source, where virtually ALL of my parse errors were related to mysql query results, and references to them. I found that the parser did not like subscripted arguments or operands in math instructions, function calls, or switch:case commands. In addition, it appeared that only the current result set was reliably available for reference. I got the parser to make it all the way through my main "while" loop, and it was parsing the first function, when I got ANOTHER of those T_ENCAPSED_AND WHITESPACE parse errors, on the last line of the following:

[code=php]
$mresult = mysql_query("se lect * from mrb_matl where
mtable = '$mtbl' and msize = '$isiz'");
$price = mysql_fetch_ass oc($mresult);
mysql_free_resu lt($mresult);
$wmthk1 = $price["mthk1"];
[/code]

My current-result-set explanation fails this time (and I was so smug). All tables, field names, and variables are valid, the nearest string is 2 lines above, and it is definitely that assignment causing that error. The function is properly called, and passed the right number of variables... I'm stumped!!

Again I must voice a concern -- that my old-time logic has revealed a deficiency in the PHP parser, relating to multiple mysql result sets, and I can't do what I need to do!! Not in this fashion, at least. In the current instance, I need to pre-load some regular $variables with mysql table row elements, because the switch:case coming up doesn't like them there!!

Did I do my [code] tags right?

I will be happy to provide any interested parties all the detail they desire. And thank you again for your indulgence!! -- Rhys

[rhys]

I SPOKE TOO SOON!! The same parse error has returned. I was moving through my source, where virtually ALL of my parse errors were related to mysql query results, and references to them. I found that the parser did not like subscripted arguments or operands in math instructions, function calls, or switch:case commands. In addition, it appeared that only the current result set was reliably available for reference. I got the parser to make it all the way through my main "while" loop, and it was parsing the first function, when I got ANOTHER of those T_ENCAPSED_AND WHITESPACE parse errors, on the last line of the following:

$mresult = mysql_query("select * from mrb_matl where
                mtable = '$mtbl' and msize = '$isiz'");
$price = mysql_fetch_assoc($mresult);
mysql_free_result($mresult);
$wmthk1 = $price["mthk1"];

My current-result-set explanation fails this time (and I was so smug). All tables, field names, and variables are valid, the nearest string is 2 lines above, and it is definitely that assignment causing that error. The function is properly called, and passed the right number of variables... I'm stumped!!

Again I must voice a concern -- that my old-time logic has revealed a deficiency in the PHP parser, relating to multiple mysql result sets, and I can't do what I need to do!! Not in this fashion, at least. In the current instance, I need to pre-load some regular $variables with mysql table row elements, because the switch:case coming up doesn't like them there!!

Did I do my [code] tags right?

I will be happy to provide any interested parties all the detail they desire. And thank you again for your indulgence!! -- Rhys

!!False Alarm!! Sort of... I found that if I replaced the [] around subscript names with () it WORKS!! Parses at least... There's one for the manual... but then, how did the previous []'s -- and there were many -- work? And why not now? I'm just a guppy in this ocean, and this is scary!! -- Rhys

[pbmods]

Heya, Rhys.

What version of PHP are you running?

[rhys]

Heya, Rhys.

What version of PHP are you running?

I'm running PHP 5.1.6, mysql Ver 14.12 Distrib 5.0.24a, and Ubuntu 2.6.17-10.34-generic

[pbmods]

Heya, Rhys.

Weird.

I was thinking that maybe PHP thought that $price was a string, and earlier versions of PHP don't allow you to access an index of a string using array-style brackets.

Except that wouldn't generate a parse error, and mysql_fetch_ass oc() never returns a string. And PHP 5 doesn't have the string index syntax problem anyway.

Ah well.