Php Zend Framework 1.12+；Crontab+；odbc查询-致命错误：允许的内存大小

目前，我在Zend Zend Framework 1.12上开发了一个应用程序，它位于Ubuntu 14.04.2服务器上，具有iSeries Access ODBC驱动程序64位

当我从控制器手动执行以下查询时，我正确地收到了结果：

class MaestrosController extends Zend_Controller_Action {

public function indexAction() {    
    $this->_query("SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1");
}

private function _query($query) {             
    try {
        $conexion = $this->_connect();
        $result = odbc_exec($conexion, $query);
    }catch (Exception $e){
        die($e->getMessage());
    }
    $salida = array();
    while( ($row = odbc_fetch_array($result)) !== false ) {
        array_push($salida, $row);
    }
    $this->_disconect($conexion);
    return $salida;
}

private function _connect()
{
   $objConnect =  odbc_connect('EXPO', $this->odbc_user,$this->odbc_calve) or die('Connect: '.odbc_errormsg()."\n");
   return $objConnect;
}

private function _disconect($conexion)
{
   odbc_close($conexion);
}
}

但是，当我通过合同执行时：

php /var/www/vhosts/core.lan/application/cronjobs/cronjob.php >> /tmp/logcron.log

SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1 FETCH FIRST 14 ROWS ONLY

cronjob.php

define("_CRONJOB_",true);
require_once('/var/www/vhosts/core.lan/httpdocs/index.php');

(...)

$this->_query("SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1");

(...)

出现以下错误消息：

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 16815550472902410251 bytes) in /var/www/vhosts/core.lan/application/models/DbTable/M3.php on line 259. 

第259行对应于

$result=odbc\u exec（$conexion，$query）

为了通过cron执行，我的索引配置如下：

(...)

$application->bootstrap();

//Cronjobs don't need all the extra's so we don't execute the bootstrap
if(!defined('_CRONJOB_') || _CRONJOB_ == false){
    $application->bootstrap()->run();
}

日志中没有其他内容，除了内存大小之外，没有错误消息


在寻找解决方案时，我发现如果我通过contrab执行以下查询：

php /var/www/vhosts/core.lan/application/cronjobs/cronjob.php >> /tmp/logcron.log

SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1 FETCH FIRST 14 ROWS ONLY

它非常有效：

+-----------+-------------------------------------+
| VALUE     | OPTION                              |
+-----------+-------------------------------------+
| 0000001   | ANIBAL                              |
| 0000002   | MODAS                               |
| 0000003   | NOVIAS                              |
| 0000004   | ROSA                                |
| 0000005   | RC                                  |
| 0000006   | BELLAESPOSA                         |
| 0000007   | RICARDO                             |
| 0000008   | YOLANDA                             |
| 0000009   | HUELVA .                            |
| 0000010   | DROP                                |
| 0000011   | DOBADOCA                            |
| 0000013   | MARIA                               |
| 0000014   | MODA                                |
| 0000015   | HABITUS                             |
+-----------+-------------------------------------+

但是，如果执行以下操作，则会出现致命错误：

SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1 FETCH FIRST 15 ROWS ONLY

如果我想看到该行中显示的信息，我执行
isql-vepo
，并收到以下结果

+-----------+-------------------------------------+
| VALUE     | OPTION                              |
+-----------+-------------------------------------+
| 0000001   | ANIBAL                              |
| 0000002   | MODAS                               |
| 0000003   | NOVIAS                              |
| 0000004   | ROSA                                |
| 0000005   | JON                                 |
| 0000006   | BELLAESPOSA                         |
| 0000007   | CHARLES                             |
| 0000008   | YOLANDA                             |
| 0000009   | HUELVA                              |
| 0000010   | DROP                                |
| 0000011   | DOBADOCA                            |
| 0000013   | MARIA                               |
| 0000014   | MODA                                |
| 0000015   | HABITUS                             |
| 0000016   | Mª ANGELES                          |
+-----------+-------------------------------------+

我推断问题可能来自字符
ª


我在IBM网站上读过以下文章：

ODBC应用程序字符集

ODBC应用程序字符集由当前语言环境的
字符集

$locale
返回以下内容：

LANG=es_ES.UTF-8
LANGUAGE=
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=

但是，命令
$sudo/opt/ibm/iSeriesAccess/bin64/cwbnltbl
给出了：

cwbnltbl - Download conversion table utility
Usage: cwbnltbl source-code-page target-code-page [host] [uid] [pwd]
Linux locale codeset=UTF-8 ccsid=1208

我不知道该怎么办

我能找到的唯一信息和我遇到的问题或多或少相似的是这篇文章：，然而，提出的解决方案根本帮不了我

我恳请有人在这个问题上给我一些支持

谢谢
 您可能遇到了旧iSeries Access for Linux ODBC驱动程序的问题。由于64位ABI在unixODBC 2.2.13中更改为支持64位参数，iSeries Access 7.1（及更早版本）驱动程序在与基于unixODBC 2.2.13或更新版本构建的应用程序一起使用时将产生不正确的结果

解决方案是使用新的IBM i Access ODBC驱动程序，该驱动程序是的一部分，已更新为使用新的ABI。
问题与执行php脚本的环境的区域设置有关

运行以下语句可以修复它：

LANG = es_ES;

如果我通过crontab运行以下命令，则没有问题：

LANG = es_ES; php -f /var/www/vhosts/core.lan/application/cronjobs/cronjob.php >> /tmp/logcron.log

因此，解决方案是修复php语言环境。
谢谢Kevin，我将尝试更新驱动程序。嗨Kevin，最近我将unixODBC更新为2.3.4，但问题仍然存在。。。还有什么我可以试试的吗？你更新驱动程序了吗？问题是您使用的驱动程序对于您的unixODBC版本来说太旧，或者相反，您的unixODBC版本对于您的驱动程序来说太新。在这种情况下，更新unixODBC的版本对您没有帮助-您需要将驱动程序更新为ACS应用程序包中的驱动程序，或者将unixODBC降级为2.2.13之前的版本。