FW: CPAN Upload: J/JU/JURL/DBD-ODBC-0.34.tar.gz

There are some significant changes in this release.

 Please note that some tests may fail or report they are
 unsupported on this platform.  Notably Oracle's ODBC driver
 will fail the "advanced" binding tests in t/08bind2.t.
 These tests run perfectly under SQL Server 2000. This is
 normal and expected.  Until Oracle fixes their drivers to
 do the right thing from an ODBC perspective, it's going to
 be tough to fix the issue.
   
 Also note that some tests may be skipped, such as
 t/09multi.t, if your driver doesn't seem to support
 returning multiple result sets.

Recent updates:
DBD::ODBC 0.34

 Further revamped tests to attempt to determine if SQLDescribeParam
 will work to handle the binding types.  The t/08bind.t attempts
 to determine if SQLDescribeParam is supported.  note that Oracle's
 ODBC driver under NT doesn't work correctly when binding dates
 using the ODBC date formatting {d } or {ts }.  So, test #3 will
 fail in t/08bind.t

 New support for primary_key_info thanks to patches by Martin Evans.
 New support for catalog, schema, table and table_type in table_info
 thanks to Martin Evans.  Thanks Martin for your work and your
 continuing testing, suggestions and general support!

 Support for upcoming dbi get_info.
 Support for upcoming dbi foreign_key_info
 
DBD::ODBC 0.33_3

 Revamped tests to include tests for multiple result sets.
 The tests are ODBC driver platform specific and will be skipped
 for drivers which do not support multiple result sets.
 
=item B<DBD::ODBC 0.33_2>

 Finally tested new binding techniques with SQL Server 2000,
 but there is a nice little bug in their MDAC and ODBC
 drivers according to the knowledge base article # Q273813, titled

   "FIX: "Incorrect Syntax near the Keyword 'by' "
   Error Message with Column Names of "C", "CA" or "CAS" (Q273813)

 DBD::ODBC now does not name any of the columns A, B, C, or D
 they are now COL_A, COL_B, COL_C, COL_D.

 *** NOTE: *** I AM STRONGLY CONSIDERING MAKING THE NEW
 BINDING the default for future versions.  I do not believe
 it will break much existing code (if any) as anyone binding
 to non VARCHAR (without the ODBC driver doing a good conversion
 from the VARCHAR) will have a problem.  It may be subtle, however,
 since much code will work, but say, binding dates may not with
 some drivers.
   
 Please comment soon...
   
=item B<DBD::ODBC 0.33_1>

*** WARNING: ***
 
 Changes to the binding code to allow the use of SQLDescribeParam
 to determine if the type of column being bound.  This is
 experimental and activated by setting
 
  $dbh->{odbc_default_bind_type} = 0; # before creating the query...

 Currently the default value of odbc_default_bind_type = SQL_VARCHAR
 which mimicks the current behavior.  If you set
 odbc_default_bind_type to 0, then SQLDescribeParam will be
 called to determine the columen type.  Not ALL databases
 handle this correctly.  For example, Oracle returns
 SQL_VARCHAR for all types and attempts to convert to the
 correct type for us.  However, if you use the ODBC escaped
 date/time format such as: {ts '1998-05-13 00:01:00'} then
 Oracle complains.  If you bind this with a SQL_TIMESTAMP type,
 however, Oracle's ODBC driver will parse the time/date correctly.
 Use at your own risk!

 Fix to dbdimp.c to allow quoted identifiers to begin/end
 with either " or '.
 The following will not be treated as if they have a bind placeholder:
   "isEstimated?"
   '01-JAN-1987 00:00:00'
   'Does anyone insert a ?'



The uploaded file

    DBD-ODBC-0.34.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/J/JU/JURL/DBD-ODBC-0.34.tar.gz
  size: 225340 bytes
   md5: ec689ff661842538741d16da19354d74

No action is required on your part
Request entered by: JURL (Jeff Urlwin)
Request entered on: Thu, 07 Feb 2002 16:24:13 GMT
Request completed:  Thu, 07 Feb 2002 16:25:25 GMT

	Virtually Yours,
	Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k 

• FW: CPAN Upload: J/JU/JURL/DBD-ODBC-0.34.tar.gz by Jeff Urlwin