Bug #72175 [Opn]: Impossibility of creatiing multiple connections to Interbase with php 7.0

From: Date: Fri, 10 Nov 2017 11:50:31 +0000
Subject: Bug #72175 [Opn]: Impossibility of creatiing multiple connections to Interbase with php 7.0
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-212541@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=72175&edit=1 ID: 72175 User updated by: netvicious at gmail dot com Reported by: netvicious at gmail dot com Summary: Impossibility of creatiing multiple connections to Interbase with php 7.0 Status: Open Type: Bug Package: InterBase related Operating System: Ubuntu 16.04 LTS PHP Version: 7.0.6 Block user comment: N Private report: N New Comment: I sent a comment to the Firebird dev mailing list but anybody looked at this bug. As I said my workaround was to use a static var on the database access library I include on all the php files which use BDs. class ps_DB { ... private static $conn = 0; function connect() { if (self::$lid == 0) { self::$lid = ibase_pconnect(DB_HOST . ":" . DB_NAME,DB_USER,DB_PWD,DB_CHARACTER); ... Using this static variable we will use always the same BD connection and it will work. Previous Comments: ------------------------------------------------------------------------ [2017-11-10 10:03:26] roman dot vanicek at gmail dot com There is a workaround. One can use one database handle obtained from ibase_connect and then multiple transaction handles obtained from ibase_trans. ------------------------------------------------------------------------ [2017-07-12 10:36:43] us at menatwork dot de I think, nobody wants to repair this, so Firebird with PHP is dead. ------------------------------------------------------------------------ [2017-07-10 20:33:55] fabricio dot th2 at gmail dot com Hello, This bug is still present in version 7.2-alpha3 for Windows and Debian; ------------------------------------------------------------------------ [2017-04-28 14:17:54] fabricio-th at bol dot com dot br Hallo, This bug is still present in version 7.1.4 for Windows and Debian ------------------------------------------------------------------------ [2017-01-23 14:30:59] netvicious at gmail dot com Between 7.0.2 and 7.0.3 there are a lot of chantes (7.0.0 to 7.0.3 the list it's bigger). **7.0.2************************************************************************** xlink = (zend_resource*) le->ptr; if ((!persistent && xlink->type == le_link) || xlink->type == le_plink) { if (IBG(default_link) > 0) { zval *link = zend_hash_index_find(&EG(regular_list), IBG(default_link)); if (link) { zend_list_delete(Z_RES_P(link)); } } xlink->gc.refcount++; xlink->gc.refcount++; IBG(default_link) = xlink->handle; RETVAL_RES(xlink); } else { zend_hash_str_del(&EG(regular_list), hash, sizeof(hash)-1); } **7.0.3************************************************************************** xlink = (zend_resource*) le->ptr; if ((!persistent && xlink->type == le_link) || xlink->type == le_plink) { if (IBG(default_link)) { zend_list_close(IBG(default_link)); } xlink->gc.refcount++; xlink->gc.refcount++; IBG(default_link) = xlink; RETVAL_RES(xlink); } else { zend_hash_str_del(&EG(regular_list), hash, sizeof(hash)-1); } They only changed some things related to lists and a way to check the "default_link". I don't know where it's the problem, but the word default_link says to me something like there only can be one NON-persistent link to the firebird/interbase database. Because that code it paster before it's inside one if /* try to reuse a connection */ if ((le = zend_hash_str_find_ptr(&EG(regular_list), hash, sizeof(hash)-1)) != NULL) { And after that if we have something that seems to create a persistent one /* ... or a persistent one */ do { One thing I don't understand it's if we reused a connection why after the if of reusing connection we do a persistent one. If it's really one OR the RETVAL should exit the function like one return statement (I don't know if it does a return). ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=72175 -- Edit this bug report at https://bugs.php.net/bug.php?id=72175&edit=1

« previous php.bugs (#212541) next »