Transparency in the Design Process
We have been looking at various options to ensure that the design of our SQL Server Driver for PHP truly reflects the requirements of the day to day challenges that our developer community faces when building real-world web applications and services. We would like to start by being as transparent as possible in the design process. I wanted to briefly describe how we’ll go about it so you know exactly what you are looking at when reading one of our design-related posts.
How did we get here? We shipped the first SQL Server Driver for PHP this week and we are now looking for feedback from the development community.
Transparency in the design? Over the years Microsoft has been opening up the engineering processes incrementally. Long ago there were only betas, and that was the only chance to see and give feedback about a product before it shipped. Then we started to do Community Tech Previews (CTPs). CTPs enabled us to provide bits more often and gather feedback frequently. The goal with increasing the transparency of design is to take this one step further: we would like to enable folks that are interested in our SQL Server Driver for PHP to follow the design topics as we discuss them, and have the opportunity to provide feedback right during the time where we are actively discussing a certain aspect and haven’t made a decision yet.
What exactly would we make visible? In short, our design process. To be more concrete, I’m not talking about some fancy set of specifications. What I mean is that as we go through the detailed design of the various aspects of the SQL Server Driver for PHP, we would post in this blog a) the meeting notes from our design meetings and b) deeper write-ups of specific design challenges where we’d like folks to understand how we’re seeing a problem and provide a channel for deep, detailed feedback.
How transparent is transparent? I want to be completely clear about the scope of the information we are sharing. One of the things we need to learn both from the Microsoft side and from the community side is whether the model works within a practical set of restrictions. We would post as much of our discussions as it is practically possible. However, we have to make sure we don’t compromise the interests of Microsoft as a company. There are certain things that can range from ideas to specific implementation details that we could consider trade secrets, high-value Microsoft intellectual property or something along those lines. It *will* happen that in some cases we will not discuss a topic publicly, either for a certain term (e.g. until a proper IP protection mechanism is in place) or until we ship or ever. This is nothing new, but I haven’t seen folks from large companies discuss this explicitly before, so I wanted to make sure it is clear here.
About your feedback: We would love to hear your thoughts, be it comments, suggestions, ideas or anything else. However, in the end we are designing a commercial Microsoft product. So we’ll happily take your feedback but you need to understand that by providing us feedback in any form you are agreeing that we may use it to develop our product, that others may use it in connection with the product and that you will not be compensated for any of these things. We may incorporate ideas or make changes based on comments you make, or we may make changes to the product that are indirectly influenced by discussions that we have with you and other folks in the community. Again, this is nothing new, but instead of having some fancy statement written in legal lingo I wanted to be upfront about this here in this first post on the topic. Of course our legal folks looked at this, and they were cool enough to understand that the informal nature of the process is what makes it work, and they let us get away with this statement in which I think we clearly delineate what will happen with whatever feedback you send our way.
So, what do folks think? Is this a good idea? Does it sound useful/practical? We will start posting design notes and challenges soon and tweak the process as we go.
John Bocharov
Program Manager
SQL Server Driver for PHP
Comments
Anonymous
October 15, 2007
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.Anonymous
October 16, 2007
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.Anonymous
October 23, 2007
The comment has been removedAnonymous
October 24, 2007
@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 PHPAnonymous
October 24, 2007
@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 PHPAnonymous
October 24, 2007
@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 PHPAnonymous
October 24, 2007
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 !Anonymous
October 26, 2007
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)Anonymous
November 14, 2007
The comment has been removedAnonymous
November 30, 2007
The comment has been removedAnonymous
December 28, 2007
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, --TravisAnonymous
December 28, 2007
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 FranceAnonymous
January 02, 2008
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.