> On Feb 21, 2017, at 2:34 PM, Sam wrote:
>
> One can also turn on the DBI trace log as well.
Thanks, Sam! That helped a lot. Now I know which subs are involved in
creating the SQL so I’m much closer to tracking this down.
This is why they say that two heads are better than o
On 02/21/2017 04:12 PM, David Precious wrote:
On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl wrote:
On Feb 21, 2017, at 8:34 AM, Uri Guttman
wrote:
you can't trace it from the value. but you can write code where
that value is stuffed into the db and look for a reference vs 1 or
a blank. then yo
On 02/21/2017 05:12 PM, David Precious wrote:
On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl wrote:
On Feb 21, 2017, at 8:34 AM, Uri Guttman
wrote:
you can't trace it from the value. but you can write code where
that value is stuffed into the db and look for a reference vs 1 or
a blank. then yo
On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl wrote:
> > On Feb 21, 2017, at 8:34 AM, Uri Guttman
> > wrote:
> >
> > you can't trace it from the value. but you can write code where
> > that value is stuffed into the db and look for a reference vs 1 or
> > a blank. then you can dump the call stack
> On Feb 21, 2017, at 8:34 AM, Uri Guttman wrote:
>
> you can't trace it from the value. but you can write code where that value is
> stuffed into the db and look for a reference vs 1 or a blank. then you can
> dump the call stack (with caller()) or do other debugging. something is
> putting a
On 02/21/2017 11:28 AM, SSC_perl wrote:
In a MySQL db I have a `customers` table with a field called `hide`.
There are some strange values that I’d like to know where they’re coming from.
In most records `hide` is blank, some others have the value ‘1’, but a handful
have values like
In a MySQL db I have a `customers` table with a field called `hide`.
There are some strange values that I’d like to know where they’re coming from.
In most records `hide` is blank, some others have the value ‘1’, but a handful
have values like HASH(0x2ced735).
I take it from w
