Michael,
FYI -- I incorporated your SQLExecDirect patch into the next release of
DBD::ODBC, with one minor change: the attribute name is odbc_execdirect,
not ExecDirect, in keeping with the DBI standards for DBD private
capabilities. I might make it a database handle attribute, that way you
could:
$dbh->{odbc_execdirect} = 1;
And get the functionality through the rest of your code. I like the
over-ride in the prepare, though!
However, I'm not sure about your other patch, though and compatibility
with other drivers/users. That's because, typically, the default for
LongReadLen is 80 and I think it might be confusing to arbitrarily limit
VARCHAR lengths to LongReadLen -- I think that would break existing
code.
Finally, next time (if there is one), can you please send me a diff -c
vs. your original? That way, I don't have to hunt through "normal"
changes too...
Thanks,
Jeff
> -----Original Message-----
> From: Michael Riber [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 03, 2002 2:29 AM
> To: 'Jeff Urlwin'
> Cc: [EMAIL PROTECTED]
> Subject: RE: DBD-ODBC for Industrial SQL
>
>
> Hi Jeff,
>
> I have managed to make a patch which allow use of ExecDirect:
>
> When $dbh->prepare() is called with the attribute
> "ExecDirect" set to a non-zero value dbd_st_prepare do NOT
> call SQLPrepare, but set the sth flag odbc_exec_direct to 1.
>
> When $sth->execute() is called it checks the odbc_exec_direct
> flag and calls SQLExecDirect if set and otherwise it calls
> SQLExecute as it normally would.
>
> Files modified:
> dbdimp.h
> dbdimp.c
>
> I hope that you can approve of the changes I made and that
> this functionality can be incorporated in a future release of
> DBD-ODBC.
>
> On another note:
> I have introduced a change that verifies that the size of an
> SQL_VARCHAR do not exceed the LongReadLen:
> case SQL_VARCHAR:
> if (fbh->ColDisplaySize > DBIc_LongReadLen(imp_sth))
> fbh->ColDisplaySize = DBIc_LongReadLen(imp_sth);
> This is due to a problem in the Informix ODBC driver that
> erroneously return the SQL_VARCHAR datatype for its LVARCHAR
> with a size of 2 GB causing an "Out of memory" fault. I have
> notified Informix, but they can not say when they have fixed
> the problem - they should use the SQL_LONGVARCHAR for the
> LVARCHAR. However this change will collide with any existing
> code that legally use VARCHAR with a length greater than
> LongReadLen. A solution to this could be to check the
> ColDisplaySize against some maximum length for VARCHARs that
> is sufficiently large to avoid problems with other ODBC
> drivers and still less than 2 GB.
>
> Thanks for you assistence and keep up the good work.
>
> Best regards
> Michael
>
> -----Original Message-----
> From: Jeff Urlwin [mailto:[EMAIL PROTECTED]]
> Sent: 01 October 2002 18:20
> To: Michael Riber; [EMAIL PROTECTED]
> Subject: RE: DBD-ODBC for Industrial SQL
>
>
> See below.
>
> >
> >
> > Hi,
> >
> > I am using Perl with DBD-ODBC to extract live values from an
> > Wonderware Industrial SQL which runs on top of a Microsoft
> SQL Server.
> >
> > The platform is Windows NT 4.0, Microsoft SQL Server 6.50.193 and
> > Industrial SQL version 7.0.211, Microsoft SQL Server ODBC version
> > 3.70.0961.
> >
> > When I use:
> > DBI prepare - SQLPrepare
> > DBI execute - SQLExecute
> > DBI fetchrow - SQLFetch
> > to select the live data from the Industrial SQL it returns no rows.
> > This is due to the fact that only the SQLExecDirect ODBC
> function will
> > cause Industrial SQL to access and provide the live data.
> >
> > When using Microsoft MDAC ODBC Test the data are provided with no
> > problems.
> >
> > In other words I need to make DBI use the ExecDirect ODBC function.
> >
> > Can I do this in a way that will allow me to use the DBI
> fetchrow to
> > read the data?
> >
> > I have read in a release note for DBD-ODBC 0.35 that $dbh->func(
> > $stmt,
> > ExecDirect) can be used to call ExecDirect, but will this
> allow me to read
> > the data afterwards?
>
> No, it won't, but it could... It kills the statement handle
> as it was designed to help make the "do()" functionality use
> the ExecDirect. The quickest way of handling it, would be to:
>
> - ExecDirect returns an sth instead of the row count
> - do() with no params calls ExecDirect (as it does now)
> then calls $sth->rows and finishes the handle
> - That would leave ExecDirect available for your purpose.
>
> I can't say that I'll be able to get to it soon. There are a
> few bug fixes in the queue. Patches welcome!
>
> Regards,
>
> Jeff
>
>
>
>
