[Dbix-class] Strange statistically significant failure for DBIC with Sybase

[Phillip Moore]

I continued to dig into this, and even with DBI_TRACE set to 15 (the
maximum value), I can't see what data values are returned by the various
API calls.   The return values from fetch*_arrayref are displayed as a
reference address:

    <- fetchall_arrayref= ( [ ARRAY(0xb95ea60) ] ) [1 items] row2 at
//ms/dist/perl5/PROJ/DBIx-Class/0.08250/lib/perl5/DBIx/Class/Storage/DBI/S\
ybase/ASE.pm line 341 via  at
//ms/dist/perl5/PROJ/DBIx-Class/0.08250/lib/perl5/DBIx/Class/Storage/DBI.pm
line 1908

The interesting information is inside that ARRAY ref, unfortunately.

I also can see ZERO differences between the trace of a successful insert
and a failed one.   There are no extra API calls, indicating an additional
select, for example.   I could provide the traces if anyone cares, but I
can't really keep investing more time into this, because...

The next thing I tried solved the problem: I added the missing metadata to
my add_columns() calls, and switched to using NoBindVars, and the code
works perfectly.   So, sadly, I did NOT get to a root cause, and after
losing a couple of days to this, I'm regretfully going to move on, since I
have what amounts to a workaround.  I don't see how the use of placeholders
will make any difference to how my application ends up working, and in this
case, not working.

Many thanks to Peter and others for the debugging hints.   Maybe someday
I'll be able to get rid of Sybase, and move onto a more supported RDBMS,
but until then, you might hear me whining in this forum again.



On Tue, Feb 4, 2014 at 12:30 PM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:

> On Tue, Feb 04, 2014 at 12:19:48PM -0500, Phillip Moore wrote:
> > OK, that must have gone right over my head, 'cause I did read it, but I
> > don't see why that means I should expect there to be no trace output.
> >
> > How do you trace the SQL that is generated when the create() method is
> > called then?
>
> Several ways:
>
> You either preclude DBIC from using an extra connection (by wrapping
> your create in a transaction, which will have little effect over Sybase,
> but will offer a clue to DBIC to do something else, see second code I
> linked)
>
> Or you reach into the storage that holds the secondary connection (deep
> internals, do not use in production):
> $schema->storage->_writer_storage->_dbh->...
>
> > Obviously, I'm just turning on tracing on the connection
> > associated with my $dbh, but if that secondary connection isn't exposed
> to
> > me somehow, are you saying my only recourse is to trace the ENTIRE
> > application execution, and then wade through the mountain of data?
>
> That's the last option yes, but the above is easier.
>
> >
> > Oh, BTW, I tried switching to using NoBindVars, and was immediately
> > reminded of why that failed for me last year:
> >
> > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Sybase::st
> > execute failed: Server message number=257 severity=16 state=1 line=1 \
> > server=NYTIBV6T228 text=Implicit conversion from datatype 'VARCHAR' to
> > 'NUMERIC' is not allowed.  Use the CONVERT function to run this query.
> >  Server message number=257 severity=16 state=1 line=1 server=NYTIBV6T228
> > text=Implicit conversion from datatype 'VARCHAR' to 'NUMERIC' is not a\
> > llowed.  Use the CONVERT function to run this query.
> >   [for Statement "INSERT INTO [ENGN_afsvolume] ( [name], [target],
> > [toplevel], [type]) VALUES ( 'canon.root', '9', '1', 'cn' )
> > SELECT @@IDENTITY"] at ./util/vms_bootstrap_database line 253
> >
> > That '9', and '1' are both foreign keys which are numerics, and the
> > dataserver doesn't like them to be quoted.
> >
>
> You do not have sufficient metadata on the 'target' and 'toplevel'
> columns. If you add data_type => $whateverthetypeis_likely_int to your
> add_columns hashref - DBIC will stop quoting:
>
> https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.08270/lib/DBIx/Class/Storage/DBI/Sybase/ASE/NoBindVars.pm#L28
>
> Cheers
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20140204/c93e9c73/attachment.htm>