asked on

Why does this not work?

Here's the function the way I run it in MSSQL Studio...

select dbo.ufn_ClientPreference( 28 , 'StatementRollUp' )

Here's the way I run it using PDO:

<?php
function test(){
	
global $mssql_pdo;	'

$sql="select dbo.ufn_ClientPreference( 28 , 'StatementRollUp' ) as StatementRollUp";

$query=$mssql_pdo->query($sql);
$row=$query->fetch_object();
	if(!$query)
	{
		echo "nope";
	}
}			

$test_stuff=test();

if($test_stuff)
{
//echo "yes";
}	
?>

<table>
	<tr>
		<td><?php echo $row['StatementRollUp'];?></td>
	</tr>
</table>

Open in new window

No specific errors, just a page that says it can't be displayed.

What's wrong?

Ray Paseur

Stray apostrophe on line 4, maybe? Looks like a PHP parse error to me.

ASKER CERTIFIED SOLUTION

Ray Paseur

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Bruce Gust

ASKER

Nuts! Ray, that was a typo. There is no stray apostrophe, I just slipped when I was copying the code.

Here's the thing: There was another scenario in my last job where, in the context of PDO, if you were interacting with a T-SQL Stored Procedure, you couldn't create a temp table within the procedure. I don't have my notes in front of me, so I'm just trying to remember. But the bottom line was that there appeared to be certain situations where if you were using PDO and calling any T-SQL functions and / or stored procedures, you needed to proceed with caution because within that dynamic you had a breakdown in communication. Does that resonate with you? Have you encountered that situation where you were using PDO to interact with a T-SQL database in a way that incorporated Stored Procedures and / or functions on the server and found that what may run without any problem in MSSQL Studio did not translate in PDO?

Bruce Gust

ASKER

Ray, I'm going to close the question. As always, I appreciate your time. The app I'm working on is using "pconnect." How that differs from a PDO connection and whether or not that would / could make any difference in the way a stored procedure or a function on the server would fire, I don't know. I'm thinking there are other variables at work here that I'm not necessarily aware of and I was able to solve the problem that I was working on, so this is a moot point...for now, anyway.

Thanks again!

Ray Paseur

Here's pconnect() - generic, but still well-explained.
http://php.net/manual/en/function.mssql-pconnect.php

Here's connect() - not persistent.
http://php.net/manual/en/function.mssql-connect.php

Why prefer connect() over pconnect()? If you're using pconnect() and anything goes wrong in another script using the connection that causes any kind of damage to the connection, you may experience intermittent run-time failures that cannot be replicated. Professionals do not like to debug those sorts of things; we prefer ways of working that are stable and predictable, with a minimum of "spooky action at a distance." If you still think there is an advantage to pconnect() consider attaching a script timer to the processes and see if pconnect() saves you any noticeable amount of script time.

Bruce Gust

ASKER

I'm getting to a place where I think some programmers simply default to what they're most familiar with rather than venturing beyond the reservation and use something else that may be more efficient.

In this instance, based on the explanations you've referred as well as some other things I've read, it looks as though pconnect may be the better option, but I'm still suspicious that while PHP and T-SQL can get along, there are some anomalies that represent some "quirks," so even when the PHP code is sound, you don't always get the recordset you expect. Not a dealbreaker necessarily, but something to be sensitive when attempting to troubleshoot some code.

Yes?