Та же ошибка обнаружена в сохраненной **процедуре**, но не в сохраненной **функции**

Я не использую Informix, но простые примеры, которые я пробовал с Perl DBD::ODBC, а также с isql (написанным на C), все возвращают ошибку:

use strict;
use warnings;
use DBI;

my $h = DBI->connect();
eval {
    $h->do(q/drop function fmje/);
};

$h->do(<<'EOS');
create function fmje (@p1 as int)
returns int
as
begin
    declare @a int;

    set @a = 'fred';
    return @p1;
end;
EOS

my $s = $h->prepare(q/{? = call fmje(?)/);
$s->bind_param_inout(1, \my $x, 10);
$s->bind_param(2, 1);
$s->execute;
print "return is ", ($x ? $x : "undef"), "\n";



isql -v baugi sa easysoft
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> {call fmje(1)}
[22005][unixODBC][Easysoft][SQL Server Driver 11.0][SQL Server]Conversion failed when converting the varchar value 'fred' to data type int.
[ISQL]ERROR: Could not SQLExecute
SQL>

Informix должен работать по-другому для функций, или, возможно, вы не используете универсальный ODBC через Aqua Data Studio.

Если вы видите ошибку от Perl, как вы говорите в своем другом посте, сделайте так, как я там рекомендовал, и добавьте:

[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log

в начало файла odbcinst.ini и запустите Perl. Тогда покажите нам строки из лога с ошибкой. Затем повторите с isql, чтобы мы могли сравнить вызовы ODBC.

Это может быть связано с используемой вами версией сервера (маловероятно, но возможно) или с используемым вами API. Когда я тестирую IDS 11.70.FC2 в MacOS X 10.7, используя (мою) сборку программы sqlcmd с ESQL/C (CSDK) 3.70.FC2, я получаю:

$ sqlcmd -c -d stores -e begin -xf x1.sql -e 'execute procedure proc(2)' \
         -e 'execute function func()' 
+ CREATE FUNCTION "test".func() RETURNING LVARCHAR(1000);
set debug file to '/home/directory_does_not_exists/unknown.log';
trace off;
trace on;
trace off;
return 'result is set here';
END FUNCTION;
+ CREATE PROCEDURE "test".proc(pDummy SMALLINT)
set debug file to '/home/directory_does_not_exists/unknown.log';
trace off;
trace on;
LET pDummy = 2;
trace off;
END PROCEDURE;
+ execute procedure proc(2)
SQL -648: Cannot open DEBUG file for SPL routine trace.
SQLSTATE: IX000 at /dev/stdin:0
+ execute function func()
SQL -648: Cannot open DEBUG file for SPL routine trace.
at /dev/stdin:0
$

Как видите, и func(), и proc() правильно сообщают об ошибке в ESQL/C. Таким образом, проблема почти наверняка заключается в клиентском коде — в драйвере ODBC и способе его обработки ошибок или в коде, вызывающем драйвер ODBC.

Как еще больше изолировать проблему?

Запустите тест с SQLIDEBUG=2:xyz в среде. Затем найдите файл с именами, начинающимися с xyz_ (у меня, например, xyz_35424_0_819800) и запустите на нем sqliprint. Это покажет вам, генерирует ли сервер сообщение об ошибке дважды.

Я получил два подобных пакета в одной трассировке:

S->C (12)               Time: 2011-07-28 00:28:02.41736
    SQ_ERR
        SQL error..........: -648
        ISAM/RSAM error....: 0
        Offset in statement: 0
        Error message......: "" [0]
    SQ_EOT

Если вы видите два пакета с ошибкой -648, то вы знаете, что проблема заключается в том, как клиент обрабатывает ошибку. Если вы не видите двух ошибок, то мне очень любопытно посмотреть, что происходит.

Прежде всего - спасибо большое @Jonathan Leffler (за подсказку с SQLIDEBUG=2:xyz + sqliprint и тестирование на его машине) и @bohica (за подсказку с strace ) за поддержку! Это действительно помогло мне найти реальную проблему и решить ее! +1 от меня обоим.
К сожалению, ответа не было в их постах, поэтому отвечу сам.

Резюме:

SQLPrepare и SQLExecute терпят неудачу иногда из-за некоторых ошибок, но не всех. При использовании хранимой процедуры эти функции обнаруживают больше ошибок. К сожалению, с хранимыми функциями дело обстоит иначе.

Как мне теперь ловить ошибки? Если SQLExecute успешно, я звоню SQLNumResultCols - это нормально. После этого я звоню SQLFetch, что тоже ожидается. НО, поскольку SQLFetch может дать сбой по многим причинам (например, он всегда дает сбой в хранимых процедурах), эта ошибка игнорируется. И есть while лайков

if ( SQLNumResultCols( stmt, &nAllCols ) != SQL_SUCCESS )
// ...

int nSucceededFetches = 0; // added now, see below why
while ( SQL_SUCCEEDED( SQLFetch( stmt ) ) )
{
    ++nSucceededFetches; // added now, see below why
    /* bla bla */ 
}

И вот ключ — добавьте дополнительную проверку:

if( 0 == nSucceededFetches && nColumns > 0 )

в котором говорится, что если есть возвращаемые столбцы и выборка не удалась при ПЕРВОМ вызове, то что-то не так. Тогда у меня есть

while ( SQL_SUCCESS == SQLError( 0, 0, stmt, szSqlState, &nNativeError, szError, 500, &nErrorMsg ) )
{ /* bla bla */ }

И все в порядке. Я до сих пор не понимаю, почему SQLExecute возвращает SQL_SUCCESS (даже НЕ SQL_SUCCESS_WITH_INFO ..), но это не имеет значения.