#31848 [NEW]: PHP doesn´t open the database file from SQLite 3.0.8
From: fernando dot wendt at gmail dot com
Operating system: Windows 2000 Professional
PHP version: 5.0.3
PHP Bug Type: SQLite related
Bug description: PHP doesn´t open the database file from SQLite 3.0.8
Description:
Hi,
I have downloaded the SQLite 3.0.8 for Windows, and it seems to work fine:
via prompt, database created, data inserted, dump done, imports and outputs
made.
Then, when trying to make it really works, whith PHP 5.0.3 and Apache
2.0.52, always PHP points an error, that saids "file is not a database or
is encrypted".
To make this really hapends, and what motivated me to came here, i get
SQLite 2.8.15, created the same database (all right), and with this
version PHP works.
The table is very simple: it´s name "tabela", and have two columns
"numero" and "nome" (smallint and varchar). Two data inserted: 1-Fernando
and 2-Nidiane.
Thats all.
Reproduce code:
---
unbufferedQuery("Select * from tabela");
foreach ($res as $row){
print_r($row);
}
?>
Expected result:
Array
(
[0] => 1
[numero] => 1
[1] => Fernando
[nome] => Fernando
)
Array
(
[0] => 2
[numero] => 2
[1] => Nidiane
[nome] => Nidiane
)
Actual result:
--
Warning: SQLiteDatabase::unbufferedQuery()
[function.unbufferedQuery.html]: no such table: tabela in C:\Arquivos de
programas\Apache Group\Apache2\htdocs\sqlite\exemplo.php on line 3
Warning: Invalid argument supplied for foreach() in C:\Arquivos de
programas\Apache Group\Apache2\htdocs\sqlite\exemplo.php on line 4
--
Edit bug report at http://bugs.php.net/?id=31848&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31848&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31848&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31848&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31848&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31848&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31848&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31848&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31848&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31848&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31848&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31848&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31848&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31848&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31848&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31848&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31848&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31848&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31848&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31848&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31848&r=mysqlcfg
#31848 [Bgs]: PHP doesn�t open the database file from SQLite 3.0.8
ID: 31848
User updated by: fernando dot wendt at gmail dot com
-Summary: PHP doesn´t open the database file from SQLite 3.0.8
Reported By: fernando dot wendt at gmail dot com
Status: Bogus
Bug Type: SQLite related
Operating System: Windows 2000 Professional
PHP Version: 5.0.3
New Comment:
OK, thank you for the information.
I sugest to put it on the docs page, to explain better this version
dependece feature about this module.
Best regards,
Fernando Wendt
Previous Comments:
[2005-02-05 01:29:36] [EMAIL PROTECTED]
No bug, PHP uses the SQLite 2.x library which ofcourse can not read
SQLite 3 formatted files. (You can have a look at PDO's SQLite3 driver
though).
[2005-02-04 18:34:17] fernando dot wendt at gmail dot com
Description:
Hi,
I have downloaded the SQLite 3.0.8 for Windows, and it seems to work
fine: via prompt, database created, data inserted, dump done, imports
and outputs made.
Then, when trying to make it really works, whith PHP 5.0.3 and Apache
2.0.52, always PHP points an error, that saids "file is not a database
or is encrypted".
To make this really hapends, and what motivated me to came here, i get
SQLite 2.8.15, created the same database (all right), and with this
version PHP works.
The table is very simple: it´s name "tabela", and have two columns
"numero" and "nome" (smallint and varchar). Two data inserted:
1-Fernando and 2-Nidiane.
Thats all.
Reproduce code:
---
unbufferedQuery("Select * from tabela");
foreach ($res as $row){
print_r($row);
}
?>
Expected result:
Array
(
[0] => 1
[numero] => 1
[1] => Fernando
[nome] => Fernando
)
Array
(
[0] => 2
[numero] => 2
[1] => Nidiane
[nome] => Nidiane
)
Actual result:
--
Warning: SQLiteDatabase::unbufferedQuery()
[function.unbufferedQuery.html]: no such table: tabela in C:\Arquivos
de programas\Apache Group\Apache2\htdocs\sqlite\exemplo.php on line 3
Warning: Invalid argument supplied for foreach() in C:\Arquivos de
programas\Apache Group\Apache2\htdocs\sqlite\exemplo.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=31848&edit=1
#49387 [NEW]: E_DEPRECATED looks like a fatal error, even off
From: fernando dot wendt at gmail dot com Operating system: Windows XP PHP version: 5.3.0 PHP Bug Type: *Configuration Issues Bug description: E_DEPRECATED looks like a fatal error, even off Description: PHP is ignoring the php.ini error_reporting configuration, and is always hangin up scripts with the E_DEPRACATED message. The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All depracated warnings are working as fatal errors, and i believe that was not the intention it supposed to do. The only way to avoid this (at least on my workaround) is setting up the display_errors = Off (even on my workstation). Reproduce code: --- Try some script that have depracated function or issue to work. It will freeze as a fatal error, pointing a depracated message. Expected result: First, it should respect the php.ini ~E_DEPRECATED flag and then show deprecated issues as warnings, not as fatal errors. Actual result: -- php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal error, and is not being respected if is on or off. -- Edit bug report at http://bugs.php.net/?id=49387&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49387&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49387&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49387&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49387&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49387&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49387&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49387&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49387&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49387&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49387&r=support Expected behavior: http://bugs.php.net/fix.php?id=49387&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49387&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49387&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49387&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49387&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49387&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49387&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49387&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49387&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49387&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49387&r=mysqlcfg
#49387 [Fbk->Csd]: E_DEPRECATED looks like a fatal error, even off
ID: 49387
User updated by: fernando dot wendt at gmail dot com
Reported By: fernando dot wendt at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: *Configuration Issues
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
Ops!
Trying to reproduce it twice, it points me to be working fine :)
Trully, there is a incomplete behavior present at phpPgAdmin (method
"printHeader", that have junt one "if" trying to change document header.
That was why the script seems to be stoping anyway.
Sorry, its all right. Bellows, a little buggy script to confirm this.
foo = 'Something';
}
public function getfoo(){
return($this->foo);
}
}
$data =& new Doit(); //Deprecated issue
echo $data->getfoo;
$xpto = 12; //Logical follows
echo $xpto;
pg_connect();//Missing function data
?>
Previous Comments:
[2009-08-27 16:17:01] sjo...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
--------
[2009-08-27 12:53:36] fernando dot wendt at gmail dot com
Description:
PHP is ignoring the php.ini error_reporting configuration, and is
always hangin up scripts with the E_DEPRACATED message.
The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All
depracated warnings are working as fatal errors, and i believe that was
not the intention it supposed to do.
The only way to avoid this (at least on my workaround) is setting up
the display_errors = Off (even on my workstation).
Reproduce code:
---
Try some script that have depracated function or issue to work. It will
freeze as a fatal error, pointing a depracated message.
Expected result:
First, it should respect the php.ini ~E_DEPRECATED flag and then show
deprecated issues as warnings, not as fatal errors.
Actual result:
--
php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal
error, and is not being respected if is on or off.
--
Edit this bug report at http://bugs.php.net/?id=49387&edit=1
#46036 [NEW]: PHP does not load pgsql module from php.ini
From: fernando dot wendt at gmail dot com Operating system: Windows Vista Home Premium PHP version: 5.2.6 PHP Bug Type: PostgreSQL related Bug description: PHP does not load pgsql module from php.ini Description: PHP 5.2.6 is not loading php_pgsql.dll from de extension add ons repository, at the file system. PHP_INFO basic page does not recognize it, and all the calls for pg* functions points failure. Expected result: PostgreSQL extension loaded, and working. Actual result: -- The pgsql extension is not loaded, with Apache 2.2.9 on Windows Vista. -- Edit bug report at http://bugs.php.net/?id=46036&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46036&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46036&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46036&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46036&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46036&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46036&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46036&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46036&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46036&r=support Expected behavior:http://bugs.php.net/fix.php?id=46036&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46036&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46036&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46036&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46036&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46036&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46036&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46036&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46036&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46036&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46036&r=mysqlcfg
#39312 [Com]: Cannot install PDO_OCI
ID: 39312
Comment by: fernando dot wendt at gmail dot com
Reported By: andrew dot nagy at villanova dot edu
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.4
Assigned To: sixd
New Comment:
More info about the lastest Oracle Instant Client under Linux: i'm
configuring a web server with Apache2.2.11, PHP5.2.8, and OIC11.1, and
PDO compile only works with this syntax:
./configure --with-oci8=shared,instantclient,/usr/lib/oracle
--with-pdo-oci=instantclient,/usr/lib/oracle,11.1
Presuming /usr/lib/oracle is your Instant Client base directory. The
great stuff is pass the version number at the command line, just as
Andrew point us.
Thanks a lot, and i do suggest you to put this detail on the online
documentation website, at installing PDO Oracle.
Best regards.
Previous Comments:
[2007-09-27 09:56:50] j...@php.net
Chris, can you check this out please?
[2007-09-25 22:08:48] tony2...@php.net
Yeah, but I never maintained PDO_OCI.
[2007-09-25 09:53:13] j...@php.net
Tony, I wasn't sure to whom to assign this but you're one of the oci8
maintainers AFAIK. :)
[2007-09-24 21:20:56] andrew dot nagy at villanova dot edu
I just did an install of php 5.2.4 on a brand new RHEL server. The
only way I could get this to work is by using the zip files provided by
Oracle, not the RPMs. Both the Basic and SDK are need (well I am
assuming the Basic is needed). Once I unzip the files, I needed to
create 2 symbolic links -- both libclntsh.so and libocci.so.
Could this be fixed in the configure script to look for the original
files instead of the renamed files?
For now - I have created a patch that makes the language a bit more
intuitive if this helps at all. It is diff'ed against the 5.2.4
release.
1305,1306c1305,1306
< Use
--with-pdo-oci=instantclient,/path/to/instantclient,version
< for an Oracle Instant Client SDK
install.
---
> Use
--with-pdo-oci=instantclient,prefix,version
> for an Oracle Instant Client SDK.
73096c73096
< { echo "configure: error: I'm too dumb to figure out where the
include dir is in your Instant Client install" 1>&2; exit 1; }
---
> { echo "configure: error: Cannot find the Instant Client SDK in
your Instant Client install" 1>&2; exit 1; }
73105c73105
< { echo "configure: error: I'm too dumb to figure out where the
libraries are in your Instant Client install" 1>&2; exit 1; }
---
> { echo "configure: error: Cannot find the libclntsh.so file.
Try making a symbolic link in your Instant Client SDK install" 1>&2;
exit 1; }
[2006-11-08 21:37:15] tony2...@php.net
If you know how exactly to make it more verbose and clear - we would
gladly accept your patch for ext/pdo_oci/config.m4.
See here:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_oci/config.m4?revision=1.14.2.5&view=markup
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/39312
--
Edit this bug report at http://bugs.php.net/?id=39312&edit=1
#42837 [NEW]: Timeout parameter sugest for ldap_bind and/or ldap_connect
From: fernando dot wendt at gmail dot com
Operating system: GNU-Linux
PHP version: 5.2.4
PHP Bug Type: LDAP related
Bug description: Timeout parameter sugest for ldap_bind and/or ldap_connect
Description:
I do suggest that PHP LDAP functions "ldap_bind" and/or "ldap_connect" are
improved to suport a new parameter to control network timeout over the
request.
At some cases, the HTTP request is send to webserver (like Ajax can do),
and it can't be handling for stop processing - on the server side (because
XMLHTTPRequest has an "abort" method avaliable - for the client side). So,
if there are a lot of online users trying to get the same LDAP large
entries, the webserver probably hangs up (or even crashes).
That hangs on the request processing for large data ranges from LDAP data
sources (i.e: more than 5000 entries). Plus, the network state is too
involved at this new suggested behavior, in order to be manipulated at some
way.
So, adding this parameter function, PHP could limits the request response
in order to control it, by the time.
Reproduce code:
---
$host = "localhost";
$basedn = "ou=MYCOMPANY";
if ($con = ldap_connect($host)){
ldap_set_option($con, LDAP_OPT_TIMELIMIT, 10);
echo "Connected";
$ldapbind = ldap_bind($con);
if ($ldapbind){
//echo "Bind OK";
$search = ldap_search($con, $basedn, "(cn=*)");
echo "LDAP Entries:" . ldap_count_entries($con, $search);
}
else
echo "No bind";
ldap_unbind($con);
}
else
echo "Not connected";
Expected result:
I would like to specify at ldap_connect($host, $time) and/or
ldap_bind($con, $time) the number of seconds that request could be hanged
on, while not expires.
Actual result:
--
As the only time limit is avaliable at ldap_search function, or even
ldap_set_option, if there are a lot of entries to be handled, the request
is being hanged on a very long time (TCP/IP connection).
--
Edit bug report at http://bugs.php.net/?id=42837&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42837&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42837&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42837&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42837&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42837&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42837&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42837&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42837&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42837&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42837&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42837&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42837&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42837&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42837&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42837&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42837&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42837&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42837&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42837&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42837&r=mysqlcfg
Bug #62003 [Com]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Comment by: fernando dot wendt at gmail dot com Reported by:aconnor at ait dot ie Summary:LDAP compile failure Status: Open Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards Previous Comments: [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
