(PHP 4, PHP 5)
sybase_query — Sends a Sybase query
sybase_query() sends a query to the currently active database on the server that's associated with the specified link identifier.
If the link identifier isn't specified, the last opened link is assumed. If no link is open, the function tries to establish a link as if sybase_connect() was called, and use it.
Returns a positive Sybase result identifier on success, FALSE on error, or TRUE if the query was successful but didn't return any columns.
I am using PHP 4.1.1 to connect to an older version of Sybase that doesn't work with CT. I found that while attempting to execute an erroneous query, sybase_query() never returns false for non-select query statements. This was reported as a bug but then dismissed because the problem is that Sybase itself does not indicate any error to PHP.
However I appear to have found a workaround: after each query statement, call sybase_get_last_message(). If that function returns you anything, it will be an error message. Then you know your non-select query has truly failed.
To use this function to execute stored procedures by parameters like this:
sybase_query("exec p_name '$para1','$para2'",$conn)
$para1 and $para2 are strings.
it works well.
Strange problem... I'm accessing a SQL SERVER 2000 database through freetds with php v4.0.1pl2 on linux.
Thoses instructions work fine :
// Just a test
sybase_query("SELECT MES_ID FROM T_MESSAGE", $dbproc);
// data i want to retrieve, stored procedure
$resConfig = sybase_query("exec P_SLC_EMAILCONFIG", $dbproc);
$arrConfig = sybase_fetch_array($resConfig);
But, when i replace the SELECT statement by an UPDATE statement, i.e:
// Here's the update
sybase_query("UPDATE T_MESSAGE SET MES_STATE = 0", $dbproc);
// data i want to retrieve, stored procedure
$resConfig = sybase_query("exec P_SLC_EMAILCONFIG", $dbproc);
$arrConfig = sybase_fetch_array($resConfig);
Then i've got an error : "Supplied argument is not a valide Sybase result resource.." on the line containing the sybase_fetch_array command.
I don't understand why... I have to close and reopen the connection if i want those lines to work!!!
sybase_query stores the whole result set in memory before returning. This function is unusable for real large result sets, ie. dumping a large table from sybase to php.
This is true for stored procedures' execution results, too. If you have a result set and a status returned, you will only be able to access the result set. Argh.
This function can be used to call stored procedures, or to process multiple queries in the same call in the same "batch". However there's a limit on the kind of stored procedures you can call, because Sybase allows a stored procedure or "batch" to return multiple result sets, and because the surrent implementation of sybase support in PHP3 has no provision to process each result set, one after one. If your stored procedure or batch has multiple result sets returned, you will only be able to retrieved the first result set in you PHP3 script. Note that other result sets won't be processed by the SQL server until you close the current result set. So this may suspend the execution of a stored procedure or batch on the SQL Server. Note also that if a stored procedure or batch uses "print" or "raiserror" SQL statements, you won't be able to collect the returned messages in the result set, because these statements do not generate a result set but instead return asynchronous server messages which currently have no support in the sybase PHP3 set of functions.
It would be a good idea for someone to add the support for queries that return multiple result sets and server messages, so that any kind of Sybase SQL queries can be used in PHP3 scripts.
This would require adding a function to go to the next results set, and a function to retrieve server messages generated before, between, and after each result sets. Note also that server messages could be sent within a result set, this won't be from "print" or "raiserror" SQL statements but internal server errors while processing a result set returned by a SELECT statement, or messages generated by triggers. There could also exist asynchronous client messages while processing any kind of return (result set or server messages), and there's for now no function to return them. Such client messages mainly signal connection status and data conversion errors.