I have a php script running on linux which queries a MSSQL Server Express database running on my dev machine (windows) using the php mssql driver.
I'm able to connect and select a database, and get no errors.
I put the query directly into a query window in MS SQL Server Management Studio and I get the correct data back. However, if I run the same query from my PHP script, the data that comes back has a bunch of "replacement characters", described here: http://www.fileformat.info/info/unicode/char/0fffd/index.htm
It looks like this: �
For instance, when querying for a list of IDs, eg "SELECT DISTINCT PageId FROM Pages", the query window is showing a list of IDs in the following format:
C961277D-D8BE-4337-82CF-003F6E7951E2
However, when I run the same query in PHP, this is the result:
'���K�#�t��#/
I AM getting the same number of results, so the SQL Server seams to be interpreting the query correctly, but in the results, the character length is wrong, none of the characters match, and the format is wrong. Anybody have any idea what is going on?
Thank you for your help.
Relevant code here:
$this->connection = mssql_connect(
$this->configuration['servername'],
$this->configuration['username'],
$this->configuration['password']);
$query = 'SELECT DISTINCT PageId FROM sf_CmsCtrlLinks';
$result = mssql_query($query);
while ($row = mssql_fetch_object($result)){
// Results in "page ID: 7��"�O�5,���"
echo "page ID: " . $row->PageId;
}
SQL Server returns GUIDs to PHP in binary format.
If you want it as a readable format, you can just make MSSQL pass it back to you as a string;
SELECT DISTINCT CONVERT(VARCHAR(38), PageId) as PageId FROM pages
If you don't need them readable, not casting them and just using them as an "opaque" id should work without problems.
I can't test it myself, but mssql_guid_string() may also work to convert them to readable form.
Related
I found a couple of results similar to what I'm about to ask but unfortunately none of them provided a solution or direction to the problem I'm facing.
I'm reviewing a large SQL Server 2008 database and I'm running some blanket queries such as running a SELECT TOP(5) on every table to get an idea of the contents.
I've encountered some Binary(16) objects in the results in PHP and of course PHP isn't able to print a readable version of the id easily. I don't have the option of adding the MSSQL extension to make use of the mssql_guid_string function and I can't perform the convert in SQL as the select needs to be as generic as possible to work for every table. I'm doing a foreach on a list of tables to return the data and print it.
So my question is: Does anyone know of an alternative to mssql_guid_string in PHP??
The pseudo of what I'm trying to do would be;
1. SELECT TOP(5) * FROM table1
2. WHILE $row = sqlsrv_fetch_array{...
3. foreach $row as $col print $col
The id's in SQL look something like this -> 0xB0826E8A84CA6C418254E28BC0F749CF
When printed in PHP they look like this -> X÷Eòv˜H½XšÔÛé«Ù
Any help/thoughts would be greatly appreciated.
Steve
From the PHP side you can dump to hexadecimal and add a prefix:
echo '0x' . strtoupper(bin2hex($col));
From SQL Server you can probably cast to string (no idea about that).
EDIT
Problem Solved: I had removed a line in my PL/SQL procedure by mistake at some point, enable DBMS output, so it could not send the PHP anything. When testing it in SQL developer I have to connect to my network and the code I use to do that enables DBMS output, so that is why it worked in SQL_Developer and not in PHP.
I feel very silly now that is has come down to a deleted line of code by mistake.
I will leave query below in case anyone has anything similar
Smashing my head against a table trying to work out why this doesn't work.
This is connecting to an Oracle database using PHP, creating code in SQL_Developer.
I created a PL/SQL procedure that would take two integers as start and end nodes and spit out some directions, which worked fine and dandy in SQL_Developer and through PHP. The select statement in my PHP was this and returned what I needed.
$get_instruc = "Select * FROM TABLE(Navi_Instructions.Get_Navi_Instructions(:start_node,:end_node))";
(Integers are binded in using oci_bind_by_name).
I now have a requirement for the integers to be strings, so I have re-written the PL/SQL procedure to accommodate this. My new procedure works perfectly, and when I use the following select statement in SQL_Developer it retrieves the correct data
Select * FROM TABLE(Navi_Instructions_Final.Get_Navi_Instructions_Final('Room_101','Room_120'));
My next step was to simply put this select statement into PHP, but the PHP select statement refuses to return any values. I just get back "0 rows selected".
$get_instruc = "Select * FROM TABLE(Navi_Instructions_Final.Get_Navi_Instructions_Final(:start_node_final,:end_node_final))";
(Strings are binded in using oci_bind_by_name).
I really do not understand how it is not working, the select statement works in SQL_Developer, so its not the PL/SQL procedure or the statement. The values initially had spaces which I have replaced with underscores and that hasn't helped. I have used ' ' and " " around the strings. I have tried removing the bindings and just using plain strings like
$get_instruc = "Select * FROM TABLE(Navi_Instructions_Final.Get_Navi_Instructions_Final('Room_101','Room_120'))"
Am I missing something basic like Oracle cannot receive strings/varchars through PHP?? Any help would be greatly appreciated.
Anyone ran into this one before?
I have a Stored Procedure in SQL with the following Parameters :
exec PaySummary 'DemoTest', 'DemoTest-Mohn-00038', '5/14/12', '5/27/12', 'manager', 'DemoTest-Boyd-00005'
And the following MSSQL Query in PHP running the exact same query.
private function dataTest(){
$strSQL = 'exec PaySummary \'DemoTest\', \'DemoTest-Mohn-00038\', \'5/14/12\', \'5/27/12\', \'manager\', \'DemoTest-Boyd-00005\'';
$a = mssql_query($strSQL);
echo $strSQL;
while($row=mssql_fetch_array($a)){
var_dump($row);
}
}
When run in SQL for this query I will get 3 results...
When run in PHP through SQL I get 2 Results...
Is there any run time settings (Set NoCOUNT on) that you must set on a SQL Stored Procedure to ensure accuracy of the output of results? Or is there a known issue with passing date parameters that would impact the results of a date driven stored procedure?
Microsoft-IIS/5.0 / PHP/5.2.5 / SQL Server 2008 R2 (Where the stored procedure is executed).
For anyone in this same situation... It is caused by the NULL_CONCAT_NULL (or whatever) option in SQL. This one flag can make a stored procedure run a little bit differently depending on how you use concat etc. A good way to solve this problem is via an ISNULL around a lot of your items which seemed to get rid of the issue of getting different results.
Further another option if you do not want to fix your sprocs is to check the path that sql is going through (TCP/IP etc). I noticed when watching the audits that some settings were wildly different depending on the port that sql was running through.
I have a single MySQL query created from PHP 5. The Query has 3 SELECT and 2 JOIN clauses. It accesses two databases on a single host using one connection and db1.table1 db2.table2 techniques. I echo the query before running. In PHP the query returns no result and does not error. When I copy and paste the echoed query into SQL in PHPMyAdmin, it returns the correct result.
Why is PHP different to the SQL part of PHPMyAdmin and does anyone have any suggestions about getting it to work in PHP?
Why is PHP different to the SQL part of PHPMyAdmin
It's not.
You're connecting to the wrong database, writing the wrong query, or checking for errors incorrectly.
I come across this sql code in a php software.
What does the #section_filter mean?
Is that a valid mysql syntax? or just a templating system?
$filterid = ac_sql_select_one("
SELECT
id
FROM
#section_filter
WHERE
userid = '$ary[userid]'
AND
sectionid = 'article'
AND
conds = '$conds_esc'
");
Thanks
It is a valid sql syntax but the problem i suspect is that hash # character creates comments in sql queries hence this query might not execute.
Another possiblity is that the program that you saw this query in should be able to dynamically replace the #section_filter with some table name before it gets to mysql engine and then the query should run fine. This is the highest possibility in my view.
The # symbol is one way to express a comment in MySQL. So, this isn't a valid SQL statement as written, since the line:
#section_filter
would be completely ignored.