-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is PDO::ATTR_PERSISTENT supported by the PDO driver? #65
Comments
As a follow on to this question. It appears that setting the PDO::ATTR_PERSISTENT attribute to true with this driver will cause intermittent crashes and timeouts when attempting to connect to the database. The crashes tend to be silent failures as well (no exceptions thrown, etc.). Hard to diagnose as a result. I would strongly recommend never setting that attribute with this driver. A note to the driver maintainers - if that attribute cannot be supported and/or is not needed (which I suspect is the case) perhaps the attribute should be ignored, or throw an error when it is set in all cases? |
Hi @MCF , As of release 4.1.8-preview, when the user specify Please double check if the issue still exists and update us. |
throws |
@silva96 , PDO::ATTR_PERSISTENT is not supported in the PDO_SQLSRV driver. Previously, a persistent DBH is made in the PDO side but the PDO_SQLSRV driver didn't clean this up properly thus resulting in intermittent crash. As of release 4.1.8-preview, |
This is either a bug report or a question regarding the PDO::ATTR_PERSISTENT attribute - depending on what the facts are. My initial question is: is the option supported? The reason I ask is because it appears that you can set the option when you create a new PDO connection, and you can read the option back using getAttribute(PDO::ATTR_PERSISTENT) - seeming to imply that it is supported. But only if you are careful with the order of the options in the call to the PDO constructor.
This, for example, will work and set the option:
But changing the order of the options will throw an exception. This call:
will result in this exception message and a failure to connect:
This blog entry from Microsoft when these new drivers were first released noted that ODBC connection pooling is used instead of the persistent connection offered by other older, non-microsoft drivers.
So should one ever use ATTR_PERSISTENT? If yes to that question, why does the second code example throw an exception? If no why is it even exposed by the driver - or at the very least why is it not simply ignored (as I mentioned above, the first code example does succeed in the setting the option)?
FWIW the following versions were used for the testing:
The text was updated successfully, but these errors were encountered: