On Mon, 2006-10-30 at 20:32 +0000, Tim Bunce wrote:
> On Mon, Oct 30, 2006 at 07:37:47PM +0000, Martin J. Evans wrote:
> > I'm trying to debug a DBD::ODBC problem and the code is full of:
> >
> > if (ODBC_TRACE_LEVEL(imp_sth) >= 2) {
> > PerlIO_printf(DBIc_LOGPIO(imp_dbh), "something");
> > PerlIO_flush(DBIc_LOGPIO(imp_dbh));
> > }
> >
> > Are all those PerlIO_flush calls required? I'm finding it difficult to
> > see the wood for the trees and I notice other DBDs don't use
> > PerlIO_flush. Can they be removed?
>
> Probably. The trick is to set the filehandle to automatic flushing.
> Sadly that's a little tricky to do in a perl-version-portable way
> (long story) so the DBI does it's best with:
>
> /* If the tests fail with errors about 'setlinebuf' then try */
> /* deleting the lines in the block below except the setvbuf one */
> #ifndef PerlIO_setlinebuf
> #ifdef HAS_SETLINEBUF
> #define PerlIO_setlinebuf(f) setlinebuf(f)
> #else
> #ifndef USE_PERLIO
> #define PerlIO_setlinebuf(f) setvbuf(f, Nullch, _IOLBF, 0)
> #endif
> #endif
> #endif
>
> and this in set_trace_file():
>
> /* if this line causes your compiler or linker to choke */
> /* then just comment it out, it's not essential. */
> PerlIO_setlinebuf(fp); /* force line buffered output */
>
> Tim.
Cheers Tim,
Based on what you've said and the other DBD's code I think I'll remove
them and leave it up to DBI to attempt to do the right thing. There are
20 PerlIO_flush calls but many of the PerlIO_printf calls are not
followed by flushes and I'm seeing them ok - seems an unnecessary waste
and clutters the code a lot.
Jeff, if you are reading this I'm starting to amass a number of patches
for DBD::ODBC now (like the one causing a make test error to SQL Server
in Perl 5.8.8 I posted recently (which we, Easysoft, are getting a load
of calls about) ((reported on rt) and one I hope to complete that Steven
Moore pointed out with DB2 on dbi-users with binding and procedures).
I've also got a memory corruption issue with:
In dbdimp.h:
char name[1]; /* struct is malloc'd bigger as needed */
followed in dbdimp.c with a sprintf(phs->name, "%d", parameter_number);
but:
1. I cannot seen any evidence in dbdimp.c that this is the case
2. I can't see how it could grow given it is defined as a char[1]
without at least a warning.
Any chance I could get write access to DBD::ODBC subversion or that
you'd accept a complete patch from me?
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
