Home/ Questions/Q 7688073
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T19:50:21+00:00

I’m trying to solve an issue where a script crashes with little-to-no error information

  • 0

I’m trying to solve an issue where a script crashes with little-to-no error information on one server (db1), but not on another server (db2), despite both environments being identical in every way (except one) that I can find.

Here is the script, test.pl:

use strict;
use warnings;

use DBI;
use Data::Dumper;

$ENV{LD_LIBRARY_PATH} = "/var/local/odbc";
$ENV{ODBCHOME}        = "/var/local/odbc";
$ENV{ODBCINI}         = "/etc/odbc.ini";

my $dbh = DBI->connect( "dbi:ODBC:db", "foo", "bar" ) or die "$DBI::err\n$DBI::errstr\n$DBI::state\n";
$dbh->{RaiseError} = "0";
$dbh->{AutoCommit} = "1";
$dbh->{LongReadLen} = 1024;

#$dbh->{TraceLevel} = 10;

my $sth = $dbh->prepare( "SELECT * FROM table WHERE x='y'" ) or die "$DBI::err\n$DBI::errstr\n$DBI::state\n";
$sth->execute or die "$DBI::err\n$DBI::errstr\n$DBI::state\n";

my $data = $sth->fetchall_hashref( 'x' );
print Data::Dumper->Dump( [$data] );

And here is the output (note: the death is at $sth->execute):

$ ./test
DBD::ODBC::st execute failed: [DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1) at ./test line 24.
-1
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)
HY000

TraceLevel 10 does not shed light for me:

$ ./test
    DBI::db=HASH(0x1f2cc8e0) trace level set to 0x0/10 (DBI @ 0x0/0) in DBI 1.52-ithread (pid 27494)
    -> prepare for DBD::ODBC::db (DBI::db=HASH(0x1f2cc510)~0x1f2cc8e0 'SELECT * FROM table WHERE x='y'') thr#1effa010
    dbih_setup_handle(DBI::st=HASH(0x1f2cca60)=>DBI::st=HASH(0x1f2ccb60), DBD::ODBC::st, 1f2cca70, Null!)
    dbih_make_com(DBI::db=HASH(0x1f2cc8e0), 1f2d1e30, DBD::ODBC::st, 376, 0) thr#1effa010
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), Err, DBI::db=HASH(0x1f2cc8e0)) SCALAR(0x1f183620) (already defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), State, DBI::db=HASH(0x1f2cc8e0)) SCALAR(0x1f1836a0) (already defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), Errstr, DBI::db=HASH(0x1f2cc8e0)) SCALAR(0x1f183660) (already defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), TraceLevel, DBI::db=HASH(0x1f2cc8e0)) 10 (already defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), FetchHashKeyName, DBI::db=HASH(0x1f2cc8e0)) 'NAME' (already defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), HandleSetErr, DBI::db=HASH(0x1f2cc8e0)) undef (not defined)
    dbih_setup_attrib(DBI::st=HASH(0x1f2ccb60), HandleError, DBI::db=HASH(0x1f2cc8e0)) undef (not defined)
    initializing sth query timeout to 0
    ignore named placeholders = 0
    SQLPrepare returned 0

    dbd_st_prepare'd sql f523212832, ExecDirect=0
        SELECT * FROM table WHERE x='y'
    <- prepare= DBI::st=HASH(0x1f2cca60) at ./test line 23
    -> execute for DBD::ODBC::st (DBI::st=HASH(0x1f2cca60)~0x1f2ccb60) thr#1effa010
    dbd_st_execute (outparams = 0)...
    dbd_st_execute (for hstmt 523212832 before)...
    dbd_st_execute (for hstmt 523212832 after, rc = -1)...
dbd_error: err_rc=-1 rc=0 s/d/e: 523212832/523051280/523050880
dbd_error: SQL-HY000 (native 0): [DataDirect][ODBC SQL Server Driver] (SQL-HY000)
dbd_error: SQL-HY000 (native 0): [DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
dbd_error: err_rc=-1 rc=0 s/d/e: 0/523051280/523050880
dbd_error: err_rc=-1 rc=0 s/d/e: 0/0/523050880
st_execute/SQLExecute error -1 recorded: [DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)
    !! ERROR: -1 '[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)' (err#0)
    <- execute= undef at ./test line 24
DBD::ODBC::st execute failed: [DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1) at ./test line 24.
-1
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)
HY000
    -> DESTROY for DBD::ODBC::st (DBI::st=HASH(0x1f2ccb60)~INNER) thr#1effa010
   SQLFreeStmt called, returned 0.
       ERROR: -1 '[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)' (err#0)
    <- DESTROY= undef
    -> DESTROY for DBD::ODBC::db (DBI::db=HASH(0x1f2cc8e0)~INNER) thr#1effa010
  DBD::ODBC Disconnected!
       ERROR: -1 '[DataDirect][ODBC SQL Server Driver] (SQL-HY000)
[DataDirect][ODBC SQL Server Driver] (SQL-HY000)(DBD: st_execute/SQLExecute err=-1)' (err#0)
    <- DESTROY= undef

I straced the runs on both servers and the ONLY difference happens toward the end of execution when the script on db1 attempts to open and read from the file /var/local/odbc/DDODBC.DAT and proceeds to crash. The run on db2 does nothing of the sort and goes on to do its work successfully. After a good amount of filesystem crawling and file comparing, I’ve confirmed that the odbc.ini config files are the same for both servers and that the entire structure and contents of /var/local/odbc are also the same, except that DDODBC.DAT exists on db1, but not db2. The environment variables are also the same.

Moving DDODBC.DAT somewhere else causes the script to run to success. The file is re-created, used, and then the script goes on to do its work (as seen from strace). If I replace the original DDODBC.DAT, the script crashes again. The obvious conclusion here is that the file was at fault, with bad data, corruption, or the like. strace on the new, successful, runs on db1 only differ from those on db2 by four
lines:

open("/var/local/odbc/DDODBC.DAT", O_RDONLY) = 4
lseek(4, 0, SEEK_SET)                   = 0
read(4, ..., 1212) = 1212
close(4)                                = 0

What is the file DDODBC.DAT being used for and what causes it to be created? The Googles were no help for me.

For the record:

$ perl --version
This is perl, v5.8.8 built for x86_64-linux-thread-multi
$ uname -srmo
Linux 2.6.18-141.el5 x86_64 GNU/Linux
$ odbcinst --version
unixODBC 2.2.11
$ perl -MDBD::ODBC -e 'print $DBD::ODBC::VERSION, "\n";'
1.13
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    DataDirect has confirmed that the file DDODBC.DAT is (typically) created when there is a licensing conflict on the host. In our case, our license is for servers with a maximum of 16 CPUs, however we installed the driver on a host with 24 CPUs. The driver realized this, made note of it (with DDODBC.DAT), and will, eventually, switch itself into evaluation mode.

    • 0