libdbd-odbc-perl (1.50-1) unstable; urgency=medium

  NOTES from upstream Changes file:

  [CHANGE IN BEHAVIOUR]

  * As warned years ago, this release removes the odbc_old_unicode attribute.

  * As warned years ago, the private data_sources method has been removed -
    use DBI one instead.

 -- gregor herrmann <gregoa@debian.org>  Sat, 26 Jul 2014 13:43:17 +0200

libdbd-odbc-perl (1.48-1) unstable; urgency=medium

  NOTES from upstream Changes file:

  [CHANGE IN BEHAVIOUR]

  * As warned in release 1.45, the binding of unicode parameters to
    char/varchar columns has changed significantly. If you don't attempt
    to insert unicode into char/varchar columns or if you only inserted
    unicode into nchar/nvarchar columns you should see no difference.
    From this release, unicode data inserted into
    char/varchar/longvarchar columns is bound as SQL_WCHAR and not
    whatever the driver reports the parameter as (which is mostly
    SQL_CHAR).

  * Previously if DBD::ODBC received an error or (SQL_SUCCESS_WITH_INFO)
    from an ODBC API call and then the driver refused to return the
    error state/text DBD::ODBC would issue its own error saying "Unable
    to fetch information about the error" and state IM008. That state
    was wrong and has been changed to HY000. 

 -- Xavier Guimard <x.guimard@free.fr>  Fri, 21 Mar 2014 06:29:40 +0100

libdbd-odbc-perl (1.43-1) unstable; urgency=low

  NOTES from upstream Changes file:

  [CHANGE IN BEHAVIOUR]

  * As I warned literally years ago DBD::ODBC's private function
    DescribeCol has been removed. You can use DBI's statement attributes
    like NAME, PRECISION etc, instead. All test code has been changed to
    remove calls to DescribeCol and GetTypeInfo.

  * DBD::ODBC allowed you to change the bound column type in bind_col
    after the column was already bound. It now does not allow this
    and issues a warning.

  * You can nolonger override the bound column type (except with
    SQL_NUMERIC and SQL_DOUBLE). All columns are now bound as either
    SQL_C_LONG (integer columns) or SQL_C_[W]CHAR (all other columns).
    If you are calling bind_col with a TYPE => xxx it most likely did
    not do what you expected and you should examine it carefully with a
    view to removing it altogether. As a result you no longer have to
    override the bind type for MS SQL Server XML columns - these will be
    bound as SQL_C_CHAR or SQL_C_WCHAR depending on whether Unicode is
    enabled.

  * Integer columns are now bound as SQL_C_LONGs and not as before,
    SQL_C_CHAR. This should not matter to you but if you were adding 0
    to your integer columns retrieved to make them behave like integers
    you should nolonger need to do it.

 -- Xavier Guimard <x.guimard@free.fr>  Tue, 30 Oct 2012 07:24:10 +0100

libdbd-odbc-perl (1.37-1) unstable; urgency=low

  NOTES from upstream Changes file:

  [CHANGE IN BEHAVIOUR]

  * The odbc_disable_array_operations has been replaced with
    odbc_array_operations and the default for array operations is off.
    Sorry, but I warned this was experimental. The
    ODBC_DISABLE_ARRAY_OPERATIONS env var remains.

  * In execute_for_fetch set the parameter status array to all 9999
    (which is invalid) so we can see if the ODBC driver actually sets
    them and we can warn if they don't.

  * For freeTDS default odbc_disable_array_operations to 1 as no
    version of the freeTDS driver can be found that works. I was
    requested to do this by the dbix-class guys. I may revert this
    later if freeTDS is fixed.

  * as above for MS Access. It is a shame I cannot find any way of
    finding out if a driver is capable of array operations.

 -- gregor herrmann <gregoa@debian.org>  Tue, 10 Apr 2012 19:44:26 +0200

libdbd-odbc-perl (1.35-1) unstable; urgency=low

  NOTE from upstream Changes file:

  Prior to this release if you called selectall_* methods with a
  non-select statement DBD::ODBC would raise an error saying "no
  select statement currently executing".  See RT 68720. After
  discussions on dbi-dev the concensus seems to be that issuing a
  warning in this case is better so that is what I've done. As a
  result t/rt_68720.t has been removed and
  t/85_selectall_non_select.t has been added.

 -- gregor herrmann <gregoa@debian.org>  Sun, 18 Mar 2012 18:36:09 +0100

libdbd-odbc-perl (1.29-1) unstable; urgency=low

  NOTE from upstream Changes file:
  
  The 1.28 development releases made a change which causes a generic
  error to be reported when an ODBC call fails but an error message
  is not retrieved from the ODBC Driver. It appears this has caught
  out a few ODBC drivers - notably freeTDS and Firebird. You now may
  see errors that were missed before e.g., DBIx::Class's tests for
  Firebird now errors test 21 "outer txn rolled back" (and others)
  because SQLRowCount returns an error after "ROLLBACK TO SAVEPOINT
  savepoint_0"; before this error was missed.

 -- gregor herrmann <gregoa@debian.org>  Wed, 09 Mar 2011 17:34:36 +0100

libdbd-odbc-perl (1.27-1) unstable; urgency=low

  This release marks a change where DBD::ODBC has now gone entirely
  ODBC 3, and relies on the ODBC Driver Manager to map calls to
  ODBC 2 drivers. This change may break applications relying on the
  former ODBC 2 functionality.

 -- Jonathan Yu <jawnsy@cpan.org>  Mon, 21 Feb 2011 10:09:35 -0500
