Hi.
With regard to http://bugs.php.net/bug.php?id=46971, how much effort
is needed (if any) to document that some functionality is not going to
be available in all windows builds? [DOC]
Or,
When will VC6 be dropped? [CORE and DOC]
Admittedly, it is only an issue for Microsoft SQL Server (mssql and
pdo_mssql) and for Sybase_ct.
With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
2008/12/31 Richard Quadling rquadling@googlemail.com:
With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?
http://www.codeplex.com/SQL2K5PHP is another link for this extension.
Regards,
Richard.
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hi Richard,
I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly
map into servers may have problems if using the wrong CRT. Until now, I had
no time to build up a Windows "Sun Java System Webserver" and test it with
both CRTs. The code compiles fine on the snaps box, but I am not sure, if
the DLL loads into the server.
To the snaps build: The NSAPI module tests for "#define ZTS" and does
therefore not compile without thread safety. Why do the windows non-ts
builds on snaps.php compile? Is ZTS on windows always defined (it looks like
so in the makefile). How to test on windows, if thread safety is available?
But better would be to disable thread-unsafe builds for the NSAPI SAPI from
the beginning.
Uwe
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-----Original Message-----
From: Richard Quadling [mailto:rquadling@googlemail.com]
Sent: Wednesday, December 31, 2008 11:12 AM
To: PHP Documentation ML; PHP Developers Mailing List
Subject: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL
Driver.Hi.
With regard to http://bugs.php.net/bug.php?id=46971, how much effort
is needed (if any) to document that some functionality is not going to
be available in all windows builds? [DOC]Or,
When will VC6 be dropped? [CORE and DOC]
Admittedly, it is only an issue for Microsoft SQL Server (mssql and
pdo_mssql) and for Sybase_ct.With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Uwe Schindler wrote:
I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly
map into servers may have problems if using the wrong CRT. Until now, I had
no time to build up a Windows "Sun Java System Webserver" and test it with
both CRTs. The code compiles fine on the snaps box, but I am not sure, if
the DLL loads into the server.
Precisely. Note that httpd 2.4 (.next) will not be compiled with VC6, but
may continue to use msvcrt.dll - if I successfully validate a proper method
(which might rely on some sdk/wdk includes) for continuing to use this
lowest common denominator crt with sources compiled on modern compilers,
I'll be sure to send this feedback in. 99% certain that the classic method
is simply wrong (link32 msvcrt.lib /ignore:msvcrXX.lib) since the correct
clib headers corresponding to msvcrt are required to avoid abi issues.
hi William,
On Fri, Jan 2, 2009 at 5:01 PM, William A. Rowe, Jr.
wrowe@rowe-clan.net wrote:
Uwe Schindler wrote:
I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly
map into servers may have problems if using the wrong CRT. Until now, I had
no time to build up a Windows "Sun Java System Webserver" and test it with
both CRTs. The code compiles fine on the snaps box, but I am not sure, if
the DLL loads into the server.Precisely. Note that httpd 2.4 (.next) will not be compiled with VC6, but
may continue to use msvcrt.dll - if I successfully validate a proper method
(which might rely on some sdk/wdk includes) for continuing to use this
lowest common denominator crt with sources compiled on modern compilers,
I'll be sure to send this feedback in. 99% certain that the classic method
is simply wrong (link32 msvcrt.lib /ignore:msvcrXX.lib) since the correct
clib headers corresponding to msvcrt are required to avoid abi issues.
I'm not sure it is worth the effort. What would be the gains besides
not having to distribute the 9.0 CRT (which is a non issue for the
installers and a one time install for the other)?
Cheers,
Pierre
hi Richard,
On Wed, Dec 31, 2008 at 11:11 AM, Richard Quadling
rquadling@googlemail.com wrote:
Hi.
With regard to http://bugs.php.net/bug.php?id=46971,
Can you repost (and subscribe to the list if you did not subscribe
yet) to the right list please (Windows Internals list)?
Thanks,
Pierre
With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?
I do not see us adding a new RDBMS specific extension that only works
on one OS (that is not even our main target OS in practice for
deployment) for an RDBMS that is also quite a niche solution for PHP.
Actually the only RDBMS where I am willing to currently consider a new
non PDO extension sqlite.
As such I do not think we should consider bundling this extension, let
alone have it replace the php_mssql.dll.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
target OS in practice for deployment) for an RDBMS that is also
quite a niche solution for PHP. Actually the only RDBMS where I am
willing to currently consider a new non PDO extension sqlite.
Just to make it clear what I was talking about here (there is an "is"
missing in front of sqlite):
http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite3/
And sqlite3 is already in 5.3 ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2009/1/5 Lukas Kahwe Smith mls@pooteeweet.org:
With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?I do not see us adding a new RDBMS specific extension that only works on one
OS (that is not even our main target OS in practice for deployment) for an
RDBMS that is also quite a niche solution for PHP. Actually the only RDBMS
where I am willing to currently consider a new non PDO extension sqlite.As such I do not think we should consider bundling this extension, let alone
have it replace the php_mssql.dll.
Even though it will most likely be the case that php_mssql.dll will
not be available for later versions of PHP/CRT/etc.
Or, are you saying that PHP support for MSSQL is via ODBC only (I
don't know if php_pdo_mssql uses ntwdblib.dll like php_mssql and as
such suffers in the same way).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
2009/1/5 Lukas Kahwe Smith mls@pooteeweet.org:
With Microsoft having their own PHP extension for talking to MSSQL
(http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx -
though documented to only support SQL 2005 and 2008, not 7 or 2000),
could this become the standard alternative for php_mssql.dll (though
not PDO as the MS extension is procedural only, leaving ODBC as the
route for older versions?I do not see us adding a new RDBMS specific extension that only
works on one
OS (that is not even our main target OS in practice for deployment)
for an
RDBMS that is also quite a niche solution for PHP. Actually the
only RDBMS
where I am willing to currently consider a new non PDO extension
sqlite.As such I do not think we should consider bundling this extension,
let alone
have it replace the php_mssql.dll.Even though it will most likely be the case that php_mssql.dll will
not be available for later versions of PHP/CRT/etc.Or, are you saying that PHP support for MSSQL is via ODBC only (I
don't know if php_pdo_mssql uses ntwdblib.dll like php_mssql and as
such suffers in the same way).
What I am saying is that ext/mssql should be kept alive as long as we
keep the other "native" RDBMS ext around. Even if its not possible to
keep it alive for this long for whatever reason, users should be
directed at PDO.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org