On 19/07/15 15:41, Tim Bunce wrote:
On Thu, Jul 16, 2015 at 10:46:35AM -0700, David E. Wheeler wrote:
On Jul 16, 2015, at 6:40 AM, Tim Bunce tim.bu...@pobox.com wrote:
Well, this contains lots more light! ...
- dbd_st_execute for 03fdf4e0
parse_params statement
SELECT c.change_id
On Mon, Jul 20, 2015 at 08:55:40AM +0100, Martin J. Evans wrote:
On 19/07/15 15:41, Tim Bunce wrote:
Please also see the issue I reported in DBI back in 2012:
https://rt.cpan.org/Ticket/Display.html?id=81911
I had to add various workarounds and a warning to DBD::ODBC.
Ah, thanks for the
On Sun, Jul 19, 2015 at 06:39:59PM -0700, David E. Wheeler wrote:
On Jul 19, 2015, at 7:41 AM, Tim Bunce tim.bu...@pobox.com wrote:
Internally the DBI has a DBIc_ROW_COUNT(sth) macro that has an IV type.
That's a signed int that would be 64 bits on most modern systems.
On many of those
On 20/07/15 14:15, Tim Bunce wrote:
On Mon, Jul 20, 2015 at 08:55:40AM +0100, Martin J. Evans wrote:
On 19/07/15 15:41, Tim Bunce wrote:
Please also see the issue I reported in DBI back in 2012:
https://rt.cpan.org/Ticket/Display.html?id=81911
I had to add various workarounds and a warning
On Mon, Jul 20, 2015 at 02:54:53PM +0100, Martin J. Evans wrote:
On 20/07/15 14:15, Tim Bunce wrote:
I think that would work for me - I'm happy to test it our here if you want to
give it a go.
IIRC, when this was last discussed the problem is that some drivers
might not set
On Mon, Jul 20, 2015 at 06:00:53PM +0100, Tim Bunce wrote:
On Mon, Jul 20, 2015 at 02:54:53PM +0100, Martin J. Evans wrote:
I also noticed something I should have seen before: dbd_st_rows() is
defined as returning an int. I _think_ it would be safe to change the
definition to returning an IV