This is more of a recommendation/request, rather than an issue.
The Go PHP7 group are looking to make sure that as many extensions as possible are ready for PHP7's release later this year.
Previously the SQL Server driver has been slow to keep up with new releases. Since moving to GitHub there have been a lot of improvements and 5.6 is supported :smile:
It would be really great if SQL Server was supported out of the box when PHP7 is released!
More information about Go PHP7 can be found on their own pages: https://github.com/gophp7/gophp7-ext
+1 this is very important if you want the php community to continue using Sql Server. It would be good to get a commitment from this team that the driver will be ready to support PHP 7 when it is released.
Having real built-in support for MS SQL Server in PHP would be a giant leap in giving PHP more credibility in the corporate space.
Thanks for the recommendations folks. I am part of the team that builds the client drivers for SQL Drivers. I will pass this message along.
I'm maintainer for Drupal - MSSQL integration and I'm postponing any D8 work until PHP7 is out and stable.
PHP < 7 is too slow for any of the "modern" PHP frameworks that are about to be released. With 200% overal improved performance (I can confirm those numbers personally!) I guess PHP 7 is going to be the version to be adopted at a faster pace, even if that comes at the expense of leaving behind anything that is not PHP7 compatible.
200% improved performance means halving hosting bills (among other things) and makes the pain of moving away from MSSQL to something else economically feasible and reasonable.
Hello,
We have PHP7 in our plans. I cannot comment on dates, but we will try to have it as close as possible with PHP7's release.
Right now, we are working on dates and scheduling.
Thanks
Sent from my iPad
On Jul 17, 2015, at 12:41 AM, Davvid <[email protected]notifications@github.com> wrote:
I'm maintainer for Drupal - MSSQL integration and I'm postponing any D8 work until PHP7 is out and stable.
PHP < 7 is too slow for any of the "modern" PHP frameworks that are about to be released. With 200% overal improved performance (I can confirm those numbers personally!) I guess PHP 7 is going to be the version to be adopted at a faster pace, even if that comes at the expense of leaving behind anything that is not PHP7 compatible.
200% improved performance means halving hosting bills (among other things) and makes the pain of moving away from MSSQL to something else economically feasible and reasonable.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-122205712.
PHP 7 RC 1 has already been released! I was hoping to test our application with it to help report any bugs before PHP 7 is finalized, but I can't without a driver for SQL Server.
It's for this reason that I will most likely be using a different database for future work. If it's not actively maintained (or a least has expected future release dates) it's very hard to plan future developments
Hi @gregrobson, extremely sorry for the inconvenience. I do not currently have a date for you but I can assure you that we will have a driver available for PHP 7 in the foreseeable feature. I am going to talk to my team over the next few weeks to see how we can make this happen asap. How soon do you need a PHP 7 driver?
Again apologies for the lack of communication.
Best,
Meet Bhagdev
Program Manager, Microsoft
I'd say that a ready driver at the expected release of PHP 7 (sometime in November) would be awesome.
But me (and I think other people too) would be ready to get an early preview of the driver - in other words asap :+1:
Thanks @twaileit
Let me start communicating this with folks on my team.
Best,
Meet
Hi @meet-bhagdev,
Thank you for your repsonse. I agree with @twaileit that sometime in November would be good.
I can't speak for others, but it was a long wait for 5.5 support (~16 months from PHP 5.5's release) - 5.6 support was quicker (~7 months). I know Microsoft have been having a bit of a shake up since Satya Nadella started and it's great to the code for the extension available on GitHub.
Obviously everyone is very keen to get onto PHP7 as soon as possible. With current benchmarks estimating it to be about 2x faster and with a lot lower RAM usage it's going to contribute to large cost savings for anyone who can run it. :moneybag: :smile:
I also really need a PHP7 driver for windows as soon as possible. Our company start using PHP7 with the first stable version in Nov. 2015, we testing it since first usable DEV release. One thing that we need because we use a lot of MSSQL servers is this driver. That's the last thing that we need. PHP7 seems pretty stable with the current RC release. Currently we need an extra pipe to PHP 5.6 for the scripts that require the SQLSRV extension.
Hope we will see this happen soon.
Thx and greetz
Hi @brainfoolong ,
Are you planning on updating to PHP7 as soon as it is released in November? As promised we are now working on the PHP7 driver but it is unlikely we will be able to release it so soon. We are looking a 5-7 month timeline right now. That being said, we might have a "preview version" be released a little sooner. Will keep you posted.
Best,
Meet
5-7 month delay?
You mean we should skip PHP 7 and wait for Version 8 or 9?
You did not really mean what you wrote. Or didn't i understood your post?
@meet-bhagdev Yes we are planning to use it from start, November 2015. Simply because PHP7 have so much features we really want and need. Faster than ever, finally real 64bit support on windows with 64bit integers, etc...
@meet-bhagdev PHP 7 claims to be "twice as fast" as PHP 5.x which means people will be keen to halve their hardware costs by upgrading.
If SQL Server wants to continue to take any licensing revenue from PHP applications then I suggest your team finds some extra resources.
It will be a humiliating for MS if Azure starts shipping PHP 7 with their PaaS apps and your customers can't choose SQL Server as their database engine.
Hi all,
I did not mean to say that we will be delayed by 5 months. We have already started work on PHP 7 compatibility. I am going to talk to my team to see how we can expedite it as much as possible.
Unfortunately I do not have a date for the next release but I will update you as soon as I have something to share.
Apologies for the confusion and thank you for the cooperation. We are truly trying our best.
Meet
@meet-bhagdev Nice to hear. You and your team deserve a cookie for this work, at least 2 when you get it done before Nov. 2015 :+1:
Really excited about php7 driver. Also we need to test the new php7 with RC versions but unfortunately we're missing the sql server pdo drivers. So we're waiting you guys. To test your pdo drivers and test php7 itself.
Please keep us posted about news...
Thanks
Hi @mlhkr
We are working very hard on these drivers. I still do not have a date set in stone, but stay tuned for updates.
+1 on @mlhkr
have you got some news ?
It would be nice to hear how far you've come, since the final release of PHP7 is coming closer (ETA is set to November 12th).
If you need testers, feel free to provide development drivers.
We are currently working on refactoring our driver to support the memory management improvements in PHP 7. We hope to get an early build available around January 2016 for testing on Windows. We will then continue our quality & testing work and hope to release both Linux and Windows versions when we reach our quality targets.
Hope that helps.
Thanks,
Meet
Thanks for update.
Unfortunately this is too far into the future (at list for me) and existing projects most likely will remain with existing PHP versions and MS SQL, new one will start on other data base types.
I understand that there is much work to do and many changes and we are grateful for all your work on this, but the time frame is too much in this case. Is better to have at list a basic working version (connect, select, insert, update, delete), comparing to no support at all.
Also a way too late for me. We unfortunately cannot wait, we must add a really ugly and nasty proxy to PHP 5.6 for the things that require a MSSQL server connection.
I'm thankful for all the work from the team on that but also i don't understand why such a driver need more than 6 months to get it working... At least when there is already a working driver for PHP 5.6.
Anyway, looking forward for the first working release, fingers crossed that this not will be that much delayed as the current "MS Edge Extension support" :+1:
+5000000
I use PHP and MSSQL to get the best of both worlds, yet it appears I get punished for it. :(
Can you explain why that take 6 month to update the driver, we obviously don't understand this.
Thanks.
Hi all,
My goal is to be as open and transparent as possible with this community so that you can plan accordingly. We are currently in the process of updating all our connectivity drivers in preparation for SQL 16 release while also incorporating change from PHP7 (and JDK9 for JDBC). We want align all the various releases and dependencies to make sure that our new PHP driver includes some of the goodness of the new version of the ODBC Driver that our customers can use with SQL Server 2016. As mentioned earlier we will have a functional build in January for the community to try and after that we will work to release as soon as we can. We will keep the community informed as we make progress.
Thanks for the clear statement.
We will update our old servers now to SQL 2012 with PHP 5.6.
PHP 5.7 (and e.g. SQL 2016) is out of scope now for the next years after reading this.
Thanks a lot @meet-bhagdev, in my team we will do what @tradetzki, for now upgrade to SQL Server 2012 and still using PHP 5.6 and in January in our develpoment platform test your release. ¿it will be available in x64 version? Regards
@sirio3mil : Yes it will be available on x64.
Thanks,
Meet
Definitely of importance to my team. We would love to transition to PHP7 ASAP, but will need to hold off until a sqlsrv extension is available.
Hi, PHP 7 has been released. Is there any plan ?
Hi all, PHP 7 got released on December 3.
We are aggressively working on the sqlsrv extension and are looking to release it as soon as possible.
Thanks,
Meet
@meet thanks for the link I could not agree more. But it happens that PHP nailed the "business model" - if it can be called so - to end up powering more than 80% of the internet. Unluckily sometimes - more often than not - success is not about technical quality... and we technical people must bear the burden of what business is really like.
Hope to see PHP 7 support soon and that hopefuly some of the longstanding bus get fixed.
Thanks!
@meet-bhagdev I can't understand why you point out that article, nothing to do with the actual issue ! And please look carefully this chart https://adtmag.com/articles/2015/12/03/~/media/ECG/adtmag/Images/2015/12/veracode.png .Net is not so far from PHP...
IMHO also Offtopic because i also don't like that linked article for several reasons: As with every language, security comes with coding quality, not with the language features and syntax itself. This article just smoothly raging against PHP without a fundamental reason.
But here we focusing to the PHP7 support for SQL server, and for that point, i really looking forward for some working stuff.
Last week I was approached by an Azure Canada technical sales saying "I have this two BIG government/public institutions wanting to move their workloads to Azure, and I am recommending them Azure PaaS, but I see your MSSQL driver for Drupal has some Azure MSSQL Issues".
After a few e-mails our mutual conclusion was that support for PHP and related componentes on Azure/Windows/MSSQL was too broken to be taken seriously and that they should be deploying their workloads on Azure IaaS using MySQL. So in the end they will be using Azure, but just to spin up some Linux with MySQL machines. I believe they would be better off at AWS that has a more Linux centric ecosystem.
I guess this is more on topic because it has to do with the level of support we are getting from this driver - which by the way I'm not complaining about because it has got much better than what it used to be - but still far away from something to be considered business ready.
So if MS wants to sell PHP on Azure - that is powering more than 80% of the internet so that is a big slice of the cake - (using MS technologies of course not a Linux/Nginx/MySQL virtualized setup) it is in their best interest to properly support this driver and other PHP ecosystem related pieces.
Hi all, apologies for sharing that link. My goal with sharing that article was to inform that PHP 7 got released last week.
Just a quick update on this PHP driver, we are still working hard and looking for a late January release. I will inform this thread as soon as we have our beta release ready.
Thanks,
Meet
@meet-bhagdev Great to hear... Any ideas on an approximate date for the beta release? Will be good to get some testing underway...
Hi
We are currently in the process of porting the sqlsrv driver to PHP7 as the Microsoft timelines don't meet our requirements and also the fact that each driver release restricts us to specific versions of the SQL server native client. This is noted in detail in Rob's blog post linked to below.
We have queries working (stored procedures etc) however our function usage is rather limited. We will soon be making the code available on GitHub and will also be combining it with Rob's code at:
http://robsphp.blogspot.com/2012/06/unofficial-microsoft-sql-server-driver.html
...which has a fix for a memory issue.
Going forward it would be good to know:
1) If you are using the PDO driver(pdo_sqlsrv) of the procedural driver (sqlrv)
2) What functionality you are using in each, notably for "sqlsrv" what sqlsrv_ functions you are calling.
We intend to support our port going forward as the driver is intrinsic to one our products so any help with usage patters would be great for our first beta.
Charles Durrant
Thomson Reuters
@charles-durrant-tr @meet-bhagdev
Diverging efforts in something that has such a limited support is not the best idea.
If using the Github collaborative capabilities, people could chime in, fork and fix issues. It would be good for the driver if MS would actually use Github to develop and publish ongoing work, not only to publish the "finished" code.
Just an idea....
@david-garcia-garcia. I agree....but as Rob pointed out in his blog post each driver version limits the system to a particular SQL server client and for no beneficial reason. I am sure there are 'internal reasons for this but its not practical for us going forward.
I hate to hard fork code but we don't have a choice. There is no real support for this driver (well in the past there hasn't been) so we are keen to push this forward and fix issues proactively.
An example we have had hanging around for ages is out of order stored proc parameters. They are supported in PDO but sqlsrv doesn't support them. This is purely a higher level issue with sqlsrv as the core code is the same.
On the PDO note, we'd like to use PDO but it is so much slower than sqlsrv. All that being said we almost dropped the whole thing in favour of odbc PDO but there are binary level output parameters with the PDO base php library. That is on our list of commits to make to the core.
I digress, we will be supporting the driver and I hope (which relates to your point) that after time the project can become something handled by the community which I think will benefit all parties with the caveat that it doesn't become the old mssql driver that was very out of date.
If our works goes on to spur MS to work as you say on GitHub then we will have lost some effort but we will be very familiar with the code!
Hi @charles-durrant-tr @david-garcia-garcia,
The Microsoft PHP driver is suppose to work with all SQL Server versions we support (SQL Server 2008 or later). Please let us know if you have had issues so that we can file them as bugs.
I definitely agree that using Github to develop and publish ongoing work, not only to publish the finished code is a good idea.
I will take that to our team and keep you posted of what we decide.
Thanks,
Meet
@meet, your comments re SQL versions although very welcome don't add up - see Robs blog post as linked to in my comment. This issue has been around for years and has been commented on else where.
@charles-durrant-tr, Rob's blog post lines up exactly with what @meet-bhagdev just said. The ODBC driver is not the same thing as the database version. You acknowledge the true situation is the driver, not the database version, in your original post.
I would hope that both Rob's ODBC detection and your PHP7 fixes are able to be added into the official driver.
@atbigelowe, oops, yes correct, posting after a late night was not such a good idea!
We removed the checks in the driver a while ago as v3.1 or above required odbc driver 11 which was not possible to install on server 2008 thus sqlsrv version was forcing the server OS version and also the php version. An early morning after a late finish so apologies in advance for any inaccuracies.
We expect to post our beta code this week allbeit initially with our limited feature set requirements. If the outcome is a contributable project from MS on github then that is the best option.
As an aside we use wincache as apcu isn't happy on windows at the moment and that project has raced along in terms of PHP7.
....as a post script, for a time we supported Linux with our product and freetds was orders of magnitude faster than the MS windows offering. Database access was and still is our bottleneck and a 0.5gb Linux server was running web transactions ~2x faster than windows with 2gb ram under load testing. It was all down to freetds.
I digress from the focus of this thread but I think it is an interesting observation to share. It was also fascinating seeing the tabular data stream in action.
2016 has arrived at our doors.
Any news or updates about the v7 driver?
@mlhkr : Still working on it. Aiming for a beta release by the end of the month. Stay tuned as I will update this thread as we get closer.
Happy Holidays :)
Meet
whether pdo_sqlsrv for php 7 already available ?
@meet-bhagdev,
We've made our initial port of php_sqlsrv.dll available at:
https://github.com/thomsonreuters/msphpsql/ (it aint pretty!)
It was a perfect Christmas time project and it now meets our very limited needs. We had a lot of problems with memory management related to connections, errors and recordset handles. Primarily due to the MS code storing C structs in ZVALS which looks like it is now a big no to do.
Out of interest are you doing a complete re-write or doing #if PHP7 ()?
Charlie
@charles-durrant-tr : Pretty cool project. Looks promising. I will give it a shot tonight! To answer your question, we’re not doing a complete re-write but are upgrading the current code directly because we felt it was quicker and cleaner than having a lot of #ifdef’s everywhere.
this is going to be compatible with linux?
we’re not doing a complete re-write but are upgrading the current code directly
I'm sorry to say that It is worrying to hear this statement at this point.
we felt it was quicker
Sure
and cleaner
I understand this is a typo
Anyways, I really appreciate the effort and are looking forward the PHP7 release.
I guess that if you are sharing the same codebase, some of the fixes will be backported with ease to 5.x and some of the issues in the queue get solved.
@charles-durrant-tr I tried out your driver today and couldn't get it working. Obviously it's not compatible with 64-bit PHP, but even on 32-bit it doesn't seem to be a drop-in replacement for the PDO drivers and didn't really want to spend the time figuring out which methods would need to change.
Still waiting on @meet-bhagdev and his team to provide the official one.
@soapergem Note that the driver of @charles-durrant-tr will not port the PDO extension:
1. We are not porting the PDO_SQLSRV extension and targeting only the SQLSRV extension.
I'm also waiting for the official (PDO) driver.
@soapergem
Our driver version is the procedural variant not the PDO variant which is pdo_sqlsrv.dll. We found the pdo driver to be significantly slower than php_sqlsrv.dll. We didn't look a great deal into it though. Additionally PDO has issues with streams - we have a fix pending for PDO (not pdo_sqlsrv) but as yet with many other things we haven't got around to creating a test case.
Also PDO by design encodes dates as strings. Not something we liked, a date is a date not a string. That being said ODBC presents all dates as strings underneath!
Charlie
@david-garcia-garcia
"I guess that if you are sharing the same codebase, some of the fixes will be backported with ease to 5.x and some of the issues in the queue get solved."
We went down the ifdef route for the sole reason for sharing fixes between versions. If MS are creating another version, which it appears they are then the versions <7 will have to have to have fixes applied separately. Note that all the extensions we looked shipped with the core don't use ifdefs and simply created a new source from what we could tell. This doesn't bode well for Drupal use since you need things to be consistent.
Charlie
@igormx
Nope, my advice at this point in time is to use PDO_ODBC and FreeTDS. We couldn't get the MS sql server driver unix ODBC to work effectively. FreeTDS worked for us and was much quicker.
@meet-bhagdev
Why was it that the sql server drivers were not compiled for unix given they just use ODBC underneath?
Charlie
@charles-durrant-tr We've had problems with using PDO_ODBC and FreeTDS. Things like zero length string fields being returned as " " and characters like the right and left single quote serializing as unknown characters. However, it may also be because we're using Doctrine. We had to move to serving our PHP on Windows and didn't have much luck with Linux. I'm also wondering why MS didn't release a driver for Linux.
@drewclauson
It's not the easiest setup either, I do applaud the people who wrote freetds though. It was magnitudes faster than MS, I assume due to less checking? Who knows.
" I'm also wondering why MS didn't release a driver for Linux."
I expect it is business decisions based on windows server sales. My main dev wants to port our driver to Linux and call MSs ODBC driver in his own time.
As an aside we have decided to re-factor the ms driver. I know it sounds like a typical developer saying "it would be quicker to rewrite it" but in this case we think the current structure makes fixes and porting harder. Re-factoring would mean than the code can work fof PHP7 and lower without too many ifdefs and reduce dual bug fixes. We'll see how it pans out.
Charlie
Microsoft actually have an ODBC driver for linux: https://msdn.microsoft.com/en-us/library/hh568451(v=sql.110).aspx
@sirio3mil
Yes, I know, it has more issues than freetds in our use cases. See 4th post above.
C
@charles-durant-fr also last v13 preview?
@sirio3mil
It was last official release so yes it could be worth a try with the new one.
Charlie
@charles-durrant-tr
We found the pdo driver to be significantly slower than php_sqlsrv.dll. We didn't look a great deal into > it though.
This was supposed to be fixed by the implementation of client buffered queries:
But they messed up so much with the implementation of buffered queries (problems with floats, null terminated string, etc..) and it was also buggy so this feature although "usable" is not something you do not want to rely on to build anything serious.
@david-garcia-garcia
What is it you mean by buffered queries and does this relate to:
http://www.drupalonwindows.com/en/blog/benchmarking-drupal-7-php-7-dev
From Wez Furlong's presentation about Buffered Queries were simply result->fecthAll:
http://wezfurlong.org/images/PDO.pdf
from
http://stackoverflow.com/questions/578665/php-pdo-buffered-query-problem
Nothing more different than calling ->fetch in a loop apart from the overhead of the php interpreter calls.
What were the issues explicitly?
Charlie
@meet-bhagdev Any update on this? I work for a large organization that works very closely with your company and haven't heard any updates.
@nickmccally : Still working on it very very hard. Expect to see something from us by the end of the month.
@meet-bhagdev I appreciate the feedback. With almost a year of lead time to start developing what caused the lag? This will just be for a beta correct? Do you guys have any expectations for a productionized product? I'm just curious because it looks like this project has been delayed several times, and I want to better go back to my team with commitment on upgraded infrastructure timelines. I know you most likely work as part of a large team, and this is no personal attack. Just trying to get things ready so we can still utilize sql server as our primary database-- instead of looking for alternative solutions.
@meet-bhagdev with the month ending in 4 days can you guys make any commitment to a more specific deadline? Our project decision items will be finalized by Monday, so this will help me understand if we need to work towards a new solution or if we will have something to begin testing. Thank you
@nickmccally I would not count on this for production - if it ever happens - for at least the next 6 months. For example, the Wincache PHP7 extension was released on october 2015 and bugs are still being solved. It all depends on how much testing and feedback this thing gets after release, and how responsive the maintainers are at processing that feedback.
@nickmccally We are aiming to get the binaries and source on Github on Friday 1/29. Just wrapping up some final testing.
@david-garcia-garcia We would love for you to test this hard and let us know what we need to fix, especially any PHP7 specific issues.
@meet-bhagdev Really looking forward. We want to drop PHP 5.6 as fast as possible. Only reason keeping it is this driver.
@meet-bhagdev, I am sure @david-garcia-garcia has a vested interest in improving the quality of the driver but as he is a consultant perhaps you can partially acquire his services to assist you? Having a tighter feedback loop will make the QA / fix cycle more efficient.
If we have to wait 6 months for a robust SQL Server driver there will be a number of projects who ditch SQL Server which will mean lost revenue for Microsoft.
@Joe-U-Questionmark
Your comment is spot on. No matter how many test cases you write having a live application to execute to test the driver is best.
Our driver is coming on very well and our refactoring is making the code cleaner and simpler (well we think so!).
Looking forward to seeing the MS version though - it's not an easy task hence our refactor. The MS code didn't port well - just bad luck in the way the PHP core changed for V7.
Charlie
p.s. "If we have to wait 6 months for a robust SQL Server driver " - in my opinion I think it will be the same for PHP7 as with any new tech.
@meet-bhagdev One day away... will you make the deadline you set yourself? Can you also explain WHY it takes a year to write a driver? Why the delays? Imho a year for a driver for a vastly popular framework, that woudl aid SQL server sales and support fees, is too long, especially for a large company like Microsoft...
If you'd guys have worked via github or even your own open access repository this would have been done much faster I think because people would contribute to it to speed stuff up, freeing up crucial core activities for your team to tackle...
At least it's something you guys share end code...
And eh... will mssql finally support UTF-8? that would be nice... like... really really really nice...
@tschallacka it does support UTF8 - all data is converted to UTF-8
Well, I have a utf dependant site running on sqlserver 2012, and it all gets converted internally to windows 1251 or someting like that... gave me a few headbreakers, until I figured out there is no solution for it and that I just had to accept that all german characters turn to gibberish. I have so many catch blocks in my code to check for that and to turn it into the proper text encoding when retrieving from database that it gets tiresome to constantly having to account for it...
@charles-durrant-tr Please try to get from DB a Romanian character like "ș", "ț", "ă", and you will see the big Microsoft support on this.
using nvarchar does help a bit.. but not greatly... there is still a lot getting lost in translation. Would be cool if the driver would help, or there'd be a fix for sql server to support this WIDELY use thing called utf8 instead of the MUCH HATED windows codepages.
I save in DB something like {A}, {B}, etc. instead of ă, ș, etc. and just search and replace this with HTML code for the required character. It makes no deference if I use nvarchar or char. By the way, in mysql driver this is working just fine and I can get the special characters from DB.
@tschallacka Connect using the UTF-8 CharacterSet option (see https://msdn.microsoft.com/en-us/library/cc626307.aspx). Unicode characters in nvarchar fields work fine for me when I do this.
We should be thanked that SOMEONE is working on this. How do you know this is not a MS employee doing this in his free time? I believe - I might be mistaken - that neither MSSQL PDO, Wincache or other PHP/Windows related things have official MS endorsement.
Try to file a support ticket with MS regarding this driver (you know you can do so by cashing out some bucks right?) and see what happens.
Pressure should be done on the other side of the funnel. Sign up for Azure and tell customer support that you want to move your xxxx€/month PHP workload to Azure and that you can't due to lack of support/compatiblity. Then they will tell you that you can use use _Nix and MySQL and you should answer that to use that you are better off at AWS. That *might_ yield better results than complaining here (which I appologize for having done before too).
And if you find issues with the driver, prepare sample test scripts and fill a bug in the issue queue. That is a very valuable type of contribution to open source.
After all this is open source and it is up to MS to evaluate the ROI and strategical impact of the efforts put in here.
@meet-bhagdev Looks like there's a lot of people here willing to test the driver and make the necessary effort to provide useful feedback in the form of properly reported bugs with repro scripts. At least they should if they want anything to be fixed because a bug that is not reported is a bug that does not exist. But please, if people take the time to do so, make sure to work on it otherwise they won't submit more feedback :)
(not supported in the PDO_SQLSRV driver) guess what i'm using @theodorejb
@david-garcia-garcia @meet-bhagdev my organization spends a significant yearly amount with Microsoft contracts. I'll have to look at the plan this year, but I'll reach out to some contacts and see if we can put a formal request in. The Microsoft tower is just across the street from my office in Washington DC/ Chevy chase.
@nickmccally It seems to me then that you have a good chance of making something official happen. Please take the flag and let us know Microsoft's response, if any.
I'm not taking away credit from this project, but it would be nice to know where does Microsoft stand on this if approached by an organization like yours on the matter. I'm sure everyone here will be very thankful.
FYI... another way to get around the UTF-8 character encoding is to send a Hex encoded string (without quotes) for everything that's not a date or numeric, which is then parsed automatically on the SQL server side into varchar. You get some pretty crazy stored procedure params that look like @my_param=0x5ABC123456... and so on...
function mssql_escape($data) {
if(is_numeric($data) || validateDate($data) || validateDate($data,'Y-m-d H:i:s') || validateDate($data,'H:i') || validateDate($data,'H:i:s')
|| validateDate($data,'Y-m-d H:i:s.u') || validateDate($data,'Y-m-d H:i:s.0000000') || validateDate($data,'H:i.0000000') || validateDate($data,'H:i:s.0000000') || validateDate($data,'m/d/Y') || validateDate($data,'d/m/Y') || validateDate($data,'n/j/Y') || validateDate($data,'j/n/Y')) {
return "'".$data."'";
}
$unpacked = unpack('H*hex', $data);
return '0x' . $unpacked['hex'];
}
function validateDate($date, $format = 'Y-m-d') {
$d = DateTime::createFromFormat($format, $date);
return $d != null && $d && $d->format($format) == $date;
}
Then if you need to make sure it comes back correctly when do do a query using iconv...
iconv("CP1252", "UTF-8", $data_string_from_select_query_here);
Hope that helps somebody...
Uhu, or base64encode your stuff you wish to encode, or escape htmlspecialchars and decodehtmlspecialchars... there are aways around it, but it clutters up your code and is contra intiuitive and ridicilous. Basically all software supports utf8, heck, even notepad supports utf8. The web for westeren countries relies on utf-8 as encoding, IIS sends files as UTF-8 when requested apache sends as UTF-8, ngix sends as UTF-8
Hey guys, sorry if i'm kind a spoilsport, but can we focus on the PHP7 future planning for the SQL driver here? I'm not very interested in all of your coding problems but i want to be up2date with the actual ticket. Now i'm getting tons of mails and notifications for this ticket that are not really related to this ticket.
Agreed with @brainfoolong we will lose relevance to the developers staying off topic.
@meet-bhagdev Any update on the progress sir?
https://github.com/Azure/msphpsql/tree/PHP-7.0 seems to be going up now...
@david-garcia-garcia @nickmccally @tschallacka @reyronald @charles-durrant-tr and rest. I agree with you that 1 year is a long time to release a new driver. The remark about this not being acceptable is completely justifiable. In the past, we have not done the best we could have to listen to your needs. Going forward, we plan to change that. This includes an early technical preview of the PHP sqlsrv driver for Windows that we released on GitHub today
Myself and the engineers developing the driver work at Microsoft on the SQL Engineering team. We plan on following this release with pdo_sqlsrv for Windows, porting the drivers to Linux, feature completeness, and bug fixes. We will share our progress by publishing new code and binaries incrementally on GitHub every 3-6-weeks.
We sincerely apologize about any inconvenience this has caused and will continue to try our best to avoid repeating this going forward.
If you have any concerns or questions, please reach out to us over email:
Thanks,
Meet
Thanks Meet
Thanks @meet-bhagdev really appreciate you coming through with your deadline. I personally need PDO support but it's heartening to see the progress.
@meet-bhagdev I appreciate your follow up and your dedication to the project. We often love what we do and work late into the night as programmers... your love for what you do shows! Thanks for the commitment to your customers!
Thanks @meet-bhagdev... But like @leejunkit, really need the PDO version...
Awesome to see something released. Also need PDO here.
@meet-bhagdev thanks a lot for this release, your team have plans to release a x64 version for this TP? Regards
Happy to see something, unhappy that i cannot use it because the lack of 64bit support. As already asked, some infos for the 64bit issue?
@meet-bhagdev news for x64?
Given x64 support in php was experimental until php7 anyway (and therefore presumably not used in the wild) I'd (personally) much rather have a PDO driver in any form first, with x64 for both the old sqlSrv and newer PDO to follow.
@ashryalls +1
x64 +1 :-)
PDO +1
Please release support for x64 PHP 7 soon. It'll be a whole new world for many of us! Many Thanks~!
Thanks for all the feedback so far. I would like to share a survey with you all. This will help us prioritize the work going forward. If you all could spend a few seconds to provide your input on this survey, that would be greatly appreciated.
Thanks @meet-bhagdev :)
I'm also looking for PDO x64 (just finished the survey). Thank you @meet-bhagdev for all your work on this and it's gratifying to hear that MSSQL updates/requirements may be more in step with future PHP releases.
Thanks @meet-bhagdev :)
just for interests sake, will you post the results of the poll here when it finishes? it'll be interesting to see the distribution of tech requirements from different devs.
Hello guys, is there a way to compile the new released sources on Linux?
We will definitely publish the results of the poll once it ends. I will close the poll on Sunday (2/7). I believe that is sufficient time for everyone to share their requirements.
@meet-bhagdev How did the poll turn out?
@KyleWiering thanks for the ping. It turned out great. I was delighted to see the number of unique respondents (147 respondents). Here are the results:


Q: What does this mean?
Ans: This means, we will revisit our plans to see how we can align best with what you all want here. We plan on supporting all the variants mentioned in the survey. The goal of the survey was to figure out which ones should we prioritize. We now have a clear idea and will try our best to do prioritize based on the data.
Thank you all for taking time to do this survey. Let me know if you have any questions.
Meet
Thats why i cant still use pdo sqlsrv driver on new PHP7. We are planning to develop new ERP for our company and i wonder how can i proceed with the versions. So i have to downgrade to PHP5.6 if i want to use IIS and PHP on one mashine?
Tested with php nts fast cgi 7.0.3 and nginx and works fine at first look.
@sirio3mil Glad to hear :) @naskobulgaria : We are currently working on the PDO sqlsrv driver. Will keep you and the rest of the Github community updated.
@meet-bhagdev do you have an ETA on the PDO sqlsrv driver?
Tested on Windows 7 x64 + PHP 7.0.3 x86 Thread Safe.
And works very nice.
PS: I will be waiting for PDO_SQLSRV version.
Thanks a lot.
@nbpalomino : glad to hear :)
@Joe-U-Questionmark : Thanks to the survey results we have we have mostly been focusing on making updates to support native 64-bit and the PDO driver. I do not have an eta to give yet but will let have timeline to share in a few days.
I appreciate all of the hard work. I am patiently waiting on the native 64 BIT driver to upgrade to PHP 7. I am currently running Apache 64 Bit and PHP 5.6.5 64 Bit. I could really use the performance gain that PHP 7 promises :)
I will add it's nice to have communication with a Microsoft Rep. Thank You!
I am using the "PHP5.6 + SQL Server Driver for PHP + PDO", but in trouble in that SELECT is slow.
When I search on the Internet, there was a person who suffer from the same phenomenon.
This problem is, what shall be resolved by PHP7?
Thanks.
I would like to add a request that the new drivers have an option to not send the messages like the following to the php error log:
pdo_sqlsrv_db_handle_factory: SQLSTATE = 01000
pdo_sqlsrv_db_handle_factory: error code = 5701
pdo_sqlsrv_db_handle_factory: message = [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Changed database context to 'Scheduling'.
If there is currently a way to do that which I'm not aware of, please enlighten me.
Thanks
@meet-bhagdev
but will let have timeline to share in a few days
Any news on that? 2 weeks over since that comment. Especially interested for the 64bit native release.
I am waiting on the x64 PDO driver, any news on timescales?
Hi all, thanks for the ping. We have been working extremely hard on the PDO 64 bit &32 bit drivers as well as the native SQLSRV 64-bit driver. We plan on sharing an early preview 64 bit native SQLSRV module in the week of 3/14 and the PDO 64-bit and 32-bit drivers about 3 weeks after that. That being said, we are pushing extremely hard to get these drivers out of the door as soon as we can. Towards the end of the week I will have the precise dates to share.
In the meanwhile, I also wanted to share an exciting announcement of running SQL Server on Linux. Check it out :) https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
Just good news, thx @meet-bhagdev
Hello
Thanks, it's a good news.
Will the driver works with SQL Azure wich doesn't allow the USE keyword
(The database should be selected during the connection)
Thanks
Regards
The week of 3/14 is like Christmas in March... wrap a bow around the 64 bit native SQLSRV driver please ;)
Hello all, we just uploaded the bits for the 64-bit SQLSRV driver. Feel free to give it a shot and let us know if you find any bugs/issues/concerns that you would like us to address. Next up, 64-bit PDO and 32-bit PDO driver. You should expect to see a release from us on the PDO variants in the next few weeks. I will try to get an accurate timeline as soon as I can.
Cheers,
Microsoft PHP Driver for SQL Server team
Where are they please; I looked under https://github.com/Azure/msphpsql/releases but didn't see anything new.
I am stupid.. lol I thought those were prefixed with PDO, sorry.
No worries @DigitalSolo, glad it got sorted out. Would love to get your feedback on the bits.
Cheers,
Meet
I am unable to connect to the DB with this error message:
Server. Access the following URL to download the ODBC Driver 11 for SQL Server for x64: http://go.microsoft.com/fwlink/?LinkId=163712
[message] => This extension requires the Microsoft ODBC Driver 11 for SQL Server. Access the following URL to download the ODBC Driver 11 for SQL Server for x64: http://go.microsoft.com/fwlink/?LinkId=163712
)
[1] => Array
(
[0] => IM002
[SQLSTATE] => IM002
[1] => 0
[code] => 0
[2] => [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
[message] => [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
)
)
@DigitalSolo The Microsoft ODBC Driver is a pre-requisite for the PHP Driver. Can you download the driver from here? Let us know if this still exists and we will work with you to sort it out. Also, feel free to create a new issue, so that we can track it better.
Cheers,
Meet
Loading the ODBC Driver now. The link in the error message doesn't make it real clear where to get the file. http://go.microsoft.com/fwlink/?LinkId=163712 Thank you for the link you provided.
That worked great. I can select data from my DB just fine. I will test writes and a few other things tomorrow. Thanks for the hard work :)
Glad it worked out! :+1: :)
Hey there,
had one issue so far with sqlsrv_fetch_array: you have to define fetchType or else php crashes.
Otherwise it works great for me.
Is it possible to add it to https://www.microsoft.com/en-us/download/details.aspx?id=20098 ?
It's only in the beta testing phase so I would assume not until it get's past UAT.
@k2viewLTD : We will definitely add it to the download center in the coming months. I am curious to learn what do you prefer, getting the bits from Github or Download Center?
@PakL : Issue has been noted and will be investigated. Will let you know if we have any questions.
Cheers,
Meet
Could you add the download link https://www.microsoft.com/en-us/download/details.aspx?id=36434 to the required ODBC driver to the error page: http://go.microsoft.com/fwlink/?LinkId=163712 This is the link that's given in the error message when you don't have the ODBC driver installed.
@DigitalSolo Will be done! @PakL Can you share a repro script for the issue you are experiencing?
Cheers,
Meet
Thank you
@meet-bhagdev I made some more tests. It only crashes with prepare parameters and undefined fetchType. Here is a snippet of my test https://gist.github.com/PakL/97abbb0767df3f42ba51
Thanks for the 64-bit driver!
I can't seem to get the current ODBC driver 11 to work in Windows 2012 R2. Anyone tried the ODBC driver 13 preview at https://www.microsoft.com/en-us/download/details.aspx?id=50420 ? Or am I missing something..
@PakL Thank you! @dageddy The ODBC 13 preview is not compatible with the PHP Driver yet. We are working on it. What issues are you experiencing while using the ODBC Driver 11 on Windows 2012 R2.
Cheers,
Meet
I have been too busy to really dig into this beta driver as of yet. I hope to take it through it's paces this weekend. I would be curious if anyone can validate the performance gain that PHP 7 with the 64 Bit native SQL_SRV driver boasts.
@meet-bhagdev Thanks for confirming ODBC 13 preview is not compatible. Recently the download link for 64bit ODBC 11 disappeared. So I installed a copy that was downloaded last year and it works. Today I see the ODBC 11 link but hosted under "amd64" folder.. is there no x64 version?
I downloaded the one https://www.microsoft.com/en-us/download/details.aspx?id=36434 listed as amd64 and it worked on my Intel machine perfectly.
@DigitalSolo Thanks. I will try the amd64 copy then.
If for some reason it changed I can zip and email you the one I downloaded a couple of days ago :)
@dageddy you can fetch the ODBC Driver from here: https://www.microsoft.com/en-us/download/details.aspx?id=36434
Once you click on the Download button it will ask you to pick the 64 bit msi (
1033amd64msodbcsql.msi) or the 32 bit msi (1033x86msodbcsql.msi
).
Let us know if you still have trouble and we will look into this. We will also update our documentation to make this clear.
Thanks,
Meet
@meet-bhagdev Thanks for the work you and your team are putting into this. My question is what the best course of action the we, the general PHP development community, can follow to get the importance of your work known to the decision makers and get your team more resources.
Combined with the lack of direct support in Visual Studio (as opposed to Python, Ruby, etc.) and the staleness of the PHP on IIS site, among other things, it seems to the outside observer, that PHP is taken by MS at large as a tertiary language. How can we, from your perspective, help to turn this around?
Thanks again!
@TampaCraig ,
Glad to hear from you. It is always great to have a passionate and dedicated community like the one we have for PHP. There are numerous efforts going on across Microsoft to ensure PHP is considered a primary language. You can help us identify areas that are most important to you and thereby help us prioritize. Having input from the community with regards to what matters the most to them will definitely help us scope out the work and channel our resources in the right direction. What are the specific use cases (in addition to the ones you mentioned above) you as a PHP developer are finding out today where Microsoft could do better at supporting you. I encourage you to voice your thoughts here and/or by email- [email protected]
Cheers,
Meet
Thanks Meet, I'll definitely put some earnest thought into it and follow your advice in writing [email protected]. If "data is the new electricity" then software is the conduit by which it is conveyed and transformed. I think we will need many different routes, conductors, and transformers that interoperate to allow us electricians to create integrated solutions.
I'm happy to see MS opening its toolbox, and hope for more to come. It inspired me to move my PHP based Intranet to Windows/IIS from Linux/https, let's see where more interoperability will take us in the future.
Your idea is great @TampaCraig, I will also give my support and suggestions to this email. Thanks a lot @meet-bhagdev for this.
We use Drupal on IIS with Sql Server.
Drupal serves as the back end for more than 1 million websites and boasts a community of more than 600,000 users and 25,000 developers who have contributed more than 20,000 modules.
If Microsoft wants OP OS and Sql server licensing and Azure revenue from this group then they need to improve the performance and reliability of the Sql Server driver.
So while it is great that you are working on the features to release the Sql Server driver for PHP, I would also like to see regular benchmarks released that display the performance characteristics of the driver. And if you are ambitious and competitive then you would do this alongside the competition for context!
If I perform an insert with an invalid field name (doesn't exist in table) I am not getting any error message back pointing me to an invalid field name after calling: sqlsrv_errors()
INSERT INTO MyTable ([FieldName1],[FieldName1],[**InvalidFieldName**]) VALUES(1,2,3); SELECT SCOPE_IDENTITY() as ID
Trying to use driver php_sqlsrv_7_ts.dll instead of php_sqlsrv_53_ts_vc9. Code page 1251. All is working good except one thing - function sqlsrv_errors, returning error, produced by SQL server, converts all non-english letters to '?'. Is it posiible to correct this somehow? Not sure is this a problem of sqlsrv driver or ODBC driver 11 (Which replaces SQL Server Native Client 10.0, as I understand)...
try saving in nvarchar instead of varchar
Verzonden vanuit Outlook Mobilehttps://aka.ms/blhgte
On Thu, Mar 31, 2016 at 12:52 AM -0700, "Nick74k" <[email protected]notifications@github.com> wrote:
Trying to use driver php_sqlsrv_7_ts.dll instead of php_sqlsrv_53_ts_vc9. Code page 1251. All is working good except one thing - function sqlsrv_errors, returning error, produced by SQL server, converts all non-english letters to '?'. Is it posiible to correct this somehow? Not sure is this a problem of sqlsrv driver or ODBC driver 11 (Which replaces SQL Server Native Client 10.0, as I understand)...
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-203803641
*_tschallacka *_
it is hard to do when i already have 700 tables with thousands of fields with varchar type...
Solved problem now by passing 'CharacterSet' => 'UTF-8' and encoding/decoding all queries and results to/from UTF-8, but it's a crutch. ((
Ouch...
Well that sucks. Im lucky i found out that caveat with 75 tables.
I suggest you export create scripts, change varchar into nvarchar in those, then insert into new select * from old
If you have multimillion records i suggest batching that, but it can be done in a day, maybe two, then rename old to old.back and new to old.
Takes effort, but is much more error free that converting.
Verzonden vanuit Outlook Mobilehttps://aka.ms/blhgte
On Fri, Apr 1, 2016 at 2:00 AM -0700, "Nick74k" <[email protected]notifications@github.com> wrote:
*tschallacka *
it is hard to do when i already have 700 tables with thousands of fields with varchar type...
Solved problem now by passing 'CharacterSet' => 'UTF-8' and encoding/decoding all queries and results to/from UTF-8, but it's a crutch. ((
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-204318311
@Nick74k I have created a new issue the non English character issue for better tracking - https://github.com/Azure/msphpsql/issues/80.
Let us know if @tschallacka's recommendation works for you. We will investigate this on our end regardless.
well, utf8 support in varchar would be nice instead of the windows 125X ones.
Utf8 support in general throughout sqlserver instead of having to manually capture all the gotchas.
For web applications and php developers in general is utf8 prederred i believe over the windows codepages
Verzonden vanuit Outlook Mobilehttps://aka.ms/blhgte
On Fri, Apr 1, 2016 at 11:29 AM -0700, "Meet Bhagdev" <[email protected]notifications@github.com> wrote:
@Nick74khttps://github.com/Nick74k I have created a new issue the non English character issue for better tracking - #80https://github.com/Azure/msphpsql/issues/80.
Let us know if @tschallackahttps://github.com/tschallacka's recommendation works for you. We will investigate this on our end regardless.
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-204503923
Meet,
Any news for the pdo sqlsrv driver for php7 (that supports x64) ?
Do you plan a prerelease soon ?
I really really would like to know why are people requesting for x64 support. I'd love to see a use case where you need > 4Gb on a PHP process.
@David-Garcia-Garcia - The software i work on requires the larger int size provided by a 64bit php. There are many use cases and applications outside of the memory limitation. My company easily exceeds the max int size for 32bit in primary keys on sql tables on a regular basis. Sure, I can code around it, and I have. But having a larger int size helps performance.
Hi all,
We are targeting the week of April 10 for the prerelease of the 64bit AND 32bit variants of the PDO_SQLSRV driver. I will notify this thread with updates as we get closer to the date.
Let me know if you have any questions.
Cheers,
Meet
@David-Garcia-Garcia, a common use case is exporting data to excel spreadsheets that contains more than 100,000 cells
Thanks for the answer @meet-bhagdev !
I am getting a crash in the 64 Bit module. I am using Apache 2.4, Windows 10 & PHP 7.0.4. I am using the same code base that we have in production.
Faulting application name: httpd.exe, version: 2.4.18.0, time stamp: 0x5667fd57
Faulting module name: php7ts.dll, version: 7.0.4.0, time stamp: 0x56d77347
Exception code: 0xc0000005
Fault offset: 0x000000000001ae0d
Faulting process id: 0x2bac
Faulting application start time: 0x01d18e418a22bd23
Faulting application path: D:Program FilesApache24binhttpd.exe
Faulting module path: D:PHPphp7ts.dll
Report Id: 3248c3ef-3559-4c3c-9d4a-5401be16a7f3
Faulting package full name:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: httpd.exe
P2: 2.4.18.0
P3: 5667fd57
P4: php7ts.dll
P5: 7.0.4.0
P6: 56d77347
P7: c0000005
P8: 000000000001ae0d
P9:
P10:
Attached files:
These files may be available here:
C:ProgramDataMicrosoftWindowsWERReportQueueAppCrash_httpd.exe_9860e3bfaaecee75f074070b0e41e269273_75fa684f_2325d7cc
Analysis symbol:
Rechecking for solution: 0
Report Id: 00008176-be42-4321-a08f-913da275e65d
Report Status: 4100
Hashed bucket:
The crash file contents:
Version=1
EventType=APPCRASH
EventTime=131042285770735908
ReportType=2
Consent=1
ReportIdentifier=fb8fc7f0-fa36-11e5-8d96-40e2303c248a
IntegratorReportIdentifier=652b032e-8ad7-4ae2-9eb0-64b1fdcfe282
NsAppName=httpd.exe
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=httpd.exe
Sig[1].Name=Application Version
Sig[1].Value=2.4.18.0
Sig[2].Name=Application Timestamp
Sig[2].Value=5667fd57
Sig[3].Name=Fault Module Name
Sig[3].Value=php7ts.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=7.0.4.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=56d77347
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=000000000001ae0d
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=10.0.10586.2.0.0.256.48
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=b1f0
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=b1f07c44f790817cf33b8c06b56ffd1b
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=915b
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=915b46e626583658430a12e9fb5af458
UI[2]=D:Program FilesApache24binhttpd.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=Apache HTTP Server stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=D:Program FilesApache24binhttpd.exe
LoadedModule[1]=C:WINDOWSSYSTEM32ntdll.dll
LoadedModule[2]=C:WINDOWSsystem32KERNEL32.DLL
LoadedModule[3]=C:WINDOWSsystem32KERNELBASE.dll
LoadedModule[4]=D:Program FilesApache24binlibhttpd.dll
LoadedModule[5]=C:WINDOWSsystem32WS2_32.dll
LoadedModule[6]=C:WINDOWSsystem32sechost.dll
LoadedModule[7]=C:WINDOWSsystem32RPCRT4.dll
LoadedModule[8]=C:WINDOWSsystem32ADVAPI32.dll
LoadedModule[9]=C:WINDOWSsystem32msvcrt.dll
LoadedModule[10]=D:Program FilesApache24binlibaprutil-1.dll
LoadedModule[11]=D:Program FilesApache24binlibapr-1.dll
LoadedModule[12]=C:WINDOWSsystem32SHELL32.dll
LoadedModule[13]=C:WINDOWSsystem32cfgmgr32.dll
LoadedModule[14]=C:WINDOWSsystem32windows.storage.dll
LoadedModule[15]=C:WINDOWSsystem32combase.dll
LoadedModule[16]=C:WINDOWSsystem32bcryptPrimitives.dll
LoadedModule[17]=C:WINDOWSsystem32shlwapi.dll
LoadedModule[18]=C:WINDOWSsystem32GDI32.dll
LoadedModule[19]=C:WINDOWSsystem32USER32.dll
LoadedModule[20]=C:WINDOWSsystem32kernel.appcore.dll
LoadedModule[21]=C:WINDOWSsystem32shcore.dll
LoadedModule[22]=C:WINDOWSsystem32powrprof.dll
LoadedModule[23]=C:WINDOWSsystem32profapi.dll
LoadedModule[24]=C:WINDOWSSYSTEM32VCRUNTIME140.dll
LoadedModule[25]=C:WINDOWSSYSTEM32ucrtbase.dll
LoadedModule[26]=D:Program FilesApache24binpcre.dll
LoadedModule[27]=D:Program FilesApache24binlibapriconv-1.dll
LoadedModule[28]=C:WINDOWSSYSTEM32MSWSOCK.dll
LoadedModule[29]=C:WINDOWSSYSTEM32CRYPTBASE.DLL
LoadedModule[30]=C:WINDOWSSYSTEM32CRYPTSP.dll
LoadedModule[31]=C:WINDOWSsystem32rsaenh.dll
LoadedModule[32]=C:WINDOWSSYSTEM32bcrypt.dll
LoadedModule[33]=D:Program FilesApache24modulesmod_deflate.so
LoadedModule[34]=D:Program FilesApache24binzlib1.dll
LoadedModule[35]=D:Program FilesApache24modulesmod_mime.so
LoadedModule[36]=D:Program FilesApache24modulesmod_rewrite.so
LoadedModule[37]=D:Program FilesApache24modulesmod_expires.so
LoadedModule[38]=D:Program FilesApache24modulesmod_headers.so
LoadedModule[39]=D:Program FilesApache24modulesmod_cache.so
LoadedModule[40]=D:Program FilesApache24modulesmod_socache_dbm.so
LoadedModule[41]=D:Program FilesApache24modulesmod_access_compat.so
LoadedModule[42]=D:Program FilesApache24modulesmod_actions.so
LoadedModule[43]=D:Program FilesApache24modulesmod_alias.so
LoadedModule[44]=D:Program FilesApache24modulesmod_allowmethods.so
LoadedModule[45]=D:Program FilesApache24modulesmod_asis.so
LoadedModule[46]=D:Program FilesApache24modulesmod_auth_basic.so
LoadedModule[47]=D:Program FilesApache24modulesmod_authn_core.so
LoadedModule[48]=D:Program FilesApache24modulesmod_authz_core.so
LoadedModule[49]=D:Program FilesApache24modulesmod_autoindex.so
LoadedModule[50]=D:Program FilesApache24modulesmod_dir.so
LoadedModule[51]=D:Program FilesApache24modulesmod_env.so
LoadedModule[52]=D:Program FilesApache24modulesmod_include.so
LoadedModule[53]=D:Program FilesApache24modulesmod_isapi.so
LoadedModule[54]=D:Program FilesApache24modulesmod_log_config.so
LoadedModule[55]=D:Program FilesApache24modulesmod_negotiation.so
LoadedModule[56]=D:Program FilesApache24modulesmod_setenvif.so
LoadedModule[57]=D:PHPphp7apache2_4.dll
LoadedModule[58]=D:PHPphp7ts.dll
LoadedModule[59]=C:WINDOWSsystem32ole32.dll
LoadedModule[60]=C:WINDOWSsystem32PSAPI.DLL
LoadedModule[61]=C:WINDOWSSYSTEM32DNSAPI.dll
LoadedModule[62]=C:WINDOWSsystem32NSI.dll
LoadedModule[63]=D:PHPextphp_bz2.dll
LoadedModule[64]=D:PHPextphp_curl.dll
LoadedModule[65]=C:WINDOWSsystem32WLDAP32.dll
LoadedModule[66]=C:WINDOWSsystem32Normaliz.dll
LoadedModule[67]=D:Program FilesApache24binLIBEAY32.dll
LoadedModule[68]=D:PHPlibssh2.dll
LoadedModule[69]=D:Program FilesApache24binSSLEAY32.dll
LoadedModule[70]=D:PHPextphp_fileinfo.dll
LoadedModule[71]=D:PHPextphp_gd2.dll
LoadedModule[72]=D:PHPextphp_gettext.dll
LoadedModule[73]=D:PHPextphp_gmp.dll
LoadedModule[74]=D:PHPextphp_intl.dll
LoadedModule[75]=D:PHPicuuc56.dll
LoadedModule[76]=D:PHPicuin56.dll
LoadedModule[77]=D:PHPicuio56.dll
LoadedModule[78]=C:WINDOWSSYSTEM32MSVCP140.dll
LoadedModule[79]=D:PHPicudt56.dll
LoadedModule[80]=D:PHPextphp_imap.dll
LoadedModule[81]=C:WINDOWSsystem32CRYPT32.dll
LoadedModule[82]=C:WINDOWSsystem32MSASN1.dll
LoadedModule[83]=C:WINDOWSSYSTEM32WINMM.dll
LoadedModule[84]=C:WINDOWSSYSTEM32Secur32.dll
LoadedModule[85]=C:WINDOWSSYSTEM32WINMMBASE.dll
LoadedModule[86]=C:WINDOWSSYSTEM32SSPICLI.DLL
LoadedModule[87]=D:PHPextphp_mbstring.dll
LoadedModule[88]=D:PHPextphp_exif.dll
LoadedModule[89]=D:PHPextphp_openssl.dll
LoadedModule[90]=D:PHPextphp_pdo_odbc.dll
LoadedModule[91]=C:WINDOWSSYSTEM32ODBC32.dll
LoadedModule[92]=C:WINDOWSSYSTEM32DPAPI.dll
LoadedModule[93]=D:PHPextphp_sockets.dll
LoadedModule[94]=C:WINDOWSSYSTEM32IPHLPAPI.DLL
LoadedModule[95]=D:PHPextphp_tidy.dll
LoadedModule[96]=D:PHPextphp_sqlsrv_7_ts.dll
LoadedModule[97]=C:WINDOWSsystem32msodbcsql11.dll
LoadedModule[98]=C:WINDOWSsystem32OLEAUT32.dll
LoadedModule[99]=C:WINDOWSsystem32NETAPI32.dll
LoadedModule[100]=C:WINDOWSsystem32COMDLG32.dll
LoadedModule[101]=C:WINDOWSsystem32FirewallAPI.dll
LoadedModule[102]=C:WINDOWSsystem32VERSION.dll
LoadedModule[103]=C:WINDOWSWinSxSamd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.10586.0_none_396e892957c7fb25COMCTL32.dll
LoadedModule[104]=C:WINDOWSsystem32MSVCR100.dll
LoadedModule[105]=C:WINDOWSsystem32DAVHLPR.DLL
LoadedModule[106]=C:WINDOWSsystem32fwbase.dll
LoadedModule[107]=C:WINDOWSSYSTEM32MTXDM.DLL
LoadedModule[108]=C:WINDOWSsystem32clbcatq.dll
LoadedModule[109]=C:WindowsSystem32comsvcs.dll
LoadedModule[110]=C:WINDOWSsystem321033msodbcsqlr11.rll
LoadedModule[111]=C:WINDOWSsystem32CLUSAPI.DLL
LoadedModule[112]=C:WINDOWSSYSTEM32ncrypt.dll
LoadedModule[113]=C:WINDOWSSYSTEM32NTASN1.dll
LoadedModule[114]=C:WINDOWSsystem32RESUTILS.DLL
LoadedModule[115]=C:WINDOWSsystem32security.dll
LoadedModule[116]=C:WINDOWSsystem32schannel.DLL
LoadedModule[117]=C:Program FilesMicrosoft SQL Server90Sharedinstapi.dll
LoadedModule[118]=C:WINDOWSWinSxSamd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9193_none_88e4514b2faac6c7MSVCR80.dll
LoadedModule[119]=C:WINDOWSSYSTEM32mskeyprotect.dll
LoadedModule[120]=C:WINDOWSsystem32ncryptsslp.dll
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=Apache HTTP Server
AppPath=D:Program FilesApache24binhttpd.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=5DB4A09869DD73F016080CF76D0925EA
Hi Folks,
Great to see so much interest in the new drivers. This issue has effectively become the announcement location for the new drivers as they trickle out. Can I make a suggestion that any issues that you run into when you try out the new releases be logged as brand new issues? Most people who are starting to work with the new drivers will not know to come review this one issue for possible problems. I would think it would be more effective to have each new issue logged separately so we can all participate in the trouble shooting. And this issue has become very, very long ;-)
Best Regards, and thanks for all the hard work.
Couldn't agree with @MCF more. Please create new issues on GitHub if you feel there is a bug we need to investigate.
@DigitalSolo I have created a new issue for your crash report - https://github.com/Azure/msphpsql/issues/82
Cheers,
Meet
Hello! How i can find pdo_sqlsrv.dll x64 driver for windows?
@Slavenin not out yet for php7, reading this issue would help you a lot next time
I see the pdo drivers are now available, which is great news! Thanks guys!
Would it be possible to make the pre-compiled binaries available as they are for the sqlsrv driver?
Thanks
@qqzm Good catch! This is done. Please check :) Alternatively you can always find the binaries in the releases - https://github.com/Azure/msphpsql/releases/tag/v4.0.3
@Slavenin The PDO drivers are now out! Please give it a shot and let us know what feedback you have.
Hey,
i'm very happy about the new driver and thank you guys a lot for all your work. I prepared a new release of a web application locally. Therefor i downloaded the latest Xampp version with PHP 7 and hoped that the driver will give me the possibility to connect to the Sql-Server database... Unfortunatelly it didn't worked.
If i restart the xampp server and have a look at the phpinfo page the pdo und sqlserver driver weren't shown there... So it seemed to be, that the dll aren't recognized... The same procedure runs for me with the older 5.6PHP version and the 5.6-dll files...
Is there a configuration mistake of myself or an error in the dll files?
Thank's for your help and response!
Have a nice day!
V
Does the pdo driver show up in phpinfo()? What does your php errors log say about the incompatability? What does the apache log say?
Have you tried just plain apache without xampp?
Verzonden vanuit Outlook Mobilehttps://aka.ms/blhgte
On Sat, Apr 16, 2016 at 9:54 AM -0700, "Der-V" <[email protected]notifications@github.com> wrote:
Hey,
i'm very happy about the new driver and thank you guys a lot for all your work. I prepared a new release of a web application locally. Therefor i downloaded the latest Xampp version with PHP 7 and hoped that the driver will give me the possibility to connect to the Sql-Server database... Unfortunatelly it didn't worked.
If i restart the xampp server and have a look at the phpinfo page the pdo und sqlserver driver weren't shown there... So it seemed to be, that the dll aren't recognized... The same procedure runs for me with the older 5.6PHP version and the 5.6-dll files...
Is there a configuration mistake of myself or an error in the dll files?
Thank's for your help and response!
Have a nice day!
V
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-210856974
@Der-V : I created a new issue to track this. Would love to know the answers to @tschallacka's questions.
Hey everybody,
it's me again. I don't want to spam this thread here and to be honest i'm not sure, if there is a bug with this driver or there other circumstances. So I only want to tell you my observations.
I've got a web application written with the cakephp framework... Until saturday i used one of the latest versions and the xampp installation with php 5.6 and the suiteable sqlserver driver. After the release of the new driver, i downloaded the latest xampp version with PHP 7.0.4 and later on also the latest cake-verion 3.2....
Let's come to my problem:
I execute an insert, with an boolean column. In 5.6 everything work's fine. When I now which to the 7.04 version always a true will be inserted. Nothing has change besides, the xampp, php-verion (5.6 -> 7) and the driver. When i debug the sql which is executed, i got the following result
INSERT INTO TABLE ([col]) Values(0)
So i would expect that false will be saved.
Sure i could be possible there are some changes in the xampp or php version that lead to that error, but i google a lot and i found nothing about an error like this...
So my question ist, could it be possible that there is an error in the driver, that doesn't translate the value correctly to real boolean?
I hope the question is allowed to ask here... otherwise i would try find an evidence that the other components or myself are the reason of that mistake.
Thank's for your effort to have a look at it.
V
Sqlserver doesnt do booleans, it does bit. It saves a boolean false as 0 and boolean true as 1.
Verzonden vanuit Outlook Mobilehttps://aka.ms/blhgte
On Mon, Apr 18, 2016 at 3:01 AM -0700, "Der-V" <[email protected]notifications@github.com> wrote:
Hey everybody,
it's me again. I don't want to spam this thread here and to be honest i'm not sure, if there is a bug with this driver or there other circumstances. So I only want to tell you my observations.
I've got a web application written with the cakephp framework... Until saturday i used one of the latest versions and the xampp installation with php 5.6 and the suiteable sqlserver driver. After the release of the new driver, i downloaded the latest xampp version with PHP 7.0.4 and later on also the latest cake-verion 3.2....
Let's come to my problem:
I execute an insert, with an boolean column. In 5.6 everything work's fine. When I now which to the 7.04 version always a true will be inserted. Nothing has change besides, the xampp, php-verion (5.6 -> 7) and the driver. When i debug the sql which is executed, i got the following result
INSERT INTO TABLE ([col]) Values(0)
So i would expect that false will be saved.
Sure i could be possible there are some changes in the xampp or php version that lead to that error, but i google a lot and i found nothing about an error like this...
So my question ist, could it be possible that there is an error in the driver, that doesn't translate the value correctly to real boolean?
I hope the question is allowed to ask here... otherwise i would try find an evidence that the other components or myself are the reason of that mistake.
Thank's for your effort to have a look at it.
V
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/msphpsql/issues/58#issuecomment-211306180
Hey tschallacka
yes, of course that's right. I'm sorry for my incorrect wording. As you can see in the SQL I give a 0 for a false value with it. The table in the sqlserver got the datatype bit. So in my understanding everything is correctly configured concerning that point and the a false or a 0 should be saved.
If i excecute the same sql query, i debugged out of the application, directly in the sql management studio, everything is fine and correctly inserted. And i see in the debugged query that the sql is correctly built and interpretated by the application. So it seems that anything between create an error. That's why i could imagine that there is a possible error in the driver!?
Kind regards
V
@Slavenin The PDO drivers are now out! Please give it a shot and let us know what feedback you have.
@meet-bhagdev Thank you so much! My project is work fine!
@Der-V : We will look into this and get back to you. Will let you know if we have any questions.
@Slavenin : Glad its working out for you.
@all: We are starting work on the Linux driver for SQL Server and PHP. We would like to understand what versions and distros of Linux do you use. If you are interesting in using PHP on Linux to connect to SQL Server, please spend a few seconds to complete this survey to help us prioritize our efforts.
https://www.surveymonkey.com/r/FBCGJQ3
@meet-bhagdev Thanks! Sorry I didn't see the binaries in the releases, I was just looking on the main page.
I've been playing with the x64 PDO drivers all day today and everything looks great as far as I can tell. All our sites seem to be working correctly and significantly faster than with PHP 5.6.
Thanksfor all your hard work getting this out, great job guys!
@meet-bhagdev: I made some more tests about that observation concerning the booleans. I got the same problem with selects.... I execute that queries directly with the php sql_server methods and everything works fine. So the error is still existing but it seemed to be a problem of the framework and not of the driver, because the direct way without the ORM works fine. I let you know if there are some news.
I have to thank you for your work.
Hi @meet-bhagdev great job with this driver and sorry for not follow properly all bugs reported by me, this week I will have time to try and test more properly.
I have several questions:
Regards
hi I downloaded the PDO driver copied 'php_pdo_sqlsrv_7_ts.dll' in to the ext folder of the php. when I tried a sample page with connecting to SQL server 2014 igot the message "could not find driver".
any idea why?.....
Is there an estimated date for the Linux drivers - either PDO or SQLSRV?
You also need to register it in your php.ini.
extension=php_pdo_sqlsrv_7_ts.dll
Btw, if you use IIS, use the _nts DLL instead of the _ts.
@maneshmathew I had the same error message, so yours issue may be the same as mine. I'd accidentally downloaded a html file instead of the dll. I later found you need to click "raw" before downloading otherwise GitHub gives you a random page named as php_pdo_sqlsrv_7_ts.dll.
Hi guys I resolved it . I downloaded the 64 bit version instead of x86 and had to download the of course 11 driver for sale server . Now it's working. Thanks guys for the input .
Sent from my iPad
On 26 Apr 2016, at 17:40, qqzm [email protected] wrote:
@maneshmathew I had the same error message, so yours issue may be the same as mine. I'd accidentally downloaded a html file instead of the dll. I later found you need to click "raw" before downloading otherwise GitHub gives you a random page named as php_pdo_sqlsrv_7_ts.dll.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
are there any plans for the linux version? is it imminent?
@Der-V, I got the same issue with php 7.05, sql server, x64 pdo driver and Yii2 framework. Selects are not working with booleans in filter.
Here is pdo statement debug dump params:
SQL: [133] SELECT * FROM [Scripts] WHERE ([Hidden]=:qp0) AND ([TaggedRemoved]=:qp1) ORDER BY (SELECT NULL) OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY
Params: 2
Key: Name: [4] :qp0
paramno=0
name=[4] ":qp0"
is_param=1
param_type=5
Key: Name: [4] :qp1
paramno=1
name=[4] ":qp1"
is_param=1
param_type=5
I also tried PDO::PARAM_INT, not working on "bit" datatype column.
@ jadrovski: I referenced this issue here for about 9 days. So i hope there is a solution in the next weeks... But it seems that the frameworks doesn't test and doesn't have a suiteable test environment for the combination php7 and sqlserver, because of the recent release of the driver....I would expect, that other framework got the same problems...
If you have any result from the Yii2-Framework, that's a driver issue, please let us know :)
@Der-V, looks like its not a framework problem. Its probably somewhere in PDOStatement class.
@sdh100shaun : We are working actively on the Linux version. Will keep you posted with regards to dates over the next few week.
@Der-V and @jadrovski : We will investigate this!
Hey,
I only wanted du ask if there are any news concerning the possible bug? Currently i'm still not able to use the lastest version because of that problem. That's why I wanted to ask friendly if there are any news :) or if you could guess when it could be possible that i can receive a solution?
Thank's for your response
I'm using Apache 2.4 with php 7.0.6, both MSVC14 x64 and runing under windows 7 x64.
On my main website when I make a select statement which return a large amout of data, php-cgi.exe dies when I'm under fcgid mod and Apache.exe dies when I'm in mod_php.
Apache log :
[fcgid:warn] [pid 8928:tid 1440](OS 109)The pipe has been ended. : [client ::1:53113] mod_fcgid: get overlap result error
[core:error] [pid 8928:tid 1440] [client ::1:53113] End of script output before headers: app.php
Windows event log :
Nom de l’application défaillante php-cgi.exe, version : 7.0.6.0, horodatage : 0x57227745
Nom du module défaillant : php7ts.dll, version : 7.0.6.0, horodatage : 0x57227f4d
Code d’exception : 0xc00000fd
Décalage d’erreur : 0x00000000001c34b4
ID du processus défaillant : 0x7bc
Heure de début de l’application défaillante : 0x01d1a9bbab5fe0a8
Chemin d’accès de l’application défaillante : C:phpphp-cgi.exe
Chemin d’accès du module défaillant: C:phpphp7ts.dll
ID de rapport : eb955272-15ae-11e6-b84b-08002700e8d1
@Der-V @jadrovski : I have created a new bug for better tracking the issue with Booleans - https://github.com/Azure/msphpsql/issues/93
@christophe77 : I have a created a new bug for better tracking the issue of php-cgi crashing
https://github.com/Azure/msphpsql/issues/94
@meet-bhagdev
Hello , do you guys have any updates on the linux version?
Thanks a lot for working on this
@ValentinStefanescu : We are almost done with ironing out all the kinks and unknowns for the Linux driver. We will have a date to share with you very soon! What kind of timeline are you targeting?
Thanks,
Meet
I am tied up on other projects for the next month but would like to start testing asap after then.
@meet-bhagdev Thank you for your answer, that sounds great!
If it would be functional on linux in something like one month would be amazing.
Thank again,
Vali
@ValentinStefanescu Thanks, We still do not have a date but I plan to share one out as soon as possible! Will keep you posted. Do keep in mind that this is the first time we are releasing the driver on Linux thus it will be and early preview.
Dear @meet-bhagdev ,
Since brand new SQL Server 2016 released yesterday,
any news on the RTM release of the new drivers?
Hello @mlhkr
We are targeting the RTM release for the PDO_SQLSRV and SQLSRV (64bit and 32bit) drivers for Windows in the next 4-6 weeks. Should this date change, I will keep everyone here posted.
@all if you have feedback/issues/questions about the preview bits that we have released, please let us know as soon as possible. We will try to address it before our release.
Let me know if you have any questions. I appreciate everyone's inputs. We are almost there :)
Thanks,
Meet
@meet-bhagdev Any plans on dealing with broken prepared statements and type binding in client buffered queries?
https://github.com/Azure/msphpsql/issues/92
https://github.com/Azure/msphpsql/issues/71
https://github.com/Azure/msphpsql/issues/63
I'd love to hear a statement on this, we are completely holding back on any real D8 projects, I hoped some of these might get fixed for PHP7 and your increasing effort in this driver. Management has been pushing for a long time to completely move to LAMP stack. Thanks to --E from the IIS team we managed to solved the PHP on IIS issues and that has helped hold off the move for a while, but the inability to properly work with floats/decimals is a complete show stopper.
Very glad to see the Linux version is on the horizon at least.
@david-garcia-garcia We are looking into the issues with broken prepared statements and type binding in client buffered queries. Of the three issues you mentioned which one would you like us to prioritize? These bug fixes will likely land in one of out 3-week releases post our June release.
The most critical issue is broken type binding in client buffered queries:
https://github.com/Azure/msphpsql/issues/71
I expect data returned by statements to be exactly the same, wether I use client buffered queries or not.
Broken prepared statements has a "contained" impact because I just use them as a workaround for two situations of the MSSQL PDO Driver:
That means that I can turn off completely usage of prepared statements and pray that none of the situations above takes place. But fixing prepared statements won't harm.
BTW, deep thanks for your work on this driver. Hope this results in increased adoption of the WIMP stack.
This realease will be compatible with PHP 7.1? and ODBC 13?
@david-garcia-garcia : Sounds good! We will prioritize accordingly :+1:
@sirio3mil : The latest release is compatible PHP 7.0.7 and ODBC 13. Once PHP 7.1 is released, we will certainly support it :+1:
@all We are excited to announce the Release Candidate for the PHP Driver 4.0 for SQL Server. Major emphasis of this release was to add ODBC 13 support and bug fixes:
You can fetch the binaries from here. Also check out the updated README file here
Let us know if you have any questions.
SQL Server Engineering Team
Thanks @meet-bhagdev, tested and work fine, it detect automaticly ODBC 13 and use it.
@meet-bhagdev where is the source code for these? The PHP-7.0-Linux branch contains no source at all, and you haven't checked the files required for the PHP build system in to the PHP-7.0 branch either...
@meet-bhagdev any update about 2100 parameters limit that @david-garcia-garcia mention ? MySQL has ~65,000 and Oracle ~64,000
@LukeCarrier We will very soon be updating the code to the Linux branch. Just cleaning up a couple of things and getting the appropriate build instructions documented.
Also what are the build files you are looking for? The config.w32 files are in the PHP7 branch.
@aymanstar Just so that I understand you are talking about the limit set by SQL Server that only allows a max of 2100 parameters per query. Correct?
@meet-bhagdev the config.w32 files are specifically for the Windows build system -- I need the config.m4 files to build under Linux. Would it not make more sense to release the work in progress source to foster collaboration?
@LukeCarrier Definitely agreed! Give us a few days and we will have the required config files along with proper build instructions and the source code for Linux added to the repository. Look forward to collaborating with you :)
@All we recently release a production ready build of the PHP Driver 4.0 for SQL Server with PHP 7 support for Windows. You can fetch the latest binaries from:
You can find the detailed release notes here.
We will continue to keep improving the driver by making bug fixes for issues reported on GitHub (for eg #92 ,#97, #93 , #71, #63) and adding new features. We will try to do a release every 3-4 weeks.
Can you please take this survey to help us guide our priorities going forward? Make sure your voice is heard :)
Thanks,
SQL Server Engineering Team
@meet-bhagdev Just tried out the production ready release for our PHP 7 app. Works great. Really enjoying the perf gains. Thank you for you are your teams dedication. Keep releasing and we happy to help out as and when needed. I have also taken the survey. Hope it helps you out.
@meet-bhagdev Any prediction when sqlsrv and pdo_sqlsrv will be part of webapps when switching PHP verision to v7.0? As of now, drivers are not yet compiled there by default.
@renecatharsis Should be very soon. I will connect with the engineer working on this and try to get a date by when you can expect it to land.
@meet-bhagdev Any update on the release schedule? The extensions are not yet compiled into the PHP7 runtime on webapps.
@renecatharsis Deployment has started rolling out. Can you check now?
@all we released new previous for Windows and Linux. Find them below:
https://github.com/Microsoft/msphpsql/releases/tag/4.0.4-Linux
https://github.com/Microsoft/msphpsql/releases/tag/4.1.2-Windows
If you have any questions, do let us know.
Thanks,
Meet
Drivers are pre-compiled now, thanks a lot.
Will do some testing.
Hi all, the April survey is now up: https://www.surveymonkey.com/r/QBMNPH9. Please take this survey to help us improve our efforts with the driver.
Hi folks, do you guys know where can I find a good resource to teach me how can I connect my SQl Server to my Wamp ( Server ) ?
What you download and install depends on what version of PHP you're using.
A decent start is: https://docs.microsoft.com/en-us/sql/connect/php/loading-the-php-sql-driver?view=sql-server-2017
https://github.com/Microsoft/msphpsql/releases
Microsoft's ODBC drivers: https://www.microsoft.com/en-us/download/details.aspx?id=53339
Kind of off the top of my head.
Closing due to inactivity. Please reopen if necessary, but create new issues for distinct feature requests.
Most helpful comment
Hi Folks,
Great to see so much interest in the new drivers. This issue has effectively become the announcement location for the new drivers as they trickle out. Can I make a suggestion that any issues that you run into when you try out the new releases be logged as brand new issues? Most people who are starting to work with the new drivers will not know to come review this one issue for possible problems. I would think it would be more effective to have each new issue logged separately so we can all participate in the trouble shooting. And this issue has become very, very long ;-)
Best Regards, and thanks for all the hard work.