go to bug id or search bugs for
On upgrading from php 5.6.5 nts (server 2012r2 64bit) to 5.6.7, our odbc_exec is no longer working.
we are using the sage line 50 odbc driver to extract data from the accounts software we use.
I suspect this is related to bug id 68964
$query=odbc_exec($odbcconn,"SELECT ACCOUNT_REF, NAME FROM sales_ledger");
in the 5.6.5 version, the code will display no errors
in the 5.6.7 version we get:
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 1956365745 bytes) in C:\inetpub\wwwroot\sage.php on line 3
So i changed the memory limit from 512M to 3G to see what would happen:
PHP Fatal error: Out of memory (allocated 262144) (tried to allocate 1956365745
bytes) in C:\inetpub\wwwroot\sage.php on line 3
Add a Patch
Add a Pull Request
Could you please check with the latest snapshots as in bug #69354? Looks very similar to it.
I tried using php from php-master-nts-windows-vc11-x86-rf265928.zip as requested and still have an error
VirtualAlloc() failed: [0x00000008] Not enough storage is available to process t
PHP Fatal error: Out of memory (allocated 2097152) (tried to allocate 195376781
3 bytes) in C:\inetpub\wwwroot\sage.php on line 3
Ok, in this case, please provide the exact instructions how to reproduce this.
Other than the code above, it requires sage accounts be installed on the machine (or its odbc driver at least) which is not free software.
I could provide you access to a test virtual machine for you to see the problem on with a demo data set in sage if that is ok?
@JLH, you've already shown the error messages and confirmed the bug is still present, no need to just see that again.
What I'm asking for is to be able to debug and recompile PHP using your driver and data, and then make a fix and a unit test. So it were probably easier the other way round - if you could please supply the test db and the driver. Maybe they have some trial of the driver?
Sorry for the delay
I have put the standard sage demo data, the odbc driver and a readme.txt at
Hope that helps
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
The ODBC trace explains what's happening. The SQLColAttributes
call for SQL_DESC_CONCISE_TYPE returns SQL_VARCHAR. That causes
SQLColAttributes to be called with SQL_DESC_OCTET_LENGTH to get
the displaysize, but the driver can't handle that attribute.
However, the SQL_ERROR is not caught, and the implementation
proceeds with emalloc'ing whatever is stored in displaysize.
For comparison, see the ODBC trace under PHP 5.6.5.
This issue is closely related to bug #68350.
Anatol, can you please have a look.
@JLH thanks for the delivery, I can now confirm the insights of @cmb.
The Sage driver claims compatibility with ODBC 3.8, however this piece seems to be a bug in that driver. SQL_DESC_OCTET_LENGTH is introduced with ODBC 3.0, so it should be supported. @JLH it might probably make sense to report this to the origin.
I'm going to debug this more next days, seems that other drivers having unclean 3.x implementations may be sensitive to this as well. In the worst case I guess we'll need to apply the quirk from the bug #68350.
@cmb, ah ... that's SQLColAttribute, not SQLColAttributes - as we've ODBC 3.0 by default.
Automatic comment on behalf of ab
Log: fix bug #69381
Automatic comment on behalf of email@example.com
Log: Fixed bug #69381 out of memory with sage odbc driver
Related To: Bug #69438