#45921 [Opn]: Can't initialize character set hebrew (path: C:\mysql\\share\charsets\)
ID: 45921
User updated by: ymagriso at gmail dot com
Reported By: ymagriso at gmail dot com
Status: Open
Bug Type: MySQLi related
Operating System: Windows XP/SP3
PHP Version: 5.2.6
New Comment:
I found a solution to the problem.
The problem is related to php_mysqli.dll that comes with the PHP
installer package.
I downloaded another version of the DLL from MySQL website:
http://dev.mysql.com/get/Downloads/Connector-PHP-mysqlnd/php_5.2.1-mysqlnd-5.0.1-beta.zip/from/pick
I replaced the "faulty" DLL (that came with the PHP installer package)
with the one I downloaded from MySQL website, then restarted the
webserver and the problem was gone.
I would recommend to check the php_mysqli.dll that comes with the PHP
installer package.
Previous Comments:
[2008-08-31 12:54:58] ymagriso at gmail dot com
I just wanted to add another comment.
I called the following queries via PHP using MySQLi:
1) show character set
2) show variables like "%character%"
Surprisingly, I got exactly the same results as via "mysql" client.
So, the problem seems to be related to the mysqli::set_charset(). I
could not find anywhere in "php.ini" or "my.ini" (MySQL) that path
defined ("C:\mysql\\share\charsets\").
My guess is that the path "C:\mysql\\share\charsets\" is hardcoded
within the method in the MySQLi library (php_mysqli.dll).
[2008-08-29 07:08:26] ymagriso at gmail dot com
As I stated in the original message the SET NAMES actually works fine
as a workaround (no error and the character set is changed to
"hebrew").
As for the list of available character sets:
mysql> show character set;
+--+-+-++
| Charset | Description | Default collation | Maxlen
|
+--+-+-++
| big5 | Big5 Traditional Chinese| big5_chinese_ci | 2
|
| dec8 | DEC West European | dec8_swedish_ci | 1
|
| cp850| DOS West European | cp850_general_ci| 1
|
| hp8 | HP West European| hp8_english_ci | 1
|
| koi8r| KOI8-R Relcom Russian | koi8r_general_ci| 1
|
| latin1 | cp1252 West European| latin1_swedish_ci | 1
|
| latin2 | ISO 8859-2 Central European | latin2_general_ci | 1
|
| swe7 | 7bit Swedish| swe7_swedish_ci | 1
|
| ascii| US ASCII| ascii_general_ci| 1
|
| ujis | EUC-JP Japanese | ujis_japanese_ci| 3
|
| sjis | Shift-JIS Japanese | sjis_japanese_ci| 2
|
| hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1
|
| tis620 | TIS620 Thai | tis620_thai_ci | 1
|
| euckr| EUC-KR Korean | euckr_korean_ci | 2
|
| koi8u| KOI8-U Ukrainian| koi8u_general_ci| 1
|
| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2
|
| greek| ISO 8859-7 Greek| greek_general_ci| 1
|
| cp1250 | Windows Central European| cp1250_general_ci | 1
|
| gbk | GBK Simplified Chinese | gbk_chinese_ci | 2
|
| latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1
|
| armscii8 | ARMSCII-8 Armenian | armscii8_general_ci | 1
|
| utf8 | UTF-8 Unicode | utf8_general_ci | 3
|
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2
|
| cp866| DOS Russian | cp866_general_ci| 1
|
| keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci | 1
|
| macce| Mac Central European| macce_general_ci| 1
|
| macroman | Mac West European | macroman_general_ci | 1
|
| cp852| DOS Central European| cp852_general_ci| 1
|
| latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1
|
| cp1251 | Windows Cyrillic| cp1251_general_ci | 1
|
| cp1256 | Windows Arabic | cp1256_general_ci | 1
|
| cp1257 | Windows Baltic | cp1257_general_ci | 1
|
| binary | Binary pseudo charset | binary | 1
|
| geostd8 | GEOSTD8 Georgian| geostd8_general_ci | 1
|
| cp932| SJIS for Windows Japanese | cp932_japanese_ci | 2
|
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3
|
+--+-+-++
36 rows in set (0.05 sec)
mysql>
The character set "hebrew" is there.
As for your last request, the "my.ini" does not include any statement
regarding the "character_sets_dir".
Adding it as advised in MySQL documentation does not help in this
#45954 [Bgs]: memory leak with unset(array)
ID: 45954 User updated by: mail at milianw dot de Reported By: mail at milianw dot de Status: Bogus Bug Type: Performance problem Operating System: * PHP Version: 5.2.6 New Comment: So there is simply no way at all to delete / free / unset variables in PHP? But why does it work perfectly (i.e. like I imagine it should) when I unset a string, even a very large one? That one frees the memory instantaneously. But not so for arrays. I simply cannot see the reasoning behind this. When a programmer calls unset he seems to know that this very variable can be freed, or not? So why do we need to wait for a GC to step in and do the actual cleanup? As far as my limited knowledge goes manual delete/free is compatible with a GC, or not? Or is it only possible to free simple strings, ints etc. but not arrays? Take this code: http://bugs.php.net/bug.php?id=41713 which tells a similar story, but it should be fixed as far as the bug report tells. Additionally it was Windows only yet I spotted the described behaviour first on a Linux machine. -- Edit this bug report at http://bugs.php.net/?id=45954&edit=1
#45966 [NEW]: SoapServer does not report WSDL validation errors
From: chammers at netcologne dot de
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: SOAP related
Bug description: SoapServer does not report WSDL validation errors
Description:
When receiving a SOAP request, SoapServer does not properly validate if it
matches the given WSDL.
Invalid elements are simply surpressed and not passed through to the
called function.
I would expect the SoapServer->handler() to raise an Exception so that the
program can decide if it terminates or go ahead with all parameters it can
get.
bye,
-christian-
Reproduce code:
---
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.foo.de/services/exampleService";>
1000
815
EOF;
$server = new SoapServer("chammers.wsdl");
$server->setClass('DummyClass');
$server->handle($HTTP_RAW_POST_DATA);
And the WSDL (here "chammers.wsdl")
http://schemas.xmlsoap.org/wsdl/http/";
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:tns="http://www.foo.de/services/exampleService";
targetNamespace="http://www.foo.de/services/exampleService";>
http://www.w3.org/2001/XMLSchema";
targetNamespace="http://www.foo.de/services/exampleService";>
http://schemas.xmlsoap.org/soap/http"/>
http://soap.foo.de/services/example"/>
http://localhost:4080/services/exampleServices"/>
Expected result:
As the request parameter "aaa" has a typo and is actually written as
"" I would expect an Exception or at least some kind of warning.
Actual result:
--
... but the handler class just gets the "bbb" parameter:
$ php chammers.php
Method example was called with array (
0 =>
stdClass::__set_state(array(
'bbb' => 815,
)),
)
--
Edit bug report at http://bugs.php.net/?id=45966&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45966&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45966&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45966&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45966&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45966&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45966&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45966&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45966&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45966&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45966&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45966&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45966&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45966&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45966&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45966&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45966&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45966&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45966&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45966&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45966&r=mysqlcfg
#42318 [Asn->Csd]: problem with nm not finding object files
ID: 42318 Updated by: [EMAIL PROTECTED] Reported By: rainer dot tammer at schulergroup dot com -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: AIX 5.2/5.3 PHP Version: 5.2CVS-2007-08-17 Assigned To: dmitry New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-08-28 14:24:43] rainer dot tammer at schulergroup dot com Hello, just to clarify: The .libs is only in use when you build DSO (in my case for Apache). If I do not build with DSO then the build runs just fine (php + cgi will be build). If I build with DSO then the php build is OK too (with the modified files). Bye Rainer [2008-08-28 09:02:58] [EMAIL PROTECTED] I can understand you troubles with CLI, but I'm wondered, how you can have problems with CGI if you build DSO for Apache. [2008-08-28 07:49:10] rainer dot tammer at schulergroup dot com Hello, the problem only exists if you build the dso for Apache. If you only build php (stand alone) then you do not need the .libs directory. I am using libtool 1.5.20 (bundled with PHP). I have access to AIX 5.2 / 5.3 / 6.1 (maybe 5.1 / 4.3.3 very old dev environment). Regarding the access to an newer AIX machine: The problem is the access from the internet. If you like we can switch to pm an we can discuss this problem. Bye Rainer [2008-08-28 07:41:39] [EMAIL PROTECTED] I was never able to reproduce this build failure. The "fixed" configs worked fine for me on AIX, however build doesn't work with ".libs". I assume something may be different in libtools in different systems. For now I have access only to AIX 5.1. I'll able to fix the bug if somebody gives me access to AIX 5.2/5.3. [2008-07-17 01:20:46] [EMAIL PROTECTED] Dmitry, you never answered my question why you reverted your fix? [16 Aug 2007 10:32pm UTC] [EMAIL PROTECTED] And on second check: Assigning to Dmitry who broke this with his commit to fix (!) AIX build. Dmitry: cvs diff -r1.17.2.1 -r1.17.2.2 sapi/cgi/config9.m4 cvs diff -r1.22 -r1.22.2.1 sapi/cli/config.m4 [16 Aug 2007 10:34pm UTC] [EMAIL PROTECTED] Or not really broke but tried to fix. First fix was ok but for some reason Dmitry removed the .libs part of it, perhaps he knows why.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42318 -- Edit this bug report at http://bugs.php.net/?id=42318&edit=1
#41023 [Com]: Enhance PHP "With" a Fluent Interface
ID: 41023
Comment by: fqqdk at freemail dot hu
Reported By: codeslinger at compsalot dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 5.2.1
New Comment:
this stuff should be extended to every member (not only methods, but
properties also)
$obj = new stdClass;
$obj->foo = 'bar';
with($obj) {
$baz = ->foo;
}
Previous Comments:
[2007-04-08 17:05:15] codeslinger at compsalot dot com
Description:
Given all of the buzz about "Fluent Interface" programming, see for
instance: http://devzone.zend.com/node/view/id/1362
I decided that it would be appropriate for me to request the one
feature more than any other that I miss not having in the fantastically
fabulous PHP.
The "With" operator provides an implied scope for any object Method
which does not otherwise specify an explicit object.
The goal is to increase the readability of complex programs which
contain repetitive object references (the usual case). It also reduces
typing == effort, and potentially enables the compiler to optimize
performance/access to the object. As an additional bonus, maintenance
and clarity is increased because there is a central point for the
refered to object in a block of code, thus requiring one change instead
of many.
I refer you to discussions elsewhere as to the desirability of this
syntatic sugar.
1) http://devzone.zend.com/node/view/id/1362
2) http://www.mikenaberezny.com/archives/35
3) http://en.wikipedia.org/wiki/Fluent_interface
4) http://martinfowler.com/bliki/FluentInterface.html
5)
http://schlitt.info/applications/blog/index.php?/archives/400-A-sensible-place-for-a-fluent-interface.html
Reproduce code:
---
---
Thus:
$oMyFoo = new ClassFoo;
$oMyFoo->DoSomething();
$oMyFoo->DoSomethingElse();
$oMyFoo->DoOther();
$oMyFoo->DoEtc();
$Assigned = $oMyFoo->DoSomethingElse() + $oMyFoo->SomeOther() +
$oMyFoo->Another();
Expected result:
-
Under the "Fluent Interface" paradigm in which every Method returns a
reference to *the* object, it becomes:
$oMyFoo = new ClassFoo;
$oMyFoo->DoSomething()
->DoSomethingElse()
->DoOther()
->DoEtc()
;
Note that the above is really just:
$oMyFoo->DoSomething()->DoSomethingElse()->DoOther()->DoEtc();
However, the object class must be specially written to support this and
you can not return other values, thus the "$Assigned =" is not
possible.
But by implementing a "With" construct, any object can be used without
modification, and you do not give up the ability to return values.
-
Desired Approach:
$oMyFoo = new ClassFoo;
With($oMyFoo)
{
->DoSomething();
->DoSomethingElse();
->DoOther();
->DoEtc();
$Assigned = ->DoSomethingElse() + ->SomeOther() + ->Another();
}
For any unqualified Method, the referent object is defined by the
"With" clause. Naturally, "With" can be nested.
As you can see, the readability of the code is greatly enhanced and
full functionality is retained.
--
Edit this bug report at http://bugs.php.net/?id=41023&edit=1
#45964 [NEW]: pg_unescape_bytea() does not unescape correctly
From: skrald at amossen dot dk Operating system: Linux PHP version: 5.2.6 PHP Bug Type: PostgreSQL related Bug description: pg_unescape_bytea() does not unescape correctly Description: Calling pg_unescape_bytea() on some data that has been escaped with pg_escape_bytea() does not produce the original data as expected. That is: the "unescape" method is not the opposite of the "escape" method. Reproduce code: --- Expected result: "equal" Actual result: -- "different" -- Edit bug report at http://bugs.php.net/?id=45964&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45964&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45964&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45964&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45964&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45964&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45964&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45964&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45964&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45964&r=support Expected behavior:http://bugs.php.net/fix.php?id=45964&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45964&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45964&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45964&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45964&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45964&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45964&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45964&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45964&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45964&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45964&r=mysqlcfg
#45907 [Com]: undefined reference to `PHP_SHA512Init'
ID: 45907 Comment by: webmaster at ajeux dot com Reported By: olivier at ajeux dot com Status: Feedback Bug Type: PHAR related Operating System: Linux i686 2.6.17 PHP Version: 5.3CVS-2008-08-25 (snap) New Comment: Hello, Same bug with php5.3-200809011230 (different line number though). ext/phar/.libs/util.o: In function `phar_create_signature': /source/php/php5.3-200809011230/ext/phar/util.c:2047: undefined reference to `PHP_SHA512Init' /source/php/php5.3-200809011230/ext/phar/util.c:2050: undefined reference to `PHP_SHA512Update' [...] Previous Comments: [2008-08-29 13:27:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-25 10:13:30] olivier at ajeux dot com Description: When compiling php5.3-200808250830: ext/phar/.libs/util.o: In function `phar_create_signature': /source/php/php5.3-200808250830/ext/phar/util.c:2046: undefined reference to `PHP_SHA512Init' /source/php/php5.3-200808250830/ext/phar/util.c:2049: undefined reference to `PHP_SHA512Update' /source/php/php5.3-200808250830/ext/phar/util.c:2052: undefined reference to `PHP_SHA512Final' /source/php/php5.3-200808250830/ext/phar/util.c:2061: undefined reference to `PHP_SHA256Init' /source/php/php5.3-200808250830/ext/phar/util.c:2064: undefined reference to `PHP_SHA256Update' /source/php/php5.3-200808250830/ext/phar/util.c:2067: undefined reference to `PHP_SHA256Final' ext/phar/.libs/util.o: In function `phar_verify_signature': /source/php/php5.3-200808250830/ext/phar/util.c:1915: undefined reference to `PHP_SHA256Init' /source/php/php5.3-200808250830/ext/phar/util.c:1925: undefined reference to `PHP_SHA256Update' /source/php/php5.3-200808250830/ext/phar/util.c:1882: undefined reference to `PHP_SHA512Init' /source/php/php5.3-200808250830/ext/phar/util.c:1892: undefined reference to `PHP_SHA512Update' /source/php/php5.3-200808250830/ext/phar/util.c:1899: undefined reference to `PHP_SHA512Final' /source/php/php5.3-200808250830/ext/phar/util.c:1932: undefined reference to `PHP_SHA256Final' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 Same result with php5.3-200808211030 and all releases since (don't know if it happened before). Configure line : ./configure --prefix=/usr --sysconfdir=/etc/php53 --libdir=/usr/lib/php53 --mandir=/usr/share/man --program-suffix=53 --with-layout=GNU --enable-sigchild --disable-rpath --enable-libxml --enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared --enable-dom=shared --enable-exif=shared --enable-filter --enable-ftp=shared --enable-gd-native-ttf --enable-gd-jis-conv --enable-hash=shared --enable-json=shared --enable-mbstring=shared --enable-pcntl=shared --enable-posix=shared --enable-shmop=shared --enable-simplexml --enable-soap=shared --enable-sockets=shared --enable-sqlite-utf8 --enable-sysvmsg=shared --enable-sysvsem=shared --enable-sysvshm=shared --enable-tokenizer=shared --enable-wddx=shared --enable-xml --enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared --enable-zend-multibyte --disable-static --with-libdir=lib --with-openssl=shared --with-pcre-regex=/usr --with-zlib=shared --with-bz2=shared --with-curl=shared --with-curlwrappers --with-pcre-dir --with-gd=shared --with-jpeg-dir --with-png-dir --with-freetype-dir --with-t1lib --with-gettext=shared --with-iconv=shared --with-imap=shared --with-imap-ssl --with-ldap=shared --with-ldap-sasl --with-mcrypt=shared --with-mhash=shared --with-ming=shared --with-mssql=shared --with-mysql=shared --with-mysqli=shared --enable-pdo=shared --with-pdo-dblib=shared --with-pdo-mysql=shared --with-pdo-sqlite=shared --with-pspell=shared --with-readline=shared --with-sqlite=shared --with-xmlrpc=shared --with-xsl=shared --with-pic -- Edit this bug report at http://bugs.php.net/?id=45907&edit=1
#28038 [Com]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038
Comment by: anon at anon dot com
Reported By: jordi at jcanals dot net
Status: Open
Bug Type: Mail related
Operating System: win32 only
PHP Version: 5CVS, 6CVS (2008-08-27)
New Comment:
Workaround is:
Set the following before calling the mail function:
ini_set('sendmail_from', '[EMAIL PROTECTED]);
Previous Comments:
[2008-04-17 16:04:39] kmax at live dot com
Issalys, you fix dont work and make no sense.
My suggestion is get some free email class (like XPertMailer) and use
it instead of mail() native function.
[2008-01-13 17:31:36] issalys at hotmail dot com
hi i have de same problem and i fix it in that way:
$headers = "From: " . $fm_snd['from'] . "( Some guy)\n";
it work perfect :p by
Hola tuve el mismo problema y lo solucione asi
$headers = "From: " . $fm_snd['from'] . "( quiern sea)\n";
funcionoo :p by
[2007-06-28 00:38:36] [EMAIL PROTECTED]
It's propably not complicated to fix but there just isn't anyone with
enough interest to do it. Feel free to provide a patch and perhaps
someone might catch on it. Or pay someone serious cash to fix it..
[2007-02-23 14:24:43] business at ziu dot de
This bug is now open since THREE YEARS. And still the version of today
(5.2.1) can not talk to SMTP servers as it should do.
This can not be so complicated to fix.
[2006-04-14 11:55:21] [EMAIL PROTECTED]
See also bug #37073
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28038
--
Edit this bug report at http://bugs.php.net/?id=28038&edit=1
#45963 [NEW]: Undefined variable should cause an error
From: andyincolorado at gmx dot net
Operating system: Any
PHP version: 6CVS-2008-09-01 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: Undefined variable should cause an error
Description:
In all PHP version I've tested so far, using an undefined variable (see
code below) will cause a notice to be thrown. However, it would be better
to throw an error, since using an undefined variable can cause
unpredictable results or (as in my case) data loss. Same would go to the
"undefined index" notice for arrays.
This could either be done by using an option, allowing users to turn it
off or without an option, since PHP6 changes so many things that developers
will have to adapt their scripts.
Reproduce code:
---
// Note that $bar isn't defined anywhere in the script
$foo = $bar + 5;
Expected result:
An error message that causes the script to cease running.
Actual result:
--
A notice ("Undefined variable $foo...") is thrown.
--
Edit bug report at http://bugs.php.net/?id=45963&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45963&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45963&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45963&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45963&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45963&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45963&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45963&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45963&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45963&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45963&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45963&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45963&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45963&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45963&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45963&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45963&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45963&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45963&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45963&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45963&r=mysqlcfg
#41404 [Asn->Opn]: ODBC makes memory leaks
ID: 41404
Updated by: [EMAIL PROTECTED]
Reported By: geniuz at geniuz dot cz
-Status: Assigned
+Status: Open
Bug Type: ODBC related
Operating System: XP
PHP Version: 5.2.2
Assigned To: kalowsky
Previous Comments:
[2007-05-15 21:34:24] geniuz at geniuz dot cz
Description:
When I select over ODBC from table with any column data type defined as
TEXT (detected over odbc_columns function), and I fetch rows, I receive
one of following messages or php freeze. I selected more than 10
rows.
When I replaced selected TEXT data type column for any other column ie.
STRING data type column (and with more saved datas), all is ok without
errors.
Well, problem must be with TEXT datatype (LONG columns).
Warning: odbc_exec() [function.odbc-exec]: SQL error: Failed to fetch
error message, SQL state HY000 in SQLExecDirect in
M:\4D\.WebRoot\ctp\eshop\index.php on line 65
Warning: odbc_exec() [function.odbc-exec]: SQL error: [Simba][Simba
ODBC Driver]Memory allocation error., SQL state S1001 in SQLExecDirect
in M:\4D\.WebRoot\ctp\eshop\index.php on line 65
Reproduce code:
---
$sql = "SELECT Col1, Col2, Col3 FROM MYTABLE";
$rs=odbc_exec($conn,$sql);
while( odbc_fetch_row($rs) )
{
$data1 = odbc_result($rs,'Col1');
$data2 = odbc_result($rs,'Col2');
$data3 = odbc_result($rs,'Col3');
}
Expected result:
no sql error
Actual result:
--
sql error
--
Edit this bug report at http://bugs.php.net/?id=41404&edit=1
#40695 [Asn->Opn]: odbc_execute/prepared statements does not work with Access
ID: 40695
Updated by: [EMAIL PROTECTED]
Reported By: a at bc dot de
-Status: Assigned
+Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 5.2.1
Assigned To: kalowsky
Previous Comments:
[2007-03-02 18:34:29] a at bc dot de
Description:
[repost of bug 6275]
Hello,
My problem is odbc_execute fails with the following error message:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
The odbc_exec INSERT works fine. I am using a plain vanilla NorthWind
MS
Access database and am using the ISAPI version of PHP, with ODBC built
in.
Reproduce code:
---
$conn = odbc_connect("nwind","","");
odbc_exec($conn,"drop table ADOXYZ");
odbc_exec($conn,"create table ADOXYZ (id int, firstname char(24),
lastname char(24))");
odbc_exec($conn,"insert into ADOXYZ (id,firstname,lastname) values
(0,'Zend','PHP')");
$stmt = odbc_prepare($conn,"insert into ADOXYZ (id,firstname,lastname)
values (?,?,?)");
if ($stmt) {
print "Trying execute";
$stmt = odbc_execute($stmt,array(1,"John","Lim"));
}
Actual result:
--
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT
field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
--
Edit this bug report at http://bugs.php.net/?id=40695&edit=1
#39756 [Asn->Opn]: Crashes in fetching resultsets with LONG ASCII columns from MaxDB
ID: 39756
Updated by: [EMAIL PROTECTED]
Reported By: tobias dot barth at web-arts dot com
-Status: Assigned
+Status: Open
Bug Type: ODBC related
Operating System: SuSE Linux 10.1
PHP Version: 6.0 (snapshot 2007-04-28 10:30)
Assigned To: kalowsky
Previous Comments:
[2007-04-28 19:56:47] tobias dot barth at web-arts dot com
I know a bit more about it now. Trying to do select queries on MaxDB
tables with the unixODBC-Tool "isql" only returned the first column of
the first row full with data, the rest was empty. I contacted the author
of unixODBC, Nick Gorham, and was told to get the latest snapshot of
unixODBC. With that snapshot, isql works. The reason: In 64 Bit systems,
length parameters and pointers are 64-Bit. There is a new symbol
"SQLLEN" in the header files of unixODBC now. But the problem persists
in php. I got the latest php6 snapshot and got many compilation warnings
in php_odbc.c because of incompatible pointer types. php_odbc.c uses
SDWORD as length attributes and int variables as numeric representation
of pointers - e.g. for creating connection names. I tried to fix that
and put SQLLEN in each data structure where 4 byte datatypes where used
and produces a compiler warning - now the warnings are gone. But I still
get glibc errors, when doing select queries in MaxDB:
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x560c3e90 ***
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x560609c0 ***
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x5605e660 ***
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x56052700 ***
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x56064400 ***
*** glibc detected *** /usr/sbin/httpd2-prefork: free(): invalid
pointer: 0x560cad60 ***
Perhaps I did something wrong with those SQLLEN things or just did not
enough - would you please take a look at it?
The diff between the snapshot and my modified version is:
lxdevel:/usr/src/php6.0-200704281030/ext/odbc # diff -u php_odbc.c
/tmp/php6.0-200704281030/ext/odbc/php_odbc.c
--- php_odbc.c 2007-04-28 15:23:07.0 +0200
+++ /tmp/php6.0-200704281030/ext/odbc/php_odbc.c2007-03-13
02:30:20.0 +0100
@@ -642,7 +642,7 @@
RETCODE rc;
int i;
SWORD colnamelen; /* Not used */
- SQLLEN displaysize;
+ SDWORD displaysize;
result->values = (odbc_result_value *)
safe_emalloc(sizeof(odbc_result_value), result->numcols, 0);
@@ -736,7 +736,7 @@
*/
SDWORD len;
#else
- SQLLEN len;
+ SQLINTEGER len;
#endif
zval **pv_res, **pv_num;
@@ -932,15 +932,15 @@
{
zval **pv_res, **pv_param_arr, **tmp;
typedef struct params_t {
- SQLLEN vallen;
- SQLLEN fp;
+ SDWORD vallen;
+ int fp;
} params_t;
params_t *params = NULL;
char *filename;
unsigned char otype;
SWORD sqltype, ctype, scale;
SWORD nullable;
- SQLLEN precision;
+ UDWORD precision;
odbc_result *result;
int numArgs, i, ne;
RETCODE rc;
@@ -1154,7 +1154,7 @@
result->stmt, state,
&error, errormsg,
sizeof(errormsg)-1,
&errormsgsize);
if (!strncmp(state,"S1015",5)) {
- snprintf(cursorname, max_len+1,
"php_curs_%d", (SQLLEN)result->stmt);
+ snprintf(cursorname, max_len+1,
"php_curs_%d", (int)result->stmt);
if
(SQLSetCursorName(result->stmt,cursorname,SQL_NTS) != SQL_SUCCESS) {
odbc_sql_error(result->conn_ptr, result->stmt, "SQLSetCursorName");
RETVAL_FALSE;
@@ -1726,7 +1726,7 @@
odbc_result *result;
int i = 0;
RETCODE rc;
- SQLLEN fieldsize;
+ SDWORD fieldsize;
zval **pv_res, **pv_field;
#ifdef HAVE_SQL_EXTENDED_FETCH
UDWORD crow;
@@ -2334,13 +2334,12 @@
if (zend_hash_find(&EG(regular_list), hashed_details,
hashed_len + 1,
(void **) &index_ptr) ==
SUCCESS) {
- int type;
- SQLLEN conn_id;
+ int type, conn_id;
void *ptr;
if (Z_TYPE_P(index_ptr) != le_index_ptr) {
RETURN_FALSE;
}
- conn_id = (SQLLEN)index_ptr->ptr;
+ conn_id = (int)index_ptr->ptr;
ptr = zend_list_find(conn_id, &type)
#20298 [Asn->Opn]: [PATCH] odbc.check_persistent not working
ID: 20298
Updated by: [EMAIL PROTECTED]
Reported By: phpbug at tab1 dot clara dot co dot uk
-Status: Assigned
+Status: Open
Bug Type: ODBC related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-04-13)
Assigned To: kalowsky
Previous Comments:
[2006-02-23 20:44:25] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-07-27 10:57:57] t-yonetani+php at ergobrains dot co dot jp
Here's a patch written according to phpbugs at kevin dot offwhite dot
net's
suggestion(I hope space and tabs won't be damanged). We're using a
similar
version(just by replacing SQLGetInfo() with SQLGetConnectAttr()) on a
spare
machine, and odbc_pconnect() seems to be working so far. Uncommenting
out
the code for fixing #15758 is a bit scary, but I believe it should be
OK.
Index: php_odbc.c
===
RCS file: /repository/php-src/ext/odbc/php_odbc.c,v
retrieving revision 1.143.2.12
diff -u -r1.143.2.12 php_odbc.c
--- php_odbc.c 14 Jun 2003 03:37:30 - 1.143.2.12
+++ php_odbc.c 27 Jul 2005 08:47:05 -
@@ -2156,6 +2156,29 @@
}
/* }}} */
+/* {{{ is_connection_dead */
+static int is_connection_dead(odbc_connection *db_conn)
+{
+#if defined(HAVE_IBMDB2)
+#else
+ UCHAR d_name[32];
+ SWORD len;
+#endif
+ SQLINTEGER dead;
+ RETCODE ret;
+
+#if defined(HAVE_IBMDB2)
+ ret = SQLGetConnectAttr(db_conn->hdbc, SQL_ATTR_CONNECTION_DEAD,
&dead,
+ 0, NULL);
+#else
+ ret = SQLGetInfo(db_conn->hdbc, SQL_DATA_SOURCE_READ_ONLY, d_name,
+sizeof(d_name), &len);
+ dead = len == 0;
+#endif
+ return ret != SQL_SUCCESS || dead;
+}
+/* }}} */
+
/* Persistent connections: two list-types le_pconn, le_conn and a
plist
* where hashed connection info is stored together with index pointer
to
* the actual link of type le_pconn in the list. Only persistent
@@ -2282,23 +2305,13 @@
* check to see if the connection is still in place
(lurcher)
*/
if(ODBCG(check_persistent)){
- RETCODE ret;
- UCHAR d_name[32];
- SWORD len;
-
- ret = SQLGetInfo(db_conn->hdbc,
- SQL_DATA_SOURCE_READ_ONLY,
- d_name, sizeof(d_name), &len);
-
- if(ret != SQL_SUCCESS || len == 0) {
+ if(is_connection_dead(db_conn)) {
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_len +
1);
- /* Commented out to fix a possible
double closure error
-* when working with persistent
connections as submitted by
-* bug #15758
-*
-* safe_odbc_disconnect(db_conn->hdbc);
-* SQLFreeConnect(db_conn->hdbc);
+ /*
+* now that we know the connection is
dead, just free
+* the DBC handle without issuing
SQLDisconnect().
*/
+ SQLFreeConnect(db_conn->hdbc);
goto try_and_get_another_connection;
}
}
[2004-06-04 22:06:49] phpbugs at kevin dot offwhite dot net
Well, after some additional research I have turned up what I think is
the exact cause of the bug, but I don't feel qualified to implement the
solution.
In the php code, at line 2271 in php_odbc.c (
http://lxr.php.net/source/php-src/ext/odbc/php_odbc.c#2271 ), php calls
SQLGetInfo() passing a parameter of SQL_DATA_SOURCE_READ_ONLY to try and
determine if the connection is alive or not. While this may work in
some odbc drivers, it is not the "official" way of asking if the
connection is dead. According to my driver supplier (
http://www-912.ibm.com/o_dir/odbcforum.nsf/8178b1c14b1e9b6b8525624f0062fe9f/B0CFDBA3D8DBAC0F86256EA80077D2B9?OpenDocument
) and the Microsoft's ODBC Programmer's reference (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcodbc_connection_pooling.asp
), the correct method is to use SQLGetConnectAttr() to check the
Attribute SQL_ATTR_CONNECTION_DEAD.
Steps to reproduce:
1) Use PHP's odbc_pconnect() function wit
#43695 [Opn->Fbk]: Asynchronous socket connection timing issue
ID: 43695 Updated by: [EMAIL PROTECTED] Reported By: nicolas dot legland at free dot fr -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Windows XP Professional SP2 PHP Version: 5.3CVS-2007-12-28 (snap) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2007-12-28 14:17:55] koollman at gmail dot com Works fine on linux, so it may be windows related: #socket example, edited to remove the dl() call $ php5 socket.php Open0.002049 Wait0.194022read 1, write 1, except 0 Close 0.44 #stream example $ php5 stream.php Open0.007108 Wait0.211123read 1, write 1, except 0 Close 0.48 #php5 from http://hype.sourceforge.jp $ php5 --version PHP 5.2.3-1~edh.0 (cli) (built: Jun 10 2007 11:07:12) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies #vanilla linux kernel $ uname -r 2.6.22 [2007-12-28 14:02:38] nicolas dot legland at free dot fr Description: When using sockets through the "sockets" extension, everything works fine with no delay to notice. Reproduce code: --- Result: --- Open0.030620 Wait1.518440read 0, write 0, except 1 Close 0.000108 [2007-12-28 08:37:12] nicolas dot legland at free dot fr Description: Asynchronously connecting a TCP socket stream to a filtered port times out, but closing the resource using fclose() blocks for 0.5 second. Asynchronously connecting a TCP socket stream to a closed port ends up with the server explicitly refusing the connection by a RST ACK packet. Using stream_select() returns the stream resource as having had an except but trying to close the resource using fclose() blocks for 0.5 second too. No network transfer was captured by Wireshark apart from the initial SYN packet in either case. Using fclose() on a successfully asynchronously connected TCP socket stream to an open port returns instantaneously. If you don't explicitly fclose() the resources of failed connections, the same 0.5 seconds lag appears at the end of the script execution for each one. PHP probably cleanly frees resources at shutdown, but it can reach several seconds when several sockets have failed. When using non-blocking BSD socket with the sockets extension, no delay of any kind is noticed. Reproduce code: --- Expected result: Open0.010317 Wait1.588449read 0, write 0, except 1 Close 0.99 Actual result: -- Open0.010002 Wait1.547396read 0, write 0, except 1 Close 0.510161 -- Edit this bug report at http://bugs.php.net/?id=43695&edit=1
#45962 [Opn->Bgs]: __destruct use wrong directory
ID: 45962
Updated by: [EMAIL PROTECTED]
Reported By: zodiacxp at web dot de
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Vista
PHP Version: 5.2.6
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-09-01 01:56:02] zodiacxp at web dot de
Description:
__destruct seems to change the path
Reproduce code:
---
function __destruct()
{
file_put_contents("find.me", "foo");
}
Expected result:
I expect that it stay in the path of the script, or the script from in
which the object is.
Actual result:
--
It stores the file somewhere else.
My PHP path: E:\xammp\php\
MyDocuments: E:\xammp\htdocs\e-workspace\
Found the file in E:\xammp
--
Edit this bug report at http://bugs.php.net/?id=45962&edit=1
