FreeTDS Development Group

["Michael Horowitz" <michael.horowitz AT storagenetworks.com>]

Hello again,

I added an insert statement that violated a primary key constraint, and
this is what I get:

    DBI 1.20-nothread dispatch trace level set to 3
    Note: perl is running without the recommended perl -w option
    -> DBI->connect(DBI:Sybase:DBNAME1, username, ****)
    -> DBI->install_driver(Sybase) for solaris perl=5.006 pid=19680 ruid=0
euid=0
       install_driver: DBD::Sybase version 0.94 loaded from
/opt/perl-5.6.0/lib/site_perl/5.6.0/sun4-solaris/DBD/Sybase.pm
    New DBI::dr (for DBD::Sybase::dr, parent=, id=)
    dbih_setup_handle(DBI::dr=HASH(0x1703dc)=>DBI::dr=HASH(0xfb4ec),
DBD::Sybase::dr, 0, Null!)
    dbih_make_com(Null!, DBD::Sybase::dr, 84)
    <- install_driver= DBI::dr=HASH(0x1703dc)
    -> connect for DBD::Sybase::dr (DBI::dr=HASH(0x1703dc)~0xfb4ec
'DBNAME1' 'username' **** HASH(0xef160))
    New DBI::db (for DBD::Sybase::db, parent=DBI::dr=HASH(0xfb4ec), id=)
    dbih_setup_handle(DBI::db=HASH(0xfb4a4)=>DBI::db=HASH(0x1acfec),
DBD::Sybase::db, 170130, Null!)
    dbih_make_com(DBI::dr=HASH(0xfb4ec), DBD::Sybase::db, 1960)
Changed database context to 'dbname'.
    syb_db_login() -> checking for chained transactions
    syb_db_login() -> chained transactions are  supported
    <- connect= DBI::db=HASH(0xfb4a4) at DBI.pm line 426
    -> STORE for DBD::Sybase::db (DBI::db=HASH(0x1acfec)~INNER
'PrintError' 1)
    STORE DBI::db=HASH(0x1acfec) 'PrintError' => 1
    <- STORE= 1 at DBI.pm line 451
    -> STORE for DBD::Sybase::db (DBI::db=HASH(0x1acfec)~INNER
'AutoCommit' 1)
    <- STORE= 1 at DBI.pm line 451
    <- connect= DBI::db=HASH(0xfb4a4)
    -> do for DBD::Sybase::db (DBI::db=HASH(0xfb4a4)~0x1acfec 'insert into
names(uid, login) VALUES (101,NULL)')
2   -> prepare for DBD::Sybase::db (DBI::db=HASH(0x1acfec)~INNER 'insert
into names(uid, login) VALUES (101,NULL)' undef)
    New DBI::st (for DBD::Sybase::st, parent=DBI::db=HASH(0x1acfec), id=)
    dbih_setup_handle(DBI::st=HASH(0xfb498)=>DBI::st=HASH(0x1acfbc),
DBD::Sybase::st, fb4b0, Null!)
    dbih_make_com(DBI::db=HASH(0x1acfec), DBD::Sybase::st, 396)
2   <- prepare= DBI::st=HASH(0xfb498) at Sybase.pm line 131
    -> execute for DBD::Sybase::st (DBI::st=HASH(0xfb498)~0x1acfbc)
    syb_st_execute() -> ct_command() OK
    syb_st_execute() -> ct_send() OK
Violation of PRIMARY KEY constraint 'PK_names'. Cannot insert duplicate
key in object 'names'.
The statement has been terminated.
    st_next_result() -> ct_results(13) == 1
    st_next_result() -> ct_results(12) == 1
ct_results() final retcode = 15
    st_next_result() -> lasterr = 0, lastsev = 0
    syb_st_execute() -> got CS_CMD_DONE: resetting ACTIVE, moreResults,
dyn_execed
    <- execute= undef at Sybase.pm line 132
    <- do= undef at testdb3.pl line 15
    <> DESTROY ignored for outer handle DBI::st=HASH(0xfb498) (inner
DBI::st=HASH(0x1acfbc))
    -> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x1acfbc)~INNER)
    syb_st_destroy: called on 1a7020...
    syb_st_destroy(): freeing imp_sth->statement
    syb_st_destroy(): cmd dropped: 1
    <- DESTROY= undef
    <> DESTROY ignored for outer handle DBI::db=HASH(0xfb4a4) (inner
DBI::db=HASH(0x1acfec))
    -> DESTROY for DBD::Sybase::db (DBI::db=HASH(0x1acfec)~INNER)
    syb_db_disconnect() -> ct_close()
    <- DESTROY= undef
    -- DBI::END
    -> disconnect_all for DBD::Sybase::dr (DBI::dr=HASH(0x1703dc)~0xfb4ec)
    <- disconnect_all= 1 at DBI.pm line 468
    -> DESTROY in DBD::_::common for DBD::Sybase::dr
(DBI::dr=HASH(0xfb4ec)~INNER)
    <- DESTROY= undef during global destruction
    <> DESTROY for DBI::dr=HASH(0x1703dc) ignored (inner handle gone)

Looks like you are on the right track.  It is just printing to stderr for
any message rather than passing them to the proper DBI error handling
methods.

I appreciate all the help.

--Mike

> Michael Horowitz writes:
>  > I am not sure what I should be looking for, but this is what I get back:
> 
>  >     dbih_setup_handle(DBI::db=HASH(0xfb480)=>DBI::db=HASH(0x1acfc8),
>  > DBD::Sybase::db, 170130, Null!)
>  >     dbih_make_com(DBI::dr=HASH(0xfb4c8), DBD::Sybase::db, 1960)
>  > Changed database context to 'dbname'.
>  >     syb_db_login() -> checking for chained transactions
> 
> Weird. This looks like the error (CS_SERVERMSG *srvmsg struct) does
> not have any error number at all - just the message itself.
> 
> This is treated by the callback as a PRINT statement, and displayed
> via a fprintf(stderr) call.
> 
> This might point to a bug of some sort.
> 
> Could you with the same setup try to force an error (for example a
> duplicate insert error), and see if the error code actually gets sent
> back?
> 
> Michael
> -- 
> Michael Peppler - Data Migrations Inc. - http://www.mbay.net/~mpeppler
> mpeppler AT peppler.org - mpeppler AT mbay.net
> International Sybase User Group - http://www.isug.com