1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
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
|
