Derick Rethans has posted a new article in his series highlighting some of the changes in the latest release of Xdebug (v2.3). In this new post he talks about some of the improvements in the trace file functionality.

Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit). Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting.

This new setting allows much more information to be reported back in the trace results, adding on a serialized version of the value of variables. He also shows the output results (human-readable) that shows the memory usage and time index for the execution. He also shows the new handling to include return values in the trace output using the "xdebug.trace_format" handling.

Kevin Schroeder has a new post to his blog today on how to correctly evaluate the Zend Server product from Zend (disclaimer: he is a Zend employee).

As you all probably know, Zend has salespeople. Those sales people have sales engineers who show how to use our products. However, I personally hate being on the phone for a canned presentation when all I really want to do is tinker. So, in an effort to produce something of benefit today I decided to start a series of blog posts on how to evaluate Zend Server if you are a tinkerer, like me.

He gives a list of some of the features that the product comes with, but will only really focus on three of them in his series - application monitoring, code tracing and the Zend Server job queue (because he thinks they're the best of the crop). This post is just an introduction to the product and an overview of what it offers - expect more detail to come in future posts.

In his continuing series looking at using the SQL Server driver in PHP applications, Brian Swan has posted a new tutorial looking at enabling ODBC tracing in your SQL Server-driven PHP application.

The short story [of the backup issue] is that a query I was executing from PHP seemed to execute successfully (no errors were returned), but the results of the query were not what I expected. When I executed the same query from SQL Server Management Studio (SSMS), the query executed successfully and I got the results I expected. What was going on?

To try to figure out what was going on he needed to get down to the SNAC/ODBC level and trace the process as it went through. By enabling the "TraceOn" and "TraceFile" parameters in the connection's options, you can get a wealth of information returned along with the normal data. He includes some of the trace information to give you an idea of what he was looking at to solve his problem. In the end, the tracing helped him see more what was working than not and discovered a possible bug in the ODBC drivers that could be causing it to hang in a "restoring" state on the "RESTORE DATABASE" call.