I am currently connecting sucessfully to an SQL database sat on a Windows 2008 using the following query;
$result = mssql_query("EXEC dbo.stored_procedure_name #param_level = 2");
I am basing my queries on existing code written in VB / ADO which looks like;
If level = "" Then level = 1
cmdTT.ActiveConnection = connStrTest1
set objParam=cmdTT.CreateParameter("#param_level", adInteger, adParamInput, 4, level)
cmdTT.Parameters.Append objParam
set rsTT = cmdTT.Execute
So what I attempted was the following;
$f = 2;
$stmt = mssql_init('dbo.stored_procedure_name', $mssql_link);
mssql_bind($stmt, "#param_level", $f, SQLINT4, false);
mssql_execute($stmt);
But no matter what the variation it always seems to print the print the screen the warning, "Warning: mssql_execute() [function.mssql-execute]: stored procedure execution failed in ...".
Whats the best way for me to debug the issue here? Can anyone see a clear fix to my problem?
I'm currently connecting remotely to the database from a LAMP stack.
Many Thanks
Ian
Is this from a linux server using FreeTDS? If so, I wonder if this is related to TDS Version. Try tds version = 8.0 in you /etc/freetds.conf
Run the contents of the stored procedure from w/in a sql editor with the parameters hard coded in. You'll get more verbose error messages that way.
I know it's an old post but am sure it will help someone.
You have to add mssql_free_statement($stmt) after executing.
Related
I would like the version of a web server (Nginx, MySQL, MariaDB, ...) in PHP.
I know the function for Apache: apache_get_version().
There are many phpinfo() which returns all values but how to exploit?
You would have an idea or it is not possible for the moment?
A simple shell_exec would do the trick (assuming you're on a unix based server). Just don't put any user data into the command, and be aware that this approach may not work in shared hosting environments:
$nginxVersion = shell_exec('nginx -v 2>&1');
$mysqlVersion = shell_exec('mysql --version');
Note that nginx sends version output to stderr, so you need to pipe it to stdout to capture it.
You can retrieve the web server's version by using the $_SERVER superglobal, more specifically by using:
$_SERVER['SERVER_SIGNATURE']
As per PHPs Documentation:
SERVER_SIGNATURE
String containing the server version and virtual host name which are added to server-generated pages, if enabled.
You can find more info on the official PHP Documentation site:
http://php.net/manual/en/reserved.variables.server.php
To query the version of MySQL and/or MariaDB in PHP, you could use mysqli_get_server_info() or (if you are on still using the deprecated older mysql API) mysql_get_server_info(). The PDO API has no similar function or class for that purpose, but in that case you could just use the result of the SQL query
SELECT VERSION();
It returns something like 5.5.50-0+deb7u2. Here's a quick example:
<?php
$user = 'username_here';
$pass = 'your_db_password';
// create DB connection
$dbh = new PDO('mysql:host=localhost;dbname=mysql', $user, $pass);
$stmt = $dbh->query('SELECT VERSION();');
//fetch first column of first result row and print it out
echo $stmt->fetchColumn();
//unset PDOStatement and PDO to close DB connection
unset($stmt);
unset($dbh);
?>
Address the $_SERVER super-global http://php.net/manual/en/reserved.variables.server.php
I believe the setting you want is:
echo $_SERVER['SERVER_NAME'];
The other answers mention different methods on how to get the web server and database versions, however there is a function which will get the operating system itself.
// Gets the "System" row shown at the top of the `phpinfo()` table.
$system = php_uname( $mode = 'a' );
You can specify the mode to select different components. By default it'll display all of the components, separated by spaces and in the following order:
s: Operating System Name
n: Host name
r: Release Name
v: Version Information
m: Machine Type
You can view more information about the php_uname function here.
I found SQL Dump Task from here http://bakery.cakephp.org/articles/carcus88/2011/04/08/sql_dump_task_for_shells
I use in shell.
I already declared
$tasks = array('SqlDump')
And, I put in these code in the last line of main()
pr($this->SqlDump->dump_array());
But no sql print out. If anyone know how to use, please tell me.
the shell is usually limited in the size of the output (some of it may be cut off in case of too much printout).
therefore I would go with a log solution.
check my component approach:
https://github.com/dereuromark/tools/blob/2.0/Controller/Component/CommonComponent.php#L601
it might be re-writable for a shell environment.
basically get the sql log and write it to a file:
$log = $object->getDataSource()->getLog(false, false);
CakeLog::write('sql', $log);
of course you could still print it out on the screen, as well.
Hey, I am struggling a bit to determine the exact cause of an error that has been popping up in our release environment. There does not seem to be much dealing with this particular error on Google.
This is the error message we are getting:
SQLSTATE[34000]: Invalid cursor name:
7 ERROR: portal "" does not exist
The error only pops up when we are using PDO prepared statements.
This is the setup for our release environment:
pgpool 3.0.1 (The postgresql backend is in Streaming Replication mode!)
PHP 5.3.5
PostgreSQL 9.0
Edit: Architecture is 64bit.
The same error does not manifest in our test environment (Edit: forgot to mention, the standard test environment uses Postgresql 9.0 without pgpool). Thus, I am led to suspect that pgpool is at least partly suspect.
Does anyone know what the probable causes for this error are?
Edit: ok, here is an example of the kind of code that causes the error.
$sql = 'SELECT * ';
$sql .= 'FROM "myTable" as "myStuff" ';
$sql .= 'WHERE "myTable"."status" = 1 ';
$sql .= 'AND "myTable"."myTableId" = :tableId ';
$sth = $this->_db->prepare($sql);
$sth->bindParam(':tableId', $tableId, PDO::PARAM_INT);
$sth->execute();
Edit: Some log file output;
Postgresql:
postgresql-Sun.log-129- ORDER BY "id"
postgresql-Sun.log:130:ERROR: portal "" does not exist
postgresql-Sun.log-131-ERROR: prepared statement "pdo_stmt_00000011" does not exist
postgresql-Sun.log-132-STATEMENT: DEALLOCATE pdo_stmt_00000011
postgresql-Mon.log-82- where "id" = 32024
postgresql-Mon.log:83:ERROR: portal "" does not exist
postgresql-Mon.log-84-ERROR: prepared statement "pdo_stmt_00000002" does not exist
postgresql-Mon.log-85-STATEMENT: DEALLOCATE pdo_stmt_00000002
pgpool:
LOG: pid 22071: Replication of node:1 is behind 2080 bytes from the primary server (node:0)
LOG: pid 22071: Replication of node:2 is behind 2080 bytes from the primary server (node:0)
LOG: pid 13499: pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 8470 statement: message: portal "" does not exist
LOG: pid 13499: pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 8470 statement: DEALLOCATE pdo_stmt_00000003 message: prepared statement "pdo_stmt_00000003" does not exist
I've found a solution. Turns out this bug we are experiencing does not exists in Pgpool-II 3.1 alpha2. It looks like this bug was fixed in March after the 3.0.3 release. The solution is to download the release and build/install manually. Some of the paths are different, for instance the config path is /usr/local/etc/
Pgpool-II 3.1 alpha2 is available here:
http://pgfoundry.org/frs/?group_id=1000055
It's possible that the latest 3.0-Stable tree also has a fix for this issue. I am hoping to test an export from the CVS later tonight.
If you could duplicate the problem in your test environment, I wouldn't hesitate to recommend running the server with the -d (debug) option.
Since that's not the case, I'll just remind you that it's an option.
PostgreSQL command line options
On that page, there are a couple of "Semi-internal Options" that might help isolate the problem. Might not.
I believe I have a temporary work around, and am invested in finding a permanent solution. I am working on a high-availability PG cluster on Amazon EC2, and have also ran into this exact issue.
It occurs randomly for queries executed using DBI's prepare/execute blocks when DBI is routed through PGPool2 (3.0.3). The portal errors do not occur when PGPool2 is removed and we use Postgres 9 directly.
We run Perl, using DBI and DBD::PG. The common factor seems to be PGPool2.
One possible solution we have found is to set 'ignore_leading_white_space' = false in the pgpool.conf. The errors completely disappear for us with this option set. Unfortunately this does have the downside of potentially routing selects to the master that should be load balanced, as such I do not consider it a final solution.
Example of code that randomly generates this issue:
$sth = $dbh->prepare("SELECT * FROM TABLEX WHERE ID = ?" )
|| die "Can't prepare statement: " . $dbh->errstr;
$sth->execute($self->id) || die "Can't get inventory " . $dbh->errstr;
I have some complex code. Complex, but it was working.
The I wanted to add some new code, realized that something needed to become a function and then went on a refactoring rampage. Now my code no longer works.
So I did a bit of file compare, some code reading and debugging, and convinced myself that my changes hadn't broken anything.
To test this theory, I put together an exceedingly simple test program:
<?php
$connection = odbc_connect("Driver={MySQL ODBC 5.1 Driver};Server=localhost;Database=mysql;Option=3;", "root", "");
var_dump($connection);
echo '<br>';
$result = #odbc_exec($connection, 'show version()');
var_dump($result);
?>
which resulted in
resource(2) of type (odbc link)
bool(false)
The strange thing is that the odbc_connect() succeeds, but the simplest MySql command I can think of fails.
Btw, I have tested at the command line & the MySql server is up & running (Xampp) and reports v 5.1.41.
Obviously I am overlooking something very basic, but what?
This is the simplest MYSQL query I can think of:
select 1
This should help you determine if your connection is working or if the problem lies elsewhere.
Maybe the odbc driver "wants" to tell you something about what is causing the error...
$result = #odbc_exec($connection, 'show version()');
if ( !$result ) {
printf("error: %d %s", odbc_error($connection), odbc_errormsg($connection));
}
else {
echo "ok";
}
see http://docs.php.net/odbc_error and http://docs.php.net/odbc_errormsg
I'm trying to connect to an Oracle DB which is currently offline. When it's online it's not a problem, however, now that it's offline my program is getting hung up on the $connection = oci_connect() line and timing out. How do I simply check the connectio and bail out if it's not there?
Try this (fill in your ip and port):
if ( #fsockopen($db_ip,$db_port ) ) {
//connect to database
} else {
// didn't work
}
This gives you both a manual error, plus will return the actual error.
$connection = oci_connect() or die("Critical Error: Could not connect to database.\n\n". oci_error());
Make sure to test this as hopefully the Oracle error doesn't do something stupid like return the connection string (with your DB password) but I wouldn't assume until you see for yourself.
You could select null from dual.
OK, now I see what your asking, I think.
You want to know how to tell if a database is up before you connect to it?
You can use TNSPING to see if a database is up... ok, maybe that's not 100% accurate but it's a good indicator. go to a command prompt and type TNSPING and hit enter. So then you have to figure out how to call a command line tool from PHP.
Here is what I do in ASP.NET
Dim OracleConn As New OracleConnection(YOUR CONNECTION STRING HERE)
Try
OracleConn.Open()
OracleConn.Close()
Catch ex As Exception
Session("ErrorMessage") = "OracleConn: " & ex.Message
Response.Redirect("AccessDenied.aspx")
End Try
It doesnt necessarily say the DB is offline, but an exception will occur if the connection cannot be opened