Transparency in the Design Process

re: Transparency in the Design Process

xianve — Mon, 15 Oct 2007 23:19:12 GMT

I have been waiting a long time for this driver.

I am a little disappointed that it is not available for linux, but I guess MS is just protecting it's market. And from what I read IIS7 is much better these days anyway.

I thing I would recommend is to have a survey to see what features users need. One of mine that I have really wanted is better error reporting. Current SQL drivers only give the last error msg, and i would like to see all the error msg that you get in the console being returned to the client (in this case PHP).

Really looking forward to this project evolving. Keep up the good work.

re: Transparency in the Design Process

vbouret — Tue, 16 Oct 2007 20:34:11 GMT

Nice move from Microsoft! The old php_mssql.dll is absolutely painful to deploy and SQL Server 2005 support is almost inexistant. It works, but you never know when it's going to break.

However, I have one major concern. I believe a lot of people did their SQL Server access from PHP thru php_mssql which offers some nice API bits that are used extensively in the PHP community the most important being mssql_num_rows which returns the number of rows returned from a SELECT statement. I don't see any function like this in the API of your new extension.

I have heard a lot about the fact for many database communication protocols you cannot determine in advance the size of a result set, but since most PHP developers rely on this function (also because the very popular php_mysql and php_mysqli have this function built-in) I believe it should be included in your driver.

The overhead of rewriting an application to change the reliance on mssql_num_rows for something else, like two different SQL statements (one SELECT COUNT() and one normal SELECT) and the difficulty of writing cross-platform database SQL that implies COUNT should justify that you add such function.

We did transitioned our application from MySQL to SQL Server recently and one of the main incentive was that the API between php_mysql and php_mssql was about the same and in two hours we were able to write a parallel DB abstraction layer supporting SQL Server.

re: Transparency in the Design Process

Wanou — Wed, 24 Oct 2007 12:10:15 GMT

to vbouret:

You should test and read (RTFM...) before asking something 8-)) .

sqlsrv_stmt_rows_affected($stmt)

gives the nomber of rows affected by the last statement. Which can be a select, insert, update and so on.... Tested and it works !

I'm currently writing a little wrapper from php_mssql to to the new CTP.

By the Way, i found a annoying bug:

On SQL2005, we have a table called Document_lie with 2 fields : doc_type (varchar(50)) and doc_Document (text).

Another application is putting base64 encoded text in doc_document.

This code works:

$sql=" Select Top 1 DOC_Type,DOC_Document from Document_lie

where Doc_Compteur =7418;

$stmt=sqlsrv_conn_execute($conn,$sql);

if ($stmt) {

sqlsrv_stmt_fetch( $stmt );

$typedocu=sqlsrv_stmt_get_field($stmt,1);

$photostream=sqlsrv_stmt_get_field($stmt,2,SQLSRV_PHPTYPE_STREAM);

$photocod='';

while (!feof($photostream))

{

$photocod.=fread($photostream,8192);

}

$photobin=base64_decode($photocod);

header("Content-type:image/jpeg");

echo $photobin;

}

While this one doesn't:

$sql=" Select Top 1DOC_Type,DOC_Document from Document_lie

where Doc_Compteur =7418;

$stmt=sqlsrv_conn_execute($conn,$sql);

if ($stmt){

while ($result=sqlsrv_stmt_fetch_array($stmt, SQLSRV_FETCH_TYPE_ASSOC)){

$photocod=$result['DOC_Document'];

$photobin=base64_decode($result['DOC_Document']);

$typedocu=$result['DOC_Type'];

}

header("Content-type:image/jpeg");

echo $photobin;

}

In fact, if you look at $photocod, you see the problem easily: $photocod gets the good length (in my case 80734 bytes), but only the first 65535 bytes are correct. The rest is filled with garbage. Looks like a pointer problem.

Anyway, keep up the good work !

re: Transparency in the Design Process

Brian Swan — Thu, 25 Oct 2007 00:58:19 GMT

@xainve

Thanks for your feedback. Can you clarify what you mean by "all error messages"? Currently, sqlsrv_errors() and sqlsrv_warnings() return *all* errors and warnings that occured on the last operation. Using print_r would be a good way to see the structure of what is returned by each of these functions. For example, you could try this:

die( print_r( sqlsrv_errors( ), true ) );

If this isn't what you are looking for regarding errors sent to the client, please let us know.

Brian Swan

Programming Writer

SQL Server Driver for PHP

re: Transparency in the Design Process

Brian Swan — Thu, 25 Oct 2007 01:05:51 GMT

@vbouret

This is great feedback...thanks. We will definitely be looking into the specific issue you raise (returning the number of results from a SELECT) in the near future. Of course, we are also interested in the more general ease-of-portablility issue and will re-visit it as development continues.

Thanks again...please keep your thoughts/comments/feedback coming.

Brian Swan

Programming Writer

SQL Server Driver for PHP

re: Transparency in the Design Process

Brian Swan — Thu, 25 Oct 2007 01:12:02 GMT

@Wanou

You've hit on a limitation that was imposed in order to get an API into your hands quickly. Jay, a member of our team, responded to your question in the SQL Server Data Access forum: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2313619&SiteID=1

I'll follow up with a blog post soon that highlights how the current streaming capabilities can be used to overcome this limitation.

Thanks for your feedback.

Brian Swan

Programming Writer

SQL Server Driver for PHP

re: Transparency in the Design Process

Wanou — Thu, 25 Oct 2007 14:33:59 GMT

Oooops !

$sql='Select Top 10 DOC_Type, Doc_Document from Document_lie';

$stmt=sqlsrv_conn_execute($conn,$sql);

echo 'Rows: '.sqlsrv_stmt_rows_affected($stmt).'<br/>';

while ($result=sqlsrv_stmt_fetch_array($stmt, SQLSRV_FETCH_TYPE_ASSOC)){ }

echo 'Rows: '.sqlsrv_stmt_rows_affected($stmt).'<br/>';

Gives:

Rows: -1

Rows: 10

Sorry vbouret.... It doesn't work as I thought it was !

re: Transparency in the Design Process

xianve — Fri, 26 Oct 2007 23:09:22 GMT

Previous mssql driver only returned the last error msg.

eg. mssql_get_last_message()

And in an environment where you call one SP, which calls another, all with transactions, if the inner most fails, there is several error msgs, allowing one to traceback to where the problem is.

Glad to see that this driver accounts for this. (Will test and see)

re: Transparency in the Design Process

JanBlaha — Thu, 15 Nov 2007 11:52:16 GMT

It's good to see at least something happening. But what I would really appreciate is the PDO extension for sqlsrv. Standalone php database driver goes against the current trend in php development.

re: Transparency in the Design Process

James.Easterling — Fri, 30 Nov 2007 18:27:45 GMT

I think that the drivers are great, but lack in a object/class approach like mysqli. Is there any plans to allow both styles? Also, I think it would great if there was a way to pass in the Database to use... so as to not require a second call to execute the "Use Database" query before the actual query. If use database functionality is there I did not see it. Great job overall!

re: Transparency in the Design Process

travis_pdx — Sat, 29 Dec 2007 01:12:03 GMT

I am thrilled that this is coming out... I've been stuck in that awkward middle ground of PHP/MSSQL for years, and having a true native driver sounds awesome.

But I just tested it, and unless I am missing something, there is no Unicode support... without which this is a complete non-starter for me at least. Is there a hidden config switch or something? Or plans to support Unicode in the full release?

Cheers,

--Travis

re: Transparency in the Design Process

CMaz — Sat, 29 Dec 2007 01:27:07 GMT

I am an old sql server user

I try to use a lot of php software and they came all with Mysql support

I was very happy to get this release ....

I look after store procedure support and i didn't find anything about it.

Have i miss something ou there is nothing at this time ?

Is there somethong planned for the next 3 months ?

Thanks for your feedback

Best regards from France

re: Transparency in the Design Process

W1lz0r — Thu, 03 Jan 2008 03:26:25 GMT

I am very happy this driver is coming. I ran some tests on the CTP version and miss some functionality;

- sqlsrv_num_rows(): I use this mssql extension counterpart quite often. I am now forced to do a count query as an alternative. I prefer having this function instead.

- sqlsrv_select_db(): eventho you can run a USE db query. As far as I'm concerned this could even be part of the connect statement as optional parameter.

- sqlsrv_data_seek(): to mimic a limit statement on SQL Server I use TOP x followed by a data_seek on the resultset. I can do a sqlsrv_stmt_fetch until I reach the start row, but that might be slower then a data_seek that moves the pointer in one step.

- the limit of 64k on retrieval of columns should avoidable (ini-directive maybe).

- some bugs I ran across which I posted on the forum.

- on the positive side I am very glad we can retrieve all error messages. This is a limitation of the PHP MSSQL extension that annoyed me for a long time.

For a first release I suppose this is pretty decent. I am wondering when we will see more information on the design process as promised in this post.