DBD::ODBC works in perl 5.8.7 but fails in 5.8.8 and above

Hi,

Back in March this year Jonathan Gillespie reported the following
error in DBD::ODBC test suite:

Can't change param 1 maxlen (51->50) after first bind at
>t/20SqlServer.t line 180.

(see http://www.mail-archive.com/dbi-users@perl.org/msg26946.html).

The same version of DBI and DBD::ODBC works fine in perl 5.8.7 but
fails in perl 5.8.8 and later. I've even tried 5.9.4. I never really
got to the root of the problem but it appears:

in dbdimp.c did a:

svGrow(phs->sv, 50+1)

but

SvLEN(phs->sv) returns 52!

DBD::ODBC does not expect this so the test fails. Since this is
continuing to fail in all Perl versions since 5.8.8 I really would
like to get this sorted out. I've checked through the perl changes files and
I cannot see anything that looks a possibility. Does anyone know why

If phs->sv is a SVt_NULL and you do:
SvUPGRADE(phs->sv, SVt_PVNV)
svGrow(phs->sv, 50+1)
SvLEN(phs->sv) returns 52 in 5.8.8 onwards

but the same code returned 51 in 5.8.7 and earlier?

Any over ideas that would help me track this down?

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com

0
martin
9/19/2006 1:47:18 PM
perl.dbi.users 11100 articles. 1 followers. Follow

5 Replies
676 Views

Similar Articles

[PageSpeed] 37

On Tue, Sep 19, 2006 at 02:47:18PM +0100, Martin J. Evans wrote:
> Hi,
> 
> Back in March this year Jonathan Gillespie reported the following
> error in DBD::ODBC test suite:
> 
> Can't change param 1 maxlen (51->50) after first bind at
> >t/20SqlServer.t line 180.
> 
> (see http://www.mail-archive.com/dbi-users@perl.org/msg26946.html).
> 
> The same version of DBI and DBD::ODBC works fine in perl 5.8.7 but
> fails in perl 5.8.8 and later. I've even tried 5.9.4. I never really
> got to the root of the problem but it appears:
> 
> in dbdimp.c did a:
> 
> svGrow(phs->sv, 50+1)
> 
> but
> 
> SvLEN(phs->sv) returns 52!
> 
> DBD::ODBC does not expect this so the test fails. Since this is
> continuing to fail in all Perl versions since 5.8.8 I really would
> like to get this sorted out. I've checked through the perl changes files and
> I cannot see anything that looks a possibility. Does anyone know why
> 
> If phs->sv is a SVt_NULL and you do:
> SvUPGRADE(phs->sv, SVt_PVNV)
> svGrow(phs->sv, 50+1)

svGrow should really be SvGROW. In fact there's no svGrow in perl
[...later...] or in DBD::ODBC. I'll assume you meant SvGROW and your
shift key got out of step.

> SvLEN(phs->sv) returns 52 in 5.8.8 onwards

SvLEN is the size of the buffer allocated to the string, not the
length of the current string in the buffer (which is SvCUR).

> but the same code returned 51 in 5.8.7 and earlier?

I don't have 5.8.8 handy and no time to grab it now (satellite link
down so I only have slow ISDN at the moment).

Perhaps SvLEN(phs->sv) was 52 before SvGROW was called?

Tim.
0
Tim
9/19/2006 3:29:37 PM
--_=XFMail.1.5.5-RC1.Linux:20060919170345:4341=_
Content-Type: text/plain; charset=us-ascii


On 19-Sep-2006 Tim Bunce wrote:
> On Tue, Sep 19, 2006 at 02:47:18PM +0100, Martin J. Evans wrote:
>> Hi,
>> 
>> Back in March this year Jonathan Gillespie reported the following
>> error in DBD::ODBC test suite:
>> 
>> Can't change param 1 maxlen (51->50) after first bind at
>> >t/20SqlServer.t line 180.
>> 
>> (see http://www.mail-archive.com/dbi-users@perl.org/msg26946.html).
>> 
>> The same version of DBI and DBD::ODBC works fine in perl 5.8.7 but
>> fails in perl 5.8.8 and later. I've even tried 5.9.4. I never really
>> got to the root of the problem but it appears:
>> 
>> in dbdimp.c did a:
>> 
>> svGrow(phs->sv, 50+1)
>> 
>> but
>> 
>> SvLEN(phs->sv) returns 52!
>> 
>> DBD::ODBC does not expect this so the test fails. Since this is
>> continuing to fail in all Perl versions since 5.8.8 I really would
>> like to get this sorted out. I've checked through the perl changes files and
>> I cannot see anything that looks a possibility. Does anyone know why
>> 
>> If phs->sv is a SVt_NULL and you do:
>> SvUPGRADE(phs->sv, SVt_PVNV)
>> svGrow(phs->sv, 50+1)
> 
> svGrow should really be SvGROW. In fact there's no svGrow in perl
> [...later...] or in DBD::ODBC. I'll assume you meant SvGROW and your
> shift key got out of step.

Yes I did.

>> SvLEN(phs->sv) returns 52 in 5.8.8 onwards
> 
> SvLEN is the size of the buffer allocated to the string, not the
> length of the current string in the buffer (which is SvCUR).
> 
>> but the same code returned 51 in 5.8.7 and earlier?
> 
> I don't have 5.8.8 handy and no time to grab it now (satellite link
> down so I only have slow ISDN at the moment).
> 
> Perhaps SvLEN(phs->sv) was 52 before SvGROW was called?

Good point, I should have mentioned that. I'll try and be a bit more
specific:

The situation appears to be:
 SvREADONLY(phs->sv) is not true
 SvTYPE(phs->sv) = 0
(void)SvUPGRADE(phs->sv, SVt_PVNV);
 SvTYPE(phs->sv) = 6
 SvLEN(phs->sv) = 0
SvGROW(phs->sv, 50 + 1);
 SvLEN(phs->sv) = 52 (returns 51 in perl 5.8.7)
 SvCUR(phs->sv)=0

The actual code is in DBD::ODBC dbdimp.c _dbd_rebind_ph(). I am
using DBI 1.52 and DBD::ODBC 1.13.

perl -V (for 5.8.4) attached.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com


--_=XFMail.1.5.5-RC1.Linux:20060919170345:4341=_
Content-Disposition: attachment; filename="perl_v"
Content-Transfer-Encoding: base64
Content-Description: perl_v
Content-Type: application/octet-stream; name=perl_v; SizeOnDisk=4477

U3VtbWFyeSBvZiBteSBwZXJsNSAocmV2aXNpb24gNSB2ZXJzaW9uIDggc3VidmVyc2lvbiA4KSBj
b25maWd1cmF0aW9uOgogIFBsYXRmb3JtOgogICAgb3NuYW1lPWxpbnV4LCBvc3ZlcnM9Mi42Ljkt
MjIuMTguYnoxNTU3MjUuZWxzbXAsIGFyY2huYW1lPWkzODYtbGludXgtdGhyZWFkLW11bHRpCiAg
ICB1bmFtZT0nbGludXggaHMyMC1iYzEtNi5idWlsZC5yZWRoYXQuY29tIDIuNi45LTIyLjE4LmJ6
MTU1NzI1LmVsc21wICMxIHNtcCB0aHUgbm92IDE3IDE1OjM0OjA4IGVzdCAyMDA1IGk2ODYgaTY4
NiBpMzg2IGdudWxpbnV4ICcKICAgIGNvbmZpZ19hcmdzPSctZGVzIC1Eb3B0aW1pemU9LU8yIC1n
IC1waXBlIC1XYWxsIC1XcCwtRF9GT1JUSUZZX1NPVVJDRT0yIC1mZXhjZXB0aW9ucyAtZnN0YWNr
LXByb3RlY3RvciAtLXBhcmFtPXNzcC1idWZmZXItc2l6ZT00IC1tMzIgLW1hcmNoPWkzODYgLW10
dW5lPWdlbmVyaWMgLWZhc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtRHZlcnNpb249NS44Ljgg
LURteWhvc3RuYW1lPWxvY2FsaG9zdCAtRHBlcmxhZG1pbj1yb290QGxvY2FsaG9zdCAtRGNjPWdj
YyAtRGNmX2J5PVJlZCBIYXQsIEluYy4gLURpbnN0YWxscHJlZml4PS91c3IgLURwcmVmaXg9L3Vz
ciAtRGFyY2huYW1lPWkzODYtbGludXggLUR2ZW5kb3JwcmVmaXg9L3VzciAtRHNpdGVwcmVmaXg9
L3VzciAtRHVzZXNocnBsaWIgLUR1c2V0aHJlYWRzIC1EdXNlaXRocmVhZHMgLUR1c2VsYXJnZWZp
bGVzIC1EZF9kb3N1aWQgLURkX3NlbWN0bF9zZW11biAtRGlfZGIgLVVpX25kYm0gLURpX2dkYm0g
LURpX3NoYWRvdyAtRGlfc3lzbG9nIC1EbWFuM2V4dD0zcG0gLUR1c2VwZXJsaW8gLURpbnN0YWxs
dXNyYmlucGVybD1uIC1VYmluY29tcGF0NTAwNSAtVXZlcnNpb25vbmx5IC1EcGFnZXI9L3Vzci9i
aW4vbGVzcyAtaXNyIC1EZF9nZXRob3N0ZW50X3JfcHJvdG8gLVVkX2VuZGhvc3RlbnRfcl9wcm90
byAtVWRfc2V0aG9zdGVudF9yX3Byb3RvIC1VZF9lbmRwcm90b2VudF9yX3Byb3RvIC1VZF9zZXRw
cm90b2VudF9yX3Byb3RvIC1VZF9lbmRzZXJ2ZW50X3JfcHJvdG8gLVVkX3NldHNlcnZlbnRfcl9w
cm90byAtRGluY192ZXJzaW9uX2xpc3Q9NS44LjcgNS44LjYgNS44LjUgNS44LjQgNS44LjMgLURz
Y3JpcHRkaXI9L3Vzci9iaW4nCiAgICBoaW50PXJlY29tbWVuZGVkLCB1c2Vwb3NpeD10cnVlLCBk
X3NpZ2FjdGlvbj1kZWZpbmUKICAgIHVzZXRocmVhZHM9ZGVmaW5lIHVzZTUwMDV0aHJlYWRzPXVu
ZGVmIHVzZWl0aHJlYWRzPWRlZmluZSB1c2VtdWx0aXBsaWNpdHk9ZGVmaW5lCiAgICB1c2VwZXJs
aW89ZGVmaW5lIGRfc2Zpbz11bmRlZiB1c2VsYXJnZWZpbGVzPWRlZmluZSB1c2Vzb2Nrcz11bmRl
ZgogICAgdXNlNjRiaXRpbnQ9dW5kZWYgdXNlNjRiaXRhbGw9dW5kZWYgdXNlbG9uZ2RvdWJsZT11
bmRlZgogICAgdXNlbXltYWxsb2M9biwgYmluY29tcGF0NTAwNT11bmRlZgogIENvbXBpbGVyOgog
ICAgY2M9J2djYycsIGNjZmxhZ3MgPSctRF9SRUVOVFJBTlQgLURfR05VX1NPVVJDRSAtZm5vLXN0
cmljdC1hbGlhc2luZyAtcGlwZSAtV2RlY2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAtSS91c3Iv
bG9jYWwvaW5jbHVkZSAtRF9MQVJHRUZJTEVfU09VUkNFIC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQg
LUkvdXNyL2luY2x1ZGUvZ2RibScsCiAgICBvcHRpbWl6ZT0nLU8yIC1nIC1waXBlIC1XYWxsIC1X
cCwtRF9GT1JUSUZZX1NPVVJDRT0yIC1mZXhjZXB0aW9ucyAtZnN0YWNrLXByb3RlY3RvciAtLXBh
cmFtPXNzcC1idWZmZXItc2l6ZT00IC1tMzIgLW1hcmNoPWkzODYgLW10dW5lPWdlbmVyaWMgLWZh
c3luY2hyb25vdXMtdW53aW5kLXRhYmxlcycsCiAgICBjcHBmbGFncz0nLURfUkVFTlRSQU5UIC1E
X0dOVV9TT1VSQ0UgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLVdkZWNsYXJhdGlvbi1hZnRl
ci1zdGF0ZW1lbnQgLUkvdXNyL2xvY2FsL2luY2x1ZGUgLUkvdXNyL2luY2x1ZGUvZ2RibScKICAg
IGNjdmVyc2lvbj0nJywgZ2NjdmVyc2lvbj0nNC4xLjAgMjAwNjAyMjggKFJlZCBIYXQgNC4xLjAt
MSknLCBnY2Nvc2FuZHZlcnM9JycKICAgIGludHNpemU9NCwgbG9uZ3NpemU9NCwgcHRyc2l6ZT00
LCBkb3VibGVzaXplPTgsIGJ5dGVvcmRlcj0xMjM0CiAgICBkX2xvbmdsb25nPWRlZmluZSwgbG9u
Z2xvbmdzaXplPTgsIGRfbG9uZ2RibD1kZWZpbmUsIGxvbmdkYmxzaXplPTEyCiAgICBpdnR5cGU9
J2xvbmcnLCBpdnNpemU9NCwgbnZ0eXBlPSdkb3VibGUnLCBudnNpemU9OCwgT2ZmX3Q9J29mZl90
JywgbHNlZWtzaXplPTgKICAgIGFsaWduYnl0ZXM9NCwgcHJvdG90eXBlPWRlZmluZQogIExpbmtl
ciBhbmQgTGlicmFyaWVzOgogICAgbGQ9J2djYycsIGxkZmxhZ3MgPScgLUwvdXNyL2xvY2FsL2xp
YicKICAgIGxpYnB0aD0vdXNyL2xvY2FsL2xpYiAvbGliIC91c3IvbGliCiAgICBsaWJzPS1scmVz
b2x2IC1sbnNsIC1sZ2RibSAtbGRiIC1sZGwgLWxtIC1sY3J5cHQgLWx1dGlsIC1scHRocmVhZCAt
bGMKICAgIHBlcmxsaWJzPS1scmVzb2x2IC1sbnNsIC1sZGwgLWxtIC1sY3J5cHQgLWx1dGlsIC1s
cHRocmVhZCAtbGMKICAgIGxpYmM9L2xpYi9saWJjLTIuMy45MC5zbywgc289c28sIHVzZXNocnBs
aWI9dHJ1ZSwgbGlicGVybD1saWJwZXJsLnNvCiAgICBnbnVsaWJjX3ZlcnNpb249JzIuMy45MCcK
ICBEeW5hbWljIExpbmtpbmc6CiAgICBkbHNyYz1kbF9kbG9wZW4ueHMsIGRsZXh0PXNvLCBkX2Rs
c3ltdW49dW5kZWYsIGNjZGxmbGFncz0nLVdsLC1FIC1XbCwtcnBhdGgsL3Vzci9saWIvcGVybDUv
NS44LjgvaTM4Ni1saW51eC10aHJlYWQtbXVsdGkvQ09SRScKICAgIGNjY2RsZmxhZ3M9Jy1mUElD
JywgbGRkbGZsYWdzPSctc2hhcmVkIC1ML3Vzci9sb2NhbC9saWInCgoKQ2hhcmFjdGVyaXN0aWNz
IG9mIHRoaXMgYmluYXJ5IChmcm9tIGxpYnBlcmwpOiAKICBDb21waWxlLXRpbWUgb3B0aW9uczog
TVVMVElQTElDSVRZIFBFUkxfSU1QTElDSVRfQ09OVEVYVAogICAgICAgICAgICAgICAgICAgICAg
ICBQRVJMX01BTExPQ19XUkFQIFVTRV9JVEhSRUFEUyBVU0VfTEFSR0VfRklMRVMKICAgICAgICAg
ICAgICAgICAgICAgICAgVVNFX1BFUkxJTyBVU0VfUkVFTlRSQU5UX0FQSQogIEJ1aWx0IHVuZGVy
IGxpbnV4CiAgQ29tcGlsZWQgYXQgTWFyICAxIDIwMDYgMTg6Mjk6NTMKICBASU5DOgogICAgL3Vz
ci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC44L2kzODYtbGludXgtdGhyZWFkLW11bHRpCiAgICAv
dXNyL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS44LjcvaTM4Ni1saW51eC10aHJlYWQtbXVsdGkKICAg
IC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjguNi9pMzg2LWxpbnV4LXRocmVhZC1tdWx0aQog
ICAgL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC41L2kzODYtbGludXgtdGhyZWFkLW11bHRp
CiAgICAvdXNyL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS44LjQvaTM4Ni1saW51eC10aHJlYWQtbXVs
dGkKICAgIC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMy9pMzg2LWxpbnV4LXRocmVhZC1t
dWx0aQogICAgL3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC44CiAgICAvdXNyL2xpYi9wZXJs
NS9zaXRlX3BlcmwvNS44LjcKICAgIC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjguNgogICAg
L3Vzci9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC41CiAgICAvdXNyL2xpYi9wZXJsNS9zaXRlX3Bl
cmwvNS44LjQKICAgIC91c3IvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMwogICAgL3Vzci9saWIv
cGVybDUvc2l0ZV9wZXJsCiAgICAvdXNyL2xpYi9wZXJsNS92ZW5kb3JfcGVybC81LjguOC9pMzg2
LWxpbnV4LXRocmVhZC1tdWx0aQogICAgL3Vzci9saWIvcGVybDUvdmVuZG9yX3BlcmwvNS44Ljcv
aTM4Ni1saW51eC10aHJlYWQtbXVsdGkKICAgIC91c3IvbGliL3Blcmw1L3ZlbmRvcl9wZXJsLzUu
OC42L2kzODYtbGludXgtdGhyZWFkLW11bHRpCiAgICAvdXNyL2xpYi9wZXJsNS92ZW5kb3JfcGVy
bC81LjguNS9pMzg2LWxpbnV4LXRocmVhZC1tdWx0aQogICAgL3Vzci9saWIvcGVybDUvdmVuZG9y
X3BlcmwvNS44LjQvaTM4Ni1saW51eC10aHJlYWQtbXVsdGkKICAgIC91c3IvbGliL3Blcmw1L3Zl
bmRvcl9wZXJsLzUuOC4zL2kzODYtbGludXgtdGhyZWFkLW11bHRpCiAgICAvdXNyL2xpYi9wZXJs
NS92ZW5kb3JfcGVybC81LjguOAogICAgL3Vzci9saWIvcGVybDUvdmVuZG9yX3BlcmwvNS44LjcK
ICAgIC91c3IvbGliL3Blcmw1L3ZlbmRvcl9wZXJsLzUuOC42CiAgICAvdXNyL2xpYi9wZXJsNS92
ZW5kb3JfcGVybC81LjguNQogICAgL3Vzci9saWIvcGVybDUvdmVuZG9yX3BlcmwvNS44LjQKICAg
IC91c3IvbGliL3Blcmw1L3ZlbmRvcl9wZXJsLzUuOC4zCiAgICAvdXNyL2xpYi9wZXJsNS92ZW5k
b3JfcGVybAogICAgL3Vzci9saWIvcGVybDUvNS44LjgvaTM4Ni1saW51eC10aHJlYWQtbXVsdGkK
ICAgIC91c3IvbGliL3Blcmw1LzUuOC44CiAgICAuCg==

--_=XFMail.1.5.5-RC1.Linux:20060919170345:4341=_--
End of MIME message
0
martin
9/19/2006 4:03:45 PM
TWFydGluIEouIEV2YW5zIHdyb3RlOgo+IE9uIDE5LVNlcC0yMDA2IFRpbSBCdW5jZSB3cm90ZToK
Pj4gT24gVHVlLCBTZXAgMTksIDIwMDYgYXQgMDI6NDc6MThQTSArMDEwMCwgTWFydGluIEouIEV2
YW5zIHdyb3RlOgo+Pj4gSSBuZXZlciByZWFsbHkKPj4+IGdvdCB0byB0aGUgcm9vdCBvZiB0aGUg
cHJvYmxlbSBidXQgaXQgYXBwZWFyczoKPj4+Cj4+PiBpbiBkYmRpbXAuYyBkaWQgYToKPj4+Cj4+
PiBzdkdyb3cocGhzLT5zdiwgNTArMSkKPj4+Cj4+PiBidXQKPj4+Cj4+PiBTdkxFTihwaHMtPnN2
KSByZXR1cm5zIDUyIQo+Pj4KPj4+IERCRDo6T0RCQyBkb2VzIG5vdCBleHBlY3QgdGhpcyBzbyB0
aGUgdGVzdCBmYWlscy4gU2luY2UgdGhpcyBpcwo+Pj4gY29udGludWluZyB0byBmYWlsIGluIGFs
bCBQZXJsIHZlcnNpb25zIHNpbmNlIDUuOC44IEkgcmVhbGx5IHdvdWxkCj4+PiBsaWtlIHRvIGdl
dCB0aGlzIHNvcnRlZCBvdXQuIEkndmUgY2hlY2tlZCB0aHJvdWdoIHRoZSBwZXJsIGNoYW5nZXMg
ZmlsZXMgYW5kCj4+PiBJIGNhbm5vdCBzZWUgYW55dGhpbmcgdGhhdCBsb29rcyBhIHBvc3NpYmls
aXR5LiBEb2VzIGFueW9uZSBrbm93IHdoeQo+Pj4KPj4+IElmIHBocy0+c3YgaXMgYSBTVnRfTlVM
TCBhbmQgeW91IGRvOgo+Pj4gU3ZVUEdSQURFKHBocy0+c3YsIFNWdF9QVk5WKQo+Pj4gc3ZHcm93
KHBocy0+c3YsIDUwKzEpCj4+IHN2R3JvdyBzaG91bGQgcmVhbGx5IGJlIFN2R1JPVy4gSW4gZmFj
dCB0aGVyZSdzIG5vIHN2R3JvdyBpbiBwZXJsCj4+IFsuLi5sYXRlci4uLl0gb3IgaW4gREJEOjpP
REJDLiBJJ2xsIGFzc3VtZSB5b3UgbWVhbnQgU3ZHUk9XIGFuZCB5b3VyCj4+IHNoaWZ0IGtleSBn
b3Qgb3V0IG9mIHN0ZXAuCj4gCj4gWWVzIEkgZGlkLgo+IAo+Pj4gU3ZMRU4ocGhzLT5zdikgcmV0
dXJucyA1MiBpbiA1LjguOCBvbndhcmRzCgpJJ3ZlIG5vdCBiZWVuIGZvbGxvd2luZyB0aGlzIHRo
cmVhZCBhdCBhbGwsIGJ1dCBzZWVpbmcgdGhlIGFib3ZlIG1hZGUgCnRoaXMgc3ByaW5nIHRvIG1p
bmQ6CgpodHRwOi8vcHVibGljLmFjdGl2ZXN0YXRlLmNvbS9jZ2ktYmluL3Blcmxicm93c2U/c2hv
d19wYXRjaD1TaG93K1BhdGNoJnBhdGNoX251bT0yNDY2NQoKUGVybCBoYXMgYWx3YXlzIGJlZW4g
YXQgbGliZXJ0eSB0byBhbGxvY2F0ZSBtb3JlIG1lbW9yeSB0aGFuIHdhcyAKcmVxdWVzdGVkIGlm
IGl0IHRoaW5rcyB0aGF0IHdvdWxkIGJlIGEgZ29vZCBpZGVhLCBhbmQgdGhhdCBpcyBleGFjdGx5
IAp3aGF0IGl0IGRvZXMgYXMgb2YgdGhlIGFib3ZlIHBhdGNoICgjMjQ2NjUpIGluIG9yZGVyIHRv
IHJlZHVjZSB0aGUgCm51bWJlciBvZiByZWFsbG9jKCkncyB0aGF0IG1pZ2h0IGJlIHJlcXVpcmVk
LgoKVGhhdCBwYXRjaCB3YXMgaW50ZWdyYXRlZCBpbnRvIDUuOC44LgoKLS0gCgoKLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSYWRhbiBDb21wdXRhdGlv
bmFsIEx0ZC4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgYW5k
IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVu
ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg
bWVzc2FnZSBpbiBlcnJvciBvciB0aGVyZSBhcmUgYW55IHByb2JsZW1zLCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuIFRoZSB1bmF1dGhvcml6ZWQgdXNlLCBkaXNjbG9zdXJl
LCBjb3B5aW5nIG9yIGFsdGVyYXRpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IGZvcmJp
ZGRlbi4gTm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBl
bWFpbCBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3Nhcmls
eSByZXByZXNlbnQgdGhvc2Ugb2YgUmFkYW4gQ29tcHV0YXRpb25hbCBMdGQuIFRoZSByZWNpcGll
bnQocykgb2YgdGhpcyBtZXNzYWdlIHNob3VsZCBjaGVjayBpdCBhbmQgYW55IGF0dGFjaGVkIGZp
bGVzIGZvciB2aXJ1c2VzOiBSYWRhbiBDb21wdXRhdGlvbmFsIHdpbGwgYWNjZXB0IG5vIGxpYWJp
bGl0eSBmb3IgYW55IGRhbWFnZSBjYXVzZWQgYnkgYW55IHZpcnVzIHRyYW5zbWl0dGVkIGJ5IHRo
aXMgZW1haWwuCg==
0
steve
9/19/2006 4:22:26 PM
On 19-Sep-2006 Steve Hay wrote:
> Martin J. Evans wrote:
>> On 19-Sep-2006 Tim Bunce wrote:
>>> On Tue, Sep 19, 2006 at 02:47:18PM +0100, Martin J. Evans wrote:
>>>> I never really
>>>> got to the root of the problem but it appears:
>>>>
>>>> in dbdimp.c did a:
>>>>
>>>> svGrow(phs->sv, 50+1)
>>>>
>>>> but
>>>>
>>>> SvLEN(phs->sv) returns 52!
>>>>
>>>> DBD::ODBC does not expect this so the test fails. Since this is
>>>> continuing to fail in all Perl versions since 5.8.8 I really would
>>>> like to get this sorted out. I've checked through the perl changes files
>>>> and
>>>> I cannot see anything that looks a possibility. Does anyone know why
>>>>
>>>> If phs->sv is a SVt_NULL and you do:
>>>> SvUPGRADE(phs->sv, SVt_PVNV)
>>>> svGrow(phs->sv, 50+1)
>>> svGrow should really be SvGROW. In fact there's no svGrow in perl
>>> [...later...] or in DBD::ODBC. I'll assume you meant SvGROW and your
>>> shift key got out of step.
>> 
>> Yes I did.
>> 
>>>> SvLEN(phs->sv) returns 52 in 5.8.8 onwards
> 
> I've not been following this thread at all, but seeing the above made 
> this spring to mind:
> 
> http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_n
> um=24665
> 
> Perl has always been at liberty to allocate more memory than was 
> requested if it thinks that would be a good idea, and that is exactly 
> what it does as of the above patch (#24665) in order to reduce the 
> number of realloc()'s that might be required.
> 
> That patch was integrated into 5.8.8.

Thanks Steve, this sounds like it would cause the affect I'm seeing and was
introduced in the right perl version too. With this information I should be
able to work on a fix to DBD::ODBC.

Thanks again.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com

0
martin
9/19/2006 4:23:36 PM
--=-QVZP27/g4eQ5wC1d1+fR
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Attached is a patch which fixes the problem in t/20SqlServer.t in
DBD::ODBC 1.13 (patch actually against latest subversion) which causes:

Can't change param 1 maxlen (51->50) after first bind at
>t/20SqlServer.t line 180.

As Steve writes below, SvGROW was changed to allocate up to the
next long boundary in perl 5.8.8 and this breaks DBD::ODBC because it expects
SvLEN to return what it passes to SvGROW (thanks for remembering
this change to Perl Steve).

The actual patch is trivial - instead of comparing exactly with what
SvLEN returns it just makes sure the length passed to bind param is less
than the buffer we've already allocated (minus a 1 for trailing NUL).

The patch also fixes some "/*" in comments in dbdimp.h.

I've included Jonathan in the CC list as he reported the problem originally.

I'm sorry I didn't push this more at the time but since trying DBD::ODBC
with SQL Server 2005 there are many more test cases in 20SqlServer.t which
would fail if we could get past this issue so it sort of galvanised me
into pursuing this again. For anyone else using SQL Server 2005,
I think you can safely ignore the errors in 20SqlServer.t
(with this patch) so long as you don't use prints in procedures
- but I will try and follow this up later.

Jeff Urlwin (if you are reading), I hope you can include this
in the next DBD::ODBC as we are getting a lot of people asking about
this failure in the tests. Also, I mailed you earlier in the year
about a problem (with a fix) with obtaining ParamValues (I think)
but I see that has not been committed to DBD::ODBC in subversion
yet either. If you want the details again - let me know and I'll
dig them out.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

On Tue, 2006-09-19 at 17:23 +0100, Martin J. Evans wrote:
> On 19-Sep-2006 Steve Hay wrote:
> > Martin J. Evans wrote:
> >> On 19-Sep-2006 Tim Bunce wrote:
> >>> On Tue, Sep 19, 2006 at 02:47:18PM +0100, Martin J. Evans wrote:
> >>>> I never really
> >>>> got to the root of the problem but it appears:
> >>>>
> >>>> in dbdimp.c did a:
> >>>>
> >>>> svGrow(phs->sv, 50+1)
> >>>>
> >>>> but
> >>>>
> >>>> SvLEN(phs->sv) returns 52!
> >>>>
> >>>> DBD::ODBC does not expect this so the test fails. Since this is
> >>>> continuing to fail in all Perl versions since 5.8.8 I really would
> >>>> like to get this sorted out. I've checked through the perl changes files
> >>>> and
> >>>> I cannot see anything that looks a possibility. Does anyone know why
> >>>>
> >>>> If phs->sv is a SVt_NULL and you do:
> >>>> SvUPGRADE(phs->sv, SVt_PVNV)
> >>>> svGrow(phs->sv, 50+1)
> >>> svGrow should really be SvGROW. In fact there's no svGrow in perl
> >>> [...later...] or in DBD::ODBC. I'll assume you meant SvGROW and your
> >>> shift key got out of step.
> >> 
> >> Yes I did.
> >> 
> >>>> SvLEN(phs->sv) returns 52 in 5.8.8 onwards
> > 
> > I've not been following this thread at all, but seeing the above made 
> > this spring to mind:
> > 
> > http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_n
> > um=24665
> > 
> > Perl has always been at liberty to allocate more memory than was 
> > requested if it thinks that would be a good idea, and that is exactly 
> > what it does as of the above patch (#24665) in order to reduce the 
> > number of realloc()'s that might be required.
> > 
> > That patch was integrated into 5.8.8.
> 
> Thanks Steve, this sounds like it would cause the affect I'm seeing and was
> introduced in the right perl version too. With this information I should be
> able to work on a fix to DBD::ODBC.
> 
> Thanks again.
> 
> Martin
> --
> Martin J. Evans
> Easysoft Ltd, UK
> http://www.easysoft.com
> 
> 


--=-QVZP27/g4eQ5wC1d1+fR
Content-Disposition: attachment; filename=dbd_odbc_patch
Content-Type: text/x-patch; name=dbd_odbc_patch; charset=UTF-8
Content-Transfer-Encoding: 7bit

Index: dbdimp.c
===================================================================
--- dbdimp.c	(revision 7847)
+++ dbdimp.c	(working copy)
@@ -2928,7 +2928,7 @@
       croak("Can't rebind or change param %s in/out mode after first bind (%d => %d)",
 	    phs->name, phs->is_inout, is_inout);
    }
-   else if (maxlen && maxlen != phs->maxlen) {
+   else if (maxlen && maxlen > phs->maxlen) {
       croak("Can't change param %s maxlen (%ld->%ld) after first bind",
 	    phs->name, phs->maxlen, maxlen);
    }
Index: dbdimp.h
===================================================================
--- dbdimp.h	(revision 7847)
+++ dbdimp.h	(working copy)
@@ -37,8 +37,8 @@
     int  odbc_sqlmoreresults_supported; /* flag to see if SQLMoreResults is supported */
     int	 odbc_defer_binding; /* flag to work around SQLServer bug and defer binding until */
 			    /* last possible moment */
-    int  odbc_force_rebind; /* force rebinding the output columns after each execute to
-       /* resolve some issues where certain stored procs can return
+  int  odbc_force_rebind; /* force rebinding the output columns after each execute to */
+  /* resolve some issues where certain stored procs can return */
        /* multiple result sets */
     int  odbc_query_timeout;
     int  odbc_async_exec; /* flag to set asynchronous execution */
@@ -86,8 +86,8 @@
     int  odbc_ignore_named_placeholders;	/* flag to ignore named parameters */
     int  odbc_default_bind_type;	/* flag to set default binding type (experimental) */
     int  odbc_exec_direct;		/* flag for executing SQLExecDirect instead of SQLPrepare and SQLExecute.  Magic happens at SQLExecute() */
-    int  odbc_force_rebind; /* force rebinding the output columns after each execute to
-       /* resolve some issues where certain stored procs can return
+  int  odbc_force_rebind; /* force rebinding the output columns after each execute to */
+			       /* resolve some issues where certain stored procs can return */
        /* multiple result sets */
     int odbc_query_timeout;
 };

--=-QVZP27/g4eQ5wC1d1+fR--

0
martin
9/19/2006 6:49:09 PM
Reply:

Similar Artilces:

update from 8.7.3.7 to 8.8.5
I have been reviewing the documentations on the upgrade but have either missed it or it is not listed. Do I have to use an eDir 8.8.0 data file first and then upgrade to 8.8.5 or can I just use the 8.8.5 data file (iso)? I will be bringing all nw srvrs up to 6.5 sp 8 prior to updating eDir. Any other heads up on the upgrading? Guess I will then start the process of learning enough Linux to bring all the nw srvrs over to the green side. : ) -- jmcg ------------------------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SH...

Upgrade 8.8.4 to 8.8.5 NW v6.5 SP7
Hi, I have a test server on NW v6.5 SP7, 8.8.4. I started to install 8.8.5. It got 6% in and the power went out to the server. Upon reboot everything loaded fine except for DS (expected). Is there away of either putting back v8.8.4 or finishing off the upgrade 8.8.5. Or is it a reinstall of the server? Thanks for any advice. -- tsher1978 ------------------------------------------------------------------------ Tsher1978, > Or is it > a reinstall of the server? > Have a look in the knowledgebase for "down server upgrade" - Anders Gustafsson ...

Upgrade NW6.5 SP8 from eDir 8.7.3.10b to 8.8.5
Hi, We currently have 10 NetWare 6.5 SP8 servers with eDirectory 8.7.3.10b. 4 with Full Read/Write Replica's and 6 with Filtered Replicas. We're planning to replace all the NetWare servers with Sles/OES2 next year, but in the meantime I'd like to upgrade them to eDirectory 8.8.5. I was wondering if anyone could give me some advice on the best way to achieve this on NetWare and can we mix versions? Is there a straight forward upgrade path on netware or should I just skip straight to migrating replica servers to Linux starting with the master? Thanks! Peter ...

eDir Netware 6.5 sp6 8.7.3.9 to 8.8.5 ??
I have several Netware 6.5 sp6 8.7.3.9 servers. When I do a version at the Console the result is Novell Open Enterprise Server Netware 6.5. I'll assume this is OES1 as we have not upgraded the Netware servers to OES2. The eDir 8.8.5 documentation lists the prerequistes as OES2 and OES2sp1 as well as Netware 6.5 sp7 or higher. Do I have to upgrade these servers to OES2 before I can upgrade to eDir 8.8.5? I would like to first patch these servers to sp8 and then upgrade eDirectory to 8.8.5. Will this be OK? All the documentation I come across specifies OES2 only and no...

8.8.4 vs 8.8.5
Should I or should I not? I have 24 NW65sp8 Edir 8.8.4 in my small school system. I see not only that 8.8.5 is out but also a FTF1 sp that looks to fix some serious issues. My question is this. Is 8.8.4 stable enough that I can wait or are their issues that I may not see yet that should push me towards upgrading as soon as possible. We also use the LDAP for authentication purposes for an Astaro firewall. The content filter for surfing allows us to have multiple profiles for allowed surfing. And based on who you are is what profile you get. This has been problematic in that we ...

Smoke [5.8.9] maint-5.8-5-g03fe696 FAIL(mc) linux 3.2.0-3-amd64 [debian] (x86_64/8 cpu)
Automated smoke report for 5.8.9 patch 03fe696d61d94bd59d878a9f81b0af85465d7e1e maint-5.8-5-g03fe696 nigelhorne.force9.co.uk: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (GenuineIntel 1600MHz) (x86_64/8 cpu) on linux - 3.2.0-3-amd64 [debian] using cc version 4.7.1 smoketime 6 minutes 1 seconds (average 20.056 seconds) Summary: FAIL(mc) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, ...

Smoke [5.8.9] maint-5.8-8-g2674b61 FAIL(F) linux 3.2.0-4-amd64 [debian] (x86_64/8 cpu)
Automated smoke report for 5.8.9 patch 2674b61957c26a4924831d5110afa454ae7ae5a6 maint-5.8-8-g2674b61 nigelhorne.force9.co.uk: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (GenuineIntel 3401MHz) (x86_64/8 cpu) on linux - 3.2.0-4-amd64 [debian] using cc version 4.7.2 smoketime 3 hours 25 minutes (average 11 minutes 25 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = m...

List::MoreUtils-0.25_1 pass on 5.10.1RC0, 5.10.0, 5.8.9, 5.8.8
Following up on my report that List::MoreUtils-0.24 failed its tests on the "maint-5.10 snapshot (aka 'RC0')" that came out on July, and Tassilo later confirming the nature of the problem ... List::MoreUtils-0.25_1 was just released on CPAN, and I have tested it manually from a download of the tarball from search.cpan.org, and the problem appears to be fixed. A clean unpack/Makefile/make/make-test passes all tests on 4 versions of Perl on my same PPCG4/MacOSX10.5.7 machine: - 5.10.1RC0 built by me with defaults, custom install loc - 5.10.0 built by m...

Edir 8.7.3.5\ 8.7.3.6\8.7.3.4
Ok Iam confused with the roll back issue. What is the Edir that is working Iam hearing Novell rolled back 8.3.6 but I can only see that 8.7.3.4 is stable but Iam not hearing if 8.7.3.5 is ok. Iam on 8.7.3.5 and Iam having issue with keeping edir healthy. So is this my issue and or how do you roll back if I need to. Also I see some said " dsrapir full attened is not the preferred way of getting ds healthy so what is this about I have not heard of this before. Thanks to anyone who can clear this up while I wait for ssupport to get back to me on the phone. Hi, 8735 came with N...

Novell 6.5 SP7 and eDir 8.8.8 and eDir 8.7.3
Hello! I have a server that I'm planning to migrate onto new hardware. I built a Migration server on the new hardware with Netware 6.5 SP7 and upgraded to eDir 8.8.2. Unfortunately I didn't notice at the time I had an old copy of the migration document and when I updated it I found there was a warning that both Machines had to be eDir 8.8.2 and Netware 6.5SP7 if you wanted to migrate to a machine with dDir 8.8.2. The machine I am migrating from is Netware 6.0. Is it ok to just uninstall eDir 8.8.2 and then install eDir 8.7.3 on the server or do I need to completely rebui...

Unable to upgrade from 8.8.2 to 8.8.5
Hello, I am getting the following error when running nds-install: ./nds-install: line 863: [: too many arguments ./nds-install: line 885: [: too many arguments ./nds-install: line 885: [: too many arguments %%% There are no components available to install. %%% Some packages required for the components may be missing in I am thinking it might be related to the version of compat installed which is 2006.1.25. gettest is installed. This is a SLES 10 Patch level 3 currently running eDir 8.8.2(v20213.03). This is the last server in the tree to be upgraded and I have not run into t...

Smoke [5.8.9] maint-5.8-4-g7d6ecb1 FAIL(Fm) freebsd 8.1-RELEASE (i386/1 cpu)
Automated smoke report for 5.8.9 patch 7d6ecb1f6c7eabec011b66526161fcf678919c99 maint-5.8-4-g7d6ecb1 qemu386freebsd8-1.bandsman.co.uk: QEMU Virtual CPU version 0.14.50 (i386/1 cpu) on freebsd - 8.1-RELEASE using cc version 4.2.1 20070719 [FreeBSD] smoketime 2 hours 51 minutes (average 9 minutes 31 seconds) Summary: FAIL(Fm) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = mak...

GW5.5.5 on NW5.1SP7 NDS 8.85c to GW6.5 on W2K3 edir 8.7.3
We have a GroupWise 5.5.5 system running on NetWare 5.1 SP7 with NDS 8.85c. The box it's running on is an old HP NetServer LH Pro with a 200MHz Pentium Pro. We would like to upgrade to GroupWise 6.5 running on a Windows 2003 Server. This server is a Pentium XEON 1.6Ghz. We have updated our NetWare 5.1 SP7 server that holds the Master replica for the Tree to eDir 8.7.3 and installed eDir 8.7.3 on the Windows 2003 Server and added it to the tree. We then installed a new GroupWise 6.5 system on this server in the same tree as our GroupWise 5.5.5 system with the intent of moving us...

Smoke [5.8.9] maint-5.8-10-g5d97567 FAIL(F) linux 3.2.0-4-amd64 [debian] (x86_64/8 cpu)
Automated smoke report for 5.8.9 patch 5d97567dd5d99fd909fe6858c74f7b2ca0ad9772 maint-5.8-10-g5d97567 nigelhorne.force9.co.uk: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (GenuineIntel 3401MHz) (x86_64/8 cpu) on linux - 3.2.0-4-amd64 [debian] using cc version 4.7.2 smoketime 3 hours 32 minutes (average 11 minutes 48 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = ...

Smoke [5.8.9] maint-5.8-4-g7d6ecb1 FAIL(mc) linux 3.1.0-1-amd64 [debian] (x86_64/8 cpu)
Automated smoke report for 5.8.9 patch 7d6ecb1f6c7eabec011b66526161fcf678919c99 maint-5.8-4-g7d6ecb1 gateway: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (GenuineIntel 3392MHz) (x86_64/8 cpu) on linux - 3.1.0-1-amd64 [debian] using cc version 4.6.2 smoketime 5 minutes 40 seconds (average 18.889 seconds) Summary: FAIL(mc) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after...

Web resources about - DBD::ODBC works in perl 5.8.7 but fails in 5.8.8 and above - perl.dbi.users

Resources last updated: 1/19/2016 2:49:39 AM