Patch to DBI::DBD.pm (v1.21)

---559023410-33463914-1013562156=:12790
Content-Type: TEXT/PLAIN; charset=US-ASCII

Tim,

Here's a patch to the DBI::DBD documentation module, based on the
version shipped with DBI 1.21.

It's done some simple uncontroversial things, such as fix up URLs and
mailing list addresses (and fixed my email address).  There are a few
basically non-controversial grammatical corrections.

There are a number of places where I've used the format:

	=over 4

	*FIX ME* ...some string of questions or comments...

	=back 4

Someone, possibly you, Tim, needs to address those questions and give
me an answer, and I'll try to get those merged back into the document.

There's nowhere where I think the changes I've made are truly
controversial, though if anyone cares to correct me on which version of
Perl required prototypes in the C compiler (I said 5.6), then that
detail can be fixed.

If the attachment gets munged somewhere along the line, I'll resend in
any suitable alternative format.

-- 
Jonathan Leffler                           #include <disclaimer.h>
STSM, Informix Database Engineering, IBM Data Management Solutions
Phone: +1 650-926-6921                          Tie-line: 630-6921
Email: jleffler@us.ibm.com (jleffler@informix.com)
Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
            *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Please update your address book to use jleffler@us.ibm.com because
jleffler@informix.com will not work starting 2002-07-01.  Expect
slower responses because I can't use Lotus Notes as fast as Unix
email.  One day, this signature will shrink!

---559023410-33463914-1013562156=:12790
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dbi-dbd.diffs"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.44.0202121702360.12790@anubis.menlo.ibm.com>
Content-Description: 
Content-Disposition: attachment; filename="dbi-dbd.diffs"

LS0tIERCRC5wbS5vbGQJVHVlIEZlYiAxMiAxNjoxMzowMiAyMDAyDQorKysg
REJELnBtCVR1ZSBGZWIgMTIgMTY6NTM6NDEgMjAwMg0KQEAgLTEsOCArMSw4
IEBADQogIyAkSWQ6IERCRC5wbSx2IDExLjIgMjAwMS8wOC8yNCAyMjoxMDo0
NCB0aW1ibyBFeHAgJA0KICMNCi0jIENvcHlyaWdodCAoYykgMTk5Ny0yMDAw
IEpvbmF0aGFuIExlZmZsZXIsIEpvY2hlbiBXaWVkbWFubiBhbmQgVGltIEJ1
bmNlDQorIyBDb3B5cmlnaHQgKGMpIDE5OTctMjAwMiBKb25hdGhhbiBMZWZm
bGVyLCBKb2NoZW4gV2llZG1hbm4gYW5kIFRpbSBCdW5jZQ0KICMNCiAjIFlv
dSBtYXkgZGlzdHJpYnV0ZSB1bmRlciB0aGUgdGVybXMgb2YgZWl0aGVyIHRo
ZSBHTlUgR2VuZXJhbCBQdWJsaWMNCiAjIExpY2Vuc2Ugb3IgdGhlIEFydGlz
dGljIExpY2Vuc2UsIGFzIHNwZWNpZmllZCBpbiB0aGUgUGVybCBSRUFETUUg
ZmlsZS4NCiANCiA9aGVhZDEgTkFNRQ0KQEAgLTE2LDExICsxNiwxMSBAQA0K
ID1oZWFkMSBWRVJTSU9OIGFuZCBWT0xBVElMSVRZDQogDQogICAkUmV2aXNp
b246IDExLjIgJA0KICAgJERhdGU6IDIwMDEvMDgvMjQgMjI6MTA6NDQgJA0K
IA0KLVRoaXMgZG9jdW1lbnQgaXMgYSBtaW5pbWFsIGRyYWZ0IHdoaWNoIGlz
IGluIG5lZWQgb2YgZnVydGhlciB3b3JrLg0KK1RoaXMgZG9jdW1lbnQgaXMg
STxzdGlsbD4gYSBtaW5pbWFsIGRyYWZ0IHdoaWNoIGlzIGluIG5lZWQgb2Yg
ZnVydGhlciB3b3JrLg0KIA0KIFRoZSBjaGFuZ2VzIHdpbGwgb2NjdXIgYm90
aCBiZWNhdXNlIHRoZSBEQkkgc3BlY2lmaWNhdGlvbiBpcyBjaGFuZ2luZw0K
IGFuZCBoZW5jZSB0aGUgcmVxdWlyZW1lbnRzIG9uIERCRCBkcml2ZXJzIGNo
YW5nZSwgYW5kIGJlY2F1c2UgZmVlZGJhY2sNCiBmcm9tIHBlb3BsZSByZWFk
aW5nIHRoaXMgZG9jdW1lbnQgd2lsbCBzdWdnZXN0IGltcHJvdmVtZW50cyB0
byBpdC4NCiANCkBAIC00MywzMiArNDMsMzMgQEANCiBJZiBpbiBJPGFueT4g
ZG91YnQgYXQgYWxsLCBwbGVhc2UgZG8gY29udGFjdCB0aGUgZGJpLWRldiBt
YWlsaW5nIGxpc3QNCiAoZGV0YWlscyBnaXZlbiBiZWxvdykgd2hlcmUgVGlt
IEJ1bmNlIGFuZCBvdGhlciBkcml2ZXIgYXV0aG9ycyBjYW4gaGVscC4NCiAN
CiBUaGUgcHJpbWFyeSB3ZWItc2l0ZSBmb3IgbG9jYXRpbmcgREJJIHNvZnR3
YXJlIGFuZCBpbmZvcm1hdGlvbiBpcw0KIA0KLSAgaHR0cDovL3d3dy5zeW1i
b2xzdG9uZS5vcmcvdGVjaG5vbG9neS9wZXJsL0RCSQ0KKyAgaHR0cDovL2Ri
aS5wZXJsLm9yZy8NCiANCiBUaGVyZSBhcmUgMiBtYWluIGFuZCBvbmUgYXV4
aWxsaWFyeSBtYWlsaW5nIGxpc3RzIGZvciBwZW9wbGUgd29ya2luZw0KLXdp
dGggREJJLiAgVGhlIHByaW1hcnkgbGlzdHMgYXJlIGRiaS11c2Vyc0Bpc2Mu
b3JnIGZvciBnZW5lcmFsIHVzZXJzDQotb2YgREJJIGFuZCBEQkQgZHJpdmVy
cywgYW5kIGRiaS1kZXZAaXNjLm9yZyBtYWlubHkgZm9yIERCRCBkcml2ZXIN
Cit3aXRoIERCSS4gIFRoZSBwcmltYXJ5IGxpc3RzIGFyZSBkYmktdXNlcnNA
cGVybC5vcmcgZm9yIGdlbmVyYWwgdXNlcnMNCitvZiBEQkkgYW5kIERCRCBk
cml2ZXJzLCBhbmQgZGJpLWRldkBwZXJsLm9yZyBtYWlubHkgZm9yIERCRCBk
cml2ZXINCiB3cml0ZXJzIChkb24ndCBqb2luIHRoZSBkYmktZGV2IGxpc3Qg
dW5sZXNzIHlvdSBoYXZlIGEgZ29vZCByZWFzb24pLg0KLVRoZSBhdXhpbGxp
YXJ5IGxpc3QgaXMgZGJpLWFubm91bmNlQGlzYy5vcmcgZm9yIGFubm91bmNp
bmcgbmV3DQorVGhlIGF1eGlsbGlhcnkgbGlzdCBpcyBkYmktYW5ub3VuY2VA
cGVybC5vcmcgZm9yIGFubm91bmNpbmcgbmV3DQogcmVsZWFzZXMgb2YgREJJ
IG9yIERCRCBkcml2ZXJzLg0KIA0KIFlvdSBjYW4gam9pbiB0aGVzZSBsaXN0
cyBieSBhY2Nlc3NpbmcgdGhlIHdlYi1zaXRlDQotTDxodHRwOi8vd3d3Lmlz
Yy5vcmcvZGJpLWxpc3RzLmh0bWw+Lg0KK0w8aHR0cDovL2RiaS5wZXJsLm9y
Zy8+Lg0KIFRoZSBsaXN0cyBhcmUgY2xvc2VkIHNvIHlvdSBjYW5ub3Qgc2Vu
ZCBlbWFpbCB0byBhbnkgb2YgdGhlIGxpc3RzDQogdW5sZXNzIHlvdSBqb2lu
IHRoZSBsaXN0IGZpcnN0Lg0KIA0KIFlvdSBzaG91bGQgYWxzbyBjb25zaWRl
ciBtb25pdG9yaW5nIHRoZSBjb21wLmxhbmcucGVybC4qIG5ld3Nncm91cHMu
DQogDQogPWhlYWQxIEJPT0sNCiANCi1UaGUgZGVmaW5pdGl2ZSBib29rIG9u
IFBlcmwgREJJIGlzICdQcm9ncmFtbWluZyB0aGUgUGVybCBEQkk6IERhdGFi
YXNlDQotcHJvZ3JhbW1pbmcgd2l0aCBQZXJsJyBieSBBbGxpZ2F0b3IgRGVz
Y2FydGVzIGFuZCBUaW0gQnVuY2UsIHB1Ymxpc2hlZA0KLWJ5IE8nUmVpbGx5
IEFzc29jaWF0ZXMsIEZlYnJ1YXJ5IDIwMDAsIElTQk4gMS01NjU5Mi02OTkt
NC4gIEJ1eSBpdCBub3cNCi1pZiB5b3UgaGF2ZSBub3QgYWxyZWFkeSBkb25l
IHNvLg0KK1RoZSBkZWZpbml0aXZlIGJvb2sgb24gaG93IHRvIHVzZSB0aGUg
UGVybCBEQkkgaXMgJ1Byb2dyYW1taW5nIHRoZSBQZXJsDQorREJJOiBEYXRh
YmFzZSBQcm9ncmFtbWluZyB3aXRoIFBlcmwnIGJ5IEFsbGlnYXRvciBEZXNj
YXJ0ZXMgYW5kIFRpbQ0KK0J1bmNlLCBwdWJsaXNoZWQgYnkgTydSZWlsbHkg
QXNzb2NpYXRlcywgRmVicnVhcnkgMjAwMCwgSVNCTg0KKzEtNTY1OTItNjk5
LTQuDQorQnV5IGl0IG5vdyBpZiB5b3UgaGF2ZSBub3QgYWxyZWFkeSBkb25l
IHNvLg0KIA0KID1oZWFkMSBSRUdJU1RFUklORyBBIE5FVyBEUklWRVINCiAN
CiBCZWZvcmUgd3JpdGluZyBhIG5ldyBkcml2ZXIsIGl0IGlzIGluIHlvdXIg
aW50ZXJlc3RzIHRvIGZpbmQgb3V0DQogd2hldGhlciB0aGVyZSBhbHJlYWR5
IGlzIGEgZHJpdmVyIGZvciB5b3VyIGRhdGFiYXNlLiAgSWYgdGhlcmUgaXMg
c3VjaA0KQEAgLTEyNywxMSArMTI4LDExIEBADQogT2Ygc3BlY2lhbCBpbXBv
cnRhbmNlIGZvciBEQkkgZHJpdmVycyBpcyB0aGUgSTxwb3N0YW1ibGU+IG1l
dGhvZCBmcm9tDQogdGhlIEM8RXh0VXRpbHM6Ok1NX1VuaXg+IG1hbiBwYWdl
LiBBbmQgZm9yIEVtYWNzIHVzZXJzIEkgcmVjb21tZW5kDQogdGhlIEk8bGli
c2Nhbj4gbWV0aG9kLg0KIA0KIE5vdyBhbiBleGFtcGxlLCBJIHVzZSB0aGUg
d29yZCBDPERyaXZlcj4gd2hlcmV2ZXIgeW91IHNob3VsZCBpbnNlcnQNCi15
b3VyIGRyaXZlcnMgbmFtZToNCit5b3VyIGRyaXZlcidzIG5hbWU6DQogDQog
ICAjIC0qLSBwZXJsIC0qLQ0KIA0KICAgdXNlIERCSSAxLjAzOw0KICAgdXNl
IERCSTo6REJEOw0KQEAgLTE2MCwxOSArMTYxLDE5IEBADQogDQogVGhlIFJF
QURNRSBmaWxlIHNob3VsZCBkZXNjcmliZSB3aGF0IHRoZSBkcml2ZXIgaXMg
Zm9yLCB0aGUNCiBwcmUtcmVxdWlzaXRlcyBmb3IgdGhlIGJ1aWxkIHByb2Nl
c3MsIHRoZSBhY3R1YWwgYnVpbGQgcHJvY2VzcywgYW5kIGhvdw0KIHRvIHJl
cG9ydCBlcnJvcnMuIFVzZXJzIHdpbGwgZmluZCB3YXlzIG9mIGJyZWFraW5n
IHRoZSBkcml2ZXIgYnVpbGQgYW5kDQogdGVzdCBwcm9jZXNzIHdoaWNoIHlv
dSB3b3VsZCBuZXZlciBldmVuIGRyZWFtZWQgdG8gYmUgcG9zc2libGUgaW4g
eW91cg0KLW5pZ2h0bWFyZXMuIDotKSBUaGVyZWZvcmUsIHlvdSBuZWVkIHRv
IHdyaXRlIHRoaXMgZG9jdW1lbnQgZGVmZW5zaXZlbHkNCituaWdodG1hcmVz
LiAgVGhlcmVmb3JlLCB5b3UgbmVlZCB0byB3cml0ZSB0aGlzIGRvY3VtZW50
IGRlZmVuc2l2ZWx5DQogYW5kIHByZWNpc2VseS4gIEFsc28sIGl0IGlzIGlu
IHlvdXIgaW50ZXJlc3RzIHRvIGVuc3VyZSB0aGF0IHlvdXIgdGVzdHMNCiB3
b3JrIGFzIHdpZGVseSBhcyBwb3NzaWJsZS4gQXMgYWx3YXlzLCB1c2UgdGhl
IFJFQURNRSBmcm9tIG9uZSBvZiB0aGUNCiBlc3RhYmxpc2hlZCBkcml2ZXJz
IGFzIGEgYmFzaXMgZm9yIHlvdXIgb3duLg0KIA0KIA0KID1oZWFkMiBNQU5J
RkVTVA0KIA0KLVRoZSBNQU5JRkVTVCB3aWxsIGJlIHVzZWQgYnkgdGhlIE1h
a2VmaWxlJ2QgZGlzdCB0YXJnZXQgdG8gYnVpbGQgdGhlDQorVGhlIE1BTklG
RVNUIHdpbGwgYmUgdXNlZCBieSB0aGUgTWFrZWZpbGUncyBkaXN0IHRhcmdl
dCB0byBidWlsZCB0aGUNCiBkaXN0cmlidXRpb24gdGFyIGZpbGUgdGhhdCBp
cyB1cGxvYWRlZCB0byBDUEFOLiBJdCBzaG91bGQgbGlzdCBldmVyeQ0KIGZp
bGUgdGhhdCB5b3Ugd2FudCB0byBpbmNsdWRlIGluIHlvdXIgZGlzdHJpYnV0
aW9uLCBvbmUgcGVyIGxpbmUuDQogDQogDQogPWhlYWQyIGxpYi9CdW5kbGUv
REJEL0RyaXZlci5wbQ0KQEAgLTUxMCwxMCArNTExLDE1IEBADQogICAgICAg
ICAgIHdhcm4oIlJvbGxiYWNrIGluZWZmZWN0aXZlIHdoaWxlIEF1dG9Db21t
aXQgaXMgb24iKTsNCiAgICAgICB9DQogICAgICAgMDsNCiAgIH0NCiANCis9
b3ZlciA0DQorDQorKkZJWCBNRSogZGlzY3VzcyB0aGUgbmV3IGJlZ2luX3dv
cmsgbWV0aG9kIQ0KKw0KKz1iYWNrDQogDQogPWl0ZW0gVGhlIFNUT1JFIGFu
ZCBGRVRDSCBtZXRob2RzDQogDQogVGhlc2UgbWV0aG9kcyAodGhhdCB3ZSBo
YXZlIGFscmVhZHkgdXNlZCwgc2VlIGFib3ZlKSBhcmUgY2FsbGVkIGZvcg0K
IHlvdSwgd2hlbmV2ZXIgdGhlIHVzZXIgZG9lcyBhDQpAQCAtNzY2LDExICs3
NzIsMTEgQEANCiANCiANCiA9aGVhZDIgRHJpdmVyLnBtDQogDQogVGhlIERy
aXZlci5wbSBmaWxlIGlzIHRoZSBzYW1lIGFzIGZvciBQdXJlIFBlcmwgbW9k
dWxlcywgc2VlIGFib3ZlLg0KLUhvd2V2ZXIsIHRoZXJlIGFyZSBzb21lIHN1
YnRpbGUgZGlmZmVyZW5jZXM6DQorSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUg
c3VidGxlIGRpZmZlcmVuY2VzOg0KIA0KID1vdmVyIDgNCiANCiA9aXRlbSAq
DQogDQpAQCAtODMwLDEwICs4MzYsMTggQEANCiBpdCkgYW5kIGNhbGxzIEk8
ZGJkX2RiX2xvZ2luPiBmcm9tIEk8ZGJkaW1wLmM+LiBTZWUgYmVsb3cgZm9y
IGRldGFpbHMuDQogDQogU2luY2UgdGhlIERCSTo6X25ld194eGggbWV0aG9k
cyBjYW4ndCBmYWlsIGluIG5vcm1hbCBzaXR1YXRpb25zLCB3ZQ0KIGRvbid0
IGJvdGggY2hlY2tpbmcgJGRiaCBiZWZvcmUgY2FsbGluZyBfbG9naW4uDQog
DQorPW92ZXIgNA0KKw0KKypGSVggTUUqIERpc2N1c3MgbG9naW42IGFzIGEg
d2F5IHRvIGdldCBhdCBhdHRyaWJ1dGVzIGR1cmluZyBsb2dpbi4NCisNCisq
RklYIE1FKiBEaXNjdXNzIHJlbW92aW5nIGF0dHJpYnV0ZXMgZnJvbSBoYXNo
IHJlZmVyZW5jZSBhcyBhbiBvcHRpbWl6YXRpb24uDQorDQorPWJhY2sNCisN
CiA9aXRlbSBUaGUgc3RhdGVtZW50IGhhbmRsZSBjb25zdHJ1Y3Rvcg0KIA0K
IFRoZXJlJ3Mgbm90aGluZyBtdWNoIG5ldyBpbiB0aGUgc3RhdGVtZW50IGhh
bmRsZSBjb25zdHJ1Y3Rvci4gTGlrZQ0KIHRoZSBJPGNvbm5lY3Q+IG1ldGhv
ZCBpdCBub3cgaGFzIGEgQyBjYWxsYmFjazoNCiANCkBAIC05NTksMjcgKzk3
MywzMyBAQA0KICAgI2RlZmluZSBkYmRfaW5pdCAgICAgICAgICBvcmFfaW5p
dA0KICAgI2RlZmluZSBkYmRfZGJfbG9naW4gICAgICBvcmFfZGJfbG9naW4N
CiAgICNkZWZpbmUgZGJkX2RiX2RvICAgICAgICBvcmFfZGJfZG8NCiAgIC4u
LiBtYW55IG1vcmUgaGVyZSAuLi4NCiANCi1UaGlzIHN0cnVjdHVyZXMgaW1w
bGVtZW50IHlvdXIgcHJpdmF0ZSBwYXJ0IG9mIHRoZSBoYW5kbGVzLiBZb3Ug
STxoYXZlPg0KKz1vdmVyIDQNCisNCisqRklYIE1FKiBTaG91bGQgbWVudGlv
biBkYmRfZGJfbG9naW42Lg0KKw0KKypGSVggTUUqIFNob3VsZCB1c2UgaHlw
b3RoZXRpY2FsIGRydl8gcHJlZml4IGluc3RlYWQgb2Ygb3JhXyBwcmVmaXgu
DQorDQorPWJhY2sNCisNCitUaGVzZSBzdHJ1Y3R1cmVzIGltcGxlbWVudCB5
b3VyIHByaXZhdGUgcGFydCBvZiB0aGUgaGFuZGxlcy4gWW91IEk8aGF2ZT4N
CiB0byB1c2UgdGhlIG5hbWUgSTxpbXBfZGJoX2RyfGRifHN0PiBhbmQgdGhl
IGZpcnN0IGZpZWxkIEk8bXVzdD4gYmUgb2YNCi10eXBlIEk8ZGJpaF9kcmN8
ZGJjfHN0Y190Pi4gWW91IHNob3VsZCBuZXZlciBhY2Nlc3MgdGhpcyBmaWVs
ZHMgZGlyZWN0bHksDQordHlwZSBJPGRiaWhfZHJjfGRiY3xzdGNfdD4uIFlv
dSBzaG91bGQgbmV2ZXIgYWNjZXNzIHRoZXNlIGZpZWxkcyBkaXJlY3RseSwN
CiBleGNlcHQgb2YgdXNpbmcgdGhlIEk8REJJY194eHg+IG1hY3JvcyBiZWxv
dy4NCiANCiANCiA9aGVhZDIgSW1wbGVtZW50YXRpb24gc291cmNlIGRiZGlt
cC5jDQogDQogVGhpcyBpcyB0aGUgbWFpbiBpbXBsZW1lbnRhdGlvbiBmaWxl
LiBJIHdpbGwgZHJvcCBhIHNob3J0IG5vdGUgb24gYW55DQogZnVuY3Rpb24g
aGVyZSB0aGF0J3MgdXNlZCBpbiB0aGUgSTxEcml2ZXIueHNpPiB0ZW1wbGF0
ZSBhbmQgdGh1cyBCPGhhcz4NCiB0byBiZSBpbXBsZW1lbnRlZC4gT2YgY291
cnNlIHlvdSBjYW4gYWRkIHByaXZhdGUgb3IgYmV0dGVyIHN0YXRpYw0KIGZ1
bmN0aW9ucyBoZXJlLg0KIA0KLU5vdGUgdGhhdCBtb3N0IHBlb3BsZSBhcmUg
c3RpbGwgdXNpbmcgS2VybmlnaGFuICYgUml0Y2hpZSBzeW50YXggaGVyZS4N
Ci1JIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSB0aGlzIGFuZCBlc3BlY2lhbGx5
IGluIHRoaXMgZG9jdW1lbnRhdGlvbiBpdA0KLWNhbm5vdCBiZSBvZiBoYXJt
LCBzbyBsZXQncyB1c2UgQU5TSS4gRmluYWxseSBUaW0gQnVuY2UgaGFzIGFu
bm91bmNlZA0KLWludGVyZXN0IGluIG1vdmluZyB0aGUgREJJIHNvdXJjZXMg
dG8gQU5TSSBhcyB3ZWxsLg0KK1NpbmNlIFBlcmwgNS42IHJlcXVpcmVzIHN1
cHBvcnQgZm9yIGZ1bmN0aW9uIHByb3RvdHlwZXMgKEFOU0kgb3IgSVNPIG9y
DQorU3RhbmRhcmQgQyksIHlvdSBzaG91bGQgd3JpdGUgeW91ciBjb2RlIHVz
aW5nIGZ1bmN0aW9uIHByb3RvdHlwZXMgdG9vLg0KIA0KID1vdmVyIDINCiAN
CiA9aXRlbSBJbml0aWFsaXphdGlvbg0KIA0KQEAgLTk5NCwxNSArMTAxNCwy
OSBAQA0KIA0KIGRiZF9pbml0IHdpbGwgYmUgY2FsbGVkIHdoZW4geW91ciBk
cml2ZXIgaXMgZmlyc3QgbG9hZGVkLiBUaGVzZQ0KIHN0YXRlbWVudHMgYXJl
IG5lZWRlZCBmb3IgdXNlIG9mIHRoZSBEQkkgbWFjcm9zLiBUaGV5IHdpbGwg
aW5jbHVkZSB5b3VyDQogcHJpdmF0ZSBoZWFkZXIgZmlsZSBJPGRiZGltcC5o
PiBpbiB0dXJuLg0KIA0KKz1vdmVyIDQNCisNCisqRklYIE1FKiBJcyByZWNv
bW1lbmRlZCBwcmFjdGljZSB0byB1c2UgdGhlIHVubWFwcGVkIERCSS1zcGVj
aWZpZWQgbmFtZXMNCitvciB0byB1c2UgeW91ciBkcml2ZXItc3BlY2lmaWMg
ZnVuY3Rpb24gbmFtZXMgaW4gdGhlIHNvdXJjZSBjb2RlPyAgREJEOjpJbmZv
cm1peA0KK3VzZXMgdGhlIGRyaXZlci1zcGVjaWZpYyBuYW1lcyBpbiB0aGUg
c291cmNlOyB0aGUgaGVhZGVyIGRlYWxzIHdpdGggdGhlIG1hcHBpbmcuDQor
DQorPWJhY2sNCisNCiA9aXRlbSBkb19lcnJvcg0KIA0KIFlvdSBuZWVkIGEg
ZnVuY3Rpb24gdG8gaGFuZGxlIHJlY29yZGluZyBvZiBlcnJvcnMuIFlvdSBj
YW4gY2FsbCBpdA0KIHdoYXRldmVyIHlvdSBsaWtlLCBidXQgd2UnbGwgY2Fs
bCBpdCBDPGRvX2Vycm9yPiBoZXJlLg0KIA0KKz1vdmVyIDQNCisNCisqRklY
IE1FKiBTaG91bGQgdGhpcyBiZSBhIGZpbGUgc3RhdGljIGZ1bmN0aW9uPyAg
V2h5IG5vdD8NCisNCis9YmFjaw0KKw0KICAgdm9pZCBkb19lcnJvcihTViog
aCwgaW50IHJjLCBjaGFyKiB3aGF0KSB7DQogDQogTm90ZSB0aGF0IEk8aD4g
aXMgYSBnZW5lcmljIGhhbmRsZSwgbWF5IGl0IGJlIGEgZHJpdmVyIGhhbmRs
ZSwgYQ0KIGRhdGFiYXNlIG9yIGEgc3RhdGVtZW50IGhhbmRsZS4NCiANCkBA
IC0xMDkwLDEwICsxMTI0LDE4IEBADQogaGFuZGxlIGlzIGRlc3Ryb3llZC4N
CiANCiBUaGUgZGJkX2RiX2xvZ2luIGZ1bmN0aW9uIHNob3VsZCByZXR1cm4g
VFJVRSBmb3Igc3VjY2VzcywgRkFMU0Ugb3RoZXJ3aXNlLg0KIA0KIA0KKz1p
dGVtIGRiZF9kYl9sb2dpbjYNCisNCis9b3ZlciA0DQorDQorKkZJWCBNRSog
RGV0YWlscyBUQlMNCisNCis9YmFjaw0KKw0KID1pdGVtIGRiZF9kYl9jb21t
aXQNCiANCiA9aXRlbSBkYmRfZGJfcm9sbGJhY2sNCiANCiAgIGludCBkYmRf
ZGJfY29tbWl0KCAgIFNWKiBkYmgsIGltcF9kYmhfdCogaW1wX2RiaCApOw0K
QEAgLTExMDQsMTAgKzExNDYsMTkgQEANCiANCiBUaGUgYXJndW1lbnRzIEk8
ZGJoPiBhbmQgSTxpbXBfZGJoPiBhcmUgbGlrZSBhYm92ZSwgSSB3aWxsIG9t
aXQNCiBkZXNjcmliaW5nIHRoZW0gaW4gd2hhdCBmb2xsb3dzLCBhcyB0aGV5
IGFwcGVhciBhbHdheXMuDQogDQogDQorPWl0ZW0gZGJkX2RiX2JlZ2luX3dv
cmsNCisNCis9b3ZlciA0DQorDQorKkZJWCBNRSogRGV0YWlscyBUQlMNCisN
Cis9YmFjaw0KKw0KKw0KID1pdGVtIGRiZF9kYl9kaXNjb25uZWN0DQogDQog
VGhpcyBpcyB5b3VyIHByaXZhdGUgcGFydCBvZiB0aGUgSTxkaXNjb25uZWN0
PiBtZXRob2QuIEFueSBkYmggd2l0aA0KIHRoZSBJPEFDVElWRT4gZmxhZyBv
biBtdXN0IGJlIGRpc2Nvbm5lY3RlZC4gKE5vdGUgdGhhdCB5b3UgaGF2ZSB0
byBzZXQNCiBpdCBpbiBJPGRiZF9kYl9jb25uZWN0PiBhYm92ZS4pDQpAQCAt
MTE1MCwyMyArMTIwMSwzMSBAQA0KIGlmIHRoZSBoYW5kbGUgaXMgc3RpbGwg
J2FjdGl2ZScsIGJlZm9yZSBjYWxsaW5nIGRiZF9kYl9kZXN0cm95Lg0KIA0K
IEJlZm9yZSByZXR1cm5pbmcgdGhlIGZ1bmN0aW9uIG11c3Qgc3dpdGNoIElN
UFNFVCB0byBvZmYsIHNvIERCSSBrbm93cw0KIHRoYXQgdGhlIGRlc3RydWN0
b3Igd2FzIGNhbGxlZC4NCiANCis9b3ZlciA0DQorDQorKkZJWCBNRSogSWYg
dGhlcmUgYXJlIHN0YXRlbWVudHMgJ2FjdGl2ZScgd2hlbiB0aGUgJGRiaCBp
cyBkZXN0cm95ZWQsDQorZG9lcyBEQkkgYXJyYW5nZSB0byBkZXN0cm95IHRo
b3NlIHN0YXRlbWVudCBoYW5kbGVzLCBvciBkb2VzIHRoZSBkcml2ZXIgbmVl
ZCB0bw0KK2RvIHRoZSB3b3JrIGl0c2VsZj8NCisNCis9YmFjaw0KKw0KIA0K
ID1pdGVtIGRiZF9kYl9TVE9SRV9hdHRyaWINCiANCiBUaGlzIGZ1bmN0aW9u
IGhhbmRsZXMNCiANCiAgICRkYmgtPnska2V5fSA9ICR2YWx1ZTsNCiANCi1p
dHMgcHJvdG90eXBlIGlzDQorSXRzIHByb3RvdHlwZSBpczoNCiANCiAgIGlu
dCBkYmRfZGJfU1RPUkVfYXR0cmliKFNWKiBkYmgsIGltcF9kYmhfdCogaW1w
X2RiaCwgU1YqIGtleXN2LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
U1YqIHZhbHVlc3YpOw0KIA0KLVlvdSBkbyBub3QgaGFuZGxlIGFsbCBhdHRy
aWJ1dGVzLCBpbiBjb250cmFyeSB5b3Ugc2hvdWxkIG5vdCBoYW5kbGUNCitZ
b3UgZG8gbm90IGhhbmRsZSBhbGwgYXR0cmlidXRlczsgb24gdGhlIGNvbnRy
YXJ5LCB5b3Ugc2hvdWxkIG5vdCBoYW5kbGUNCiBEQkkgYXR0cmlidXRlcyBo
ZXJlOiBMZWF2ZSB0aGlzIHRvIERCSS4gKFRoZXJlJ3Mgb25lIGV4Y2VwdGlv
biwNCiBJPEF1dG9Db21taXQ+LCB3aGljaCB5b3Ugc2hvdWxkIGNhcmUgYWJv
dXQuKQ0KIA0KIFRoZSByZXR1cm4gdmFsdWUgaXMgVFJVRSwgaWYgeW91IGhh
dmUgaGFuZGxlZCB0aGUgYXR0cmlidXRlIG9yIEZBTFNFDQogb3RoZXJ3aXNl
LiBJZiB5b3UgYXJlIGhhbmRsaW5nIGFuIGF0dHJpYnV0ZSBhbmQgc29tZXRo
aW5nIGZhaWxzLCB5b3UNCkBAIC0xMjI0LDEwICsxMjgzLDE3IEBADQogQSB0
eXBpY2FsLCBzaW1wbGUgcG9zc2liaWxpdHkgaXMganVzdCB0byBzdG9yZSB0
aGUgc3RhdGVtZW50IGluIHRoZQ0KIGltcF9kYXRhIGhhc2ggcmVmIGFuZCB1
c2UgaXQgaW4gZGJkX3N0X2V4ZWN1dGUuIElmIHlvdSBjYW4sIHlvdSBzaG91
bGQNCiBzZXR1cCBhdHRyaWJ1dGVzIGxpa2UgTlVNX09GX0ZJRUxEUywgTkFN
RSwgLi4uIGhlcmUsIGJ1dCBEQkkNCiBkb2Vzbid0IHJlcXVpcmUgdGhhdC4g
SG93ZXZlciwgaWYgeW91IGRvLCBkb2N1bWVudCBpdC4NCiANCis9b3ZlciA0
DQorDQorKkZJWCBNRSogV2hhdCBhYm91dCBOVU1fT0ZfUEFSQU1TPyAgVGhh
dCBoYXMgdG8gYmUgc2V0IGJ5ICRkYmgtPnByZXBhcmUoKQ0KK3NvIHRoYXQg
eW91IGNhbiBjYWxsIGV4ZWN1dGUgd2l0aCB0aGUgY29ycmVjdCBudW1iZXIg
b2YgdmFsdWVzLg0KKw0KKz1iYWNrDQorDQogSW4gYW55IGNhc2UgeW91IHNo
b3VsZCBzZXQgdGhlIElNUFNFVCBmbGFnLCBhcyB5b3UgZGlkIGluDQogSTxk
YmRfZGJfY29ubmVjdD4gYWJvdmU6DQogDQogICBEQkljX0lNUFNFVF9vbihp
bXBfc3RoKTsNCiANCkBAIC0xMjYzLDMyICsxMzI5LDM2IEBADQogICAgICAg
LyogcXVvdGVzIGFuZCB0aGUgbGlrZSAuLi4gIDotKCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICovDQogICAgICAgLyogU2VlIERCRDo6bXlzcWwg
Zm9yIGFuIGV4YW1wbGUuIChEb24ndCBsb29rIHRvbyBkZWVwIGludG8gICov
DQogICAgICAgLyogdGhlIGV4YW1wbGUsIHlvdSB3aWxsIG5vdGljZSB3aGVy
ZSBJIHdhcyBsYXp5IC4uLikgICAgICAgICovDQogICB9DQogDQotVGhlIG5l
eHQgdGhpbmcgaXMgeW91IHJlYWxseSBleGVjdXRlIHRoZSBzdGF0ZW1lbnQu
IE5vdGUgdGhhdCB5b3UgbXVzdA0KLXByZXBhcmUgdGhlIGF0dHJpYnV0ZXMg
TlVNX09GX0ZJRUxEUywgTkFNRSwgLi4uIHdoZW4gdGhlIHN0YXRlbWVudCBp
cw0KLXN1Y2Nlc3NmdWxseSBleGVjdXRlZCBpZiB5b3UgaGF2ZSBub3QgYWxy
ZWFkeSBkb25lIHNvOiBUaGV5IG1heSBiZSB1c2VkIGV2ZW4gYmVmb3JlIGEg
cG90ZW50aWFsDQotSTxmZXRjaHJvdz4uIEluIHBhcnRpY3VsYXIgeW91IGhh
dmUgdG8gdGVsbCBEQkkgdGhlIG51bWJlciBvZiBmaWVsZHMsDQotdGhhdCB0
aGUgc3RhdGVtZW50IGhhcywgYmVjYXVzZSBpdCB3aWxsIGJlIHVzZWQgYnkg
REJJIGludGVybmFsbHkuDQorVGhlIG5leHQgdGhpbmcgaXMgeW91IHJlYWxs
eSBleGVjdXRlIHRoZSBzdGF0ZW1lbnQuDQorTm90ZSB0aGF0IHlvdSBtdXN0
IHByZXBhcmUgdGhlIGF0dHJpYnV0ZXMgTlVNX09GX1BBUkFNUywgTlVNX09G
X0ZJRUxEUywNCitOQU1FLCBldGMgd2hlbiB0aGUgc3RhdGVtZW50IGlzIHN1
Y2Nlc3NmdWxseSBleGVjdXRlZCBpZiB0aGUgZHJpdmVyIGhhcw0KK25vdCBh
bHJlYWR5IGRvbmUgc28uDQorVGhleSBtYXkgYmUgdXNlZCBldmVuIGJlZm9y
ZSBhIHBvdGVudGlhbCBJPGZldGNocm93Pi4NCitJbiBwYXJ0aWN1bGFyIHlv
dSBoYXZlIHRvIHRlbGwgREJJIHRoZSBudW1iZXIgb2YgZmllbGRzLCB0aGF0
IHRoZQ0KK3N0YXRlbWVudCBoYXMsIGJlY2F1c2UgaXQgd2lsbCBiZSB1c2Vk
IGJ5IERCSSBpbnRlcm5hbGx5Lg0KIFRodXMgdGhlIGZ1bmN0aW9uIHdpbGwg
dHlwaWNhbGx5IGVuZHMgd2l0aDoNCiANCiAgIGlmIChpc1NlbGVjdFN0YXRl
bWVudCkgew0KICAgICAgIERCSWNfTlVNX0ZJRUxEUyhpbXBfc3RoKSA9IG51
bUZpZWxkczsNCiAgICAgICBEQkljX0FDVElWRV9vbihpbXBfc3RoKTsNCiAg
IH0NCiANCi1JdCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgQUNUSVZFIGZsYWcg
b25seSBiZSBzZXQgZm9yIHNlbGVjdCBzdGF0ZW1lbnRzLg0KK0l0IGlzIGlt
cG9ydGFudCB0aGF0IHRoZSBBQ1RJVkUgZmxhZyBvbmx5IGJlIHNldCBmb3Ig
c2VsZWN0IHN0YXRlbWVudHMNCisob3IgYW55IG90aGVyIHN0YXRlbWVudHMg
dGhhdCBjYW4gcmV0dXJuIG11bHRpcGxlIHNldHMgb2YgdmFsdWVzIGZyb20N
Cit0aGUgZGF0YWJhc2UgdXNpbmcgYSBjdXJzb3ItbGlrZSBtZWNoYW5pc20p
Lg0KIFNlZSBJPGRiZF9zdF9wcmVwYXJzZT4gYW5kIEk8ZGJkX2RiX2Nvbm5l
Y3Q+IGFib3ZlIGZvciBtb3JlIGV4cGxhbmF0aW9ucy4NCiANCiANCiA9aXRl
bSBkYmRfc3RfZmV0Y2gNCiANCiBUaGlzIGZ1bmN0aW9uIGZldGNoZXMgYSBy
b3cgb2YgZGF0YS4gVGhlIHJvdyBpcyBzdG9yZWQgaW4gaW4gYW4gYXJyYXks
DQotb2YgU1YncyB0aGF0IERCSSBwcmVwYXJlcyBmb3IgeW91LiBUaGlzIGhh
cyB0d28gYWR2YW50YWdlczogSXQgaXMgZmFzdA0KK29mIFNWJ3MgdGhhdCBE
QkkgcHJlcGFyZXMgZm9yIHlvdS4gVGhpcyBoYXMgdHdvIGFkdmFudGFnZXM6
IGl0IGlzIGZhc3QNCiAoeW91IGV2ZW4gcmV1c2UgdGhlIFNWJ3MsIHNvIHRo
ZXkgZG9uJ3QgaGF2ZSB0byBiZSBjcmVhdGVkIGFmdGVyIHRoZQ0KLWZpcnN0
IGZldGNocm93KSBhbmQgaXQgZ3VhcmFudGVlcywgdGhhdCBEQkkgaGFuZGxl
cyBJPGJpbmRfY29scz4gZm9yDQorZmlyc3QgZmV0Y2hyb3cpLCBhbmQgaXQg
Z3VhcmFudGVlcyB0aGF0IERCSSBoYW5kbGVzIEk8YmluZF9jb2xzPiBmb3IN
CiB5b3UuDQogDQogV2hhdCB5b3UgZG8gaXMgdGhlIGZvbGxvd2luZzoNCiAN
CiAgIEFWKiBhdjsNCkBAIC0xMzI3LDEwICsxMzk3LDE3IEBADQogICBTdk9L
X29mZihBdkFSUkFZKGF2KVtpXSk7DQogDQogVGhlIGZ1bmN0aW9uIHJldHVy
bnMgdGhlIEFWIHByZXBhcmVkIGJ5IERCSSBmb3Igc3VjY2VzcyBvciBDPE51
bGxhdj4NCiBvdGhlcndpc2UuDQogDQorPW92ZXIgNA0KKw0KKypGSVggTUUq
IERpc2N1c3Mgd2hhdCBoYXBwZW5zIHdoZW4gdGhlcmUncyBubyBtb3JlIGRh
dGEgdG8gZmV0Y2guDQorQXJlIGVycm9ycyBwZXJtaXR0ZWQgaWYgYW5vdGhl
ciBmZXRjaCBvY2N1cnMgYWZ0ZXIgdGhlIGZpcnN0IGZldGNoDQordGhhdCBy
ZXBvcnRzIG5vIG1vcmUgZGF0YS4NCisNCis9YmFjaw0KIA0KID1pdGVtIGRi
ZF9zdF9maW5pc2gNCiANCiBUaGlzIGZ1bmN0aW9uIGNhbiBiZSBjYWxsZWQg
aWYgdGhlIHVzZXIgd2lzaGVzIHRvIGluZGljYXRlIHRoYXQgbm8NCiBtb3Jl
IHJvd3Mgd2lsbCBiZSBmZXRjaGVkIGV2ZW4gaWYgdGhlIHNlcnZlciBoYXMg
bW9yZSByb3dzIHRvIG9mZmVyLg0KQEAgLTEzNDcsMTAgKzE0MjQsMTkgQEAN
CiAgICAgICByZXR1cm4gMTsNCiAgIH0NCiANCiBUaGUgZnVuY3Rpb24gcmV0
dXJucyBUUlVFIGZvciBzdWNjZXNzLCBGQUxTRSBvdGhlcndpc2UuDQogDQor
PW92ZXIgNA0KKw0KKypGSVggTUUqIFdoYXQgaGFwcGVucyBpZiB0aGUgdXNl
ciBjYWxscyAkc3RoLT5maW5pc2ggYmVmb3JlICRzdGgtPmV4ZWN1dGU/DQor
V2hhdCBoYXBwZW5zIGlmIHRoZSB1c2VyIGNhbGxzICRzdGgtPmZpbmlzaCB0
d2ljZT8gIFdoYXQgaGFwcGVucyBpZiB0aGUgdXNlcg0KK2NhbGxzICRzdGgt
PmV4ZWN1dGUgb24gYSBTRUxFQ1Qgc3RhdGVtZW50IHR3aWNlIHdpdGggbm8g
aW50ZXJ2ZW5pbmcgJHN0aC0+ZmluaXNoPw0KK1doYXQgaGFwcGVucyBpZiB0
aGUgdXNlciBjYWxscyAkc3RoLT5maW5pc2ggYmVmb3JlIGZldGNoaW5nIGFu
eSBkYXRhPw0KKw0KKz1iYWNrDQorDQogDQogPWl0ZW0gZGJkX3N0X2Rlc3Ry
b3kNCiANCiBUaGlzIGZ1bmN0aW9uIGlzIHRoZSBwcml2YXRlIHBhcnQgb2Yg
dGhlIHN0YXRlbWVudCBoYW5kbGUgZGVzdHJ1Y3Rvci4NCiANCkBAIC0xNzM1
LDEzICsxODIxLDEzIEBADQogREJEOjpPcmFjbGUgZHJpdmVyLg0KIA0KIA0K
ID1oZWFkMSBBVVRIT1JTDQogDQotSm9uYXRoYW4gTGVmZmxlciA8amxlZmZs
ZXJAaW5mb3JtaXguY29tPiwNCitKb25hdGhhbiBMZWZmbGVyIDxqbGVmZmxl
ckB1cy5pYm0uY29tPiAocHJldmlvdXNseSA8amxlZmZsZXJAaW5mb3JtaXgu
Y29tPiksDQogSm9jaGVuIFdpZWRtYW5uIDxqb2VAaXNwc29mdC5kZT4sDQot
YW5kIFRpbSBCdW5jZS4NCithbmQgVGltIEJ1bmNlIDx0aW0uYnVuY2VAcG9i
b3guY29tPi4NCiANCiA9Y3V0DQogDQogDQogcGFja2FnZSBEQkk6OkRCRDsN
Cg==
---559023410-33463914-1013562156=:12790--
0
jleffler
2/13/2002 1:02:36 AM
perl.dbi.dev 1920 articles. 0 followers. Follow

10 Replies
323 Views

Similar Articles

[PageSpeed] 15

On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> -Note that most people are still using Kernighan & Ritchie syntax here.
> -I personally don't like this and especially in this documentation it
> -cannot be of harm, so let's use ANSI. Finally Tim Bunce has announced
> -interest in moving the DBI sources to ANSI as well.
> +Since Perl 5.6 requires support for function prototypes (ANSI or ISO or
> +Standard C), you should write your code using function prototypes too.

Perl requires ANSI-C (as of ***long*** before 5.6)
ANSI-C supports prototypes
We DBD authors /should/ use prototypes

I couldn't be more straight.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

0
h
2/13/2002 3:24:42 PM
On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> +=over 4
> +
> +*FIX ME* If there are statements 'active' when the $dbh is destroyed,
> +does DBI arrange to destroy those statement handles, or does the driver need to
> +do the work itself?
> +
> +=back
> +

Depends on the databse. In DBD-Unify I *have to* do it myself, but some
guidelines would be much appreciated for future DBD's

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

0
h
2/13/2002 3:26:08 PM
On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> -The next thing is you really execute the statement. Note that you must
> -prepare the attributes NUM_OF_FIELDS, NAME, ... when the statement is
> -successfully executed if you have not already done so: They may be used even before a potential
> -I<fetchrow>. In particular you have to tell DBI the number of fields,
> -that the statement has, because it will be used by DBI internally.
> +The next thing is you really execute the statement.
> +Note that you must prepare the attributes NUM_OF_PARAMS, NUM_OF_FIELDS,
> +NAME, etc when the statement is successfully executed if the driver has
> +not already done so.
> +They may be used even before a potential I<fetchrow>.
> +In particular you have to tell DBI the number of fields, that the
> +statement has, because it will be used by DBI internally.

Maybe mention that these attributes might act different on positional
parameters and returned values. For example in the DEC port of DBD-Unify,
accessing the NAME field of positional parameters dumps core, where it works
fine in the returned values. This is due to the database, not the DBD program.
I've tested that with stand-alone code which also fails. (I have no DEC
machines anymore, so I cannot test newer releases)

Unify might be the odd one out here, but as this is aguideline to new DBD
authors (and a reference to existing DBD authors that want to update their
drivers to the latest DBI), it might be worth mentioning.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

0
h
2/13/2002 3:30:25 PM
On Wed, 13 Feb 2002, H.Merijn Brand wrote:

>On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
>> -Note that most people are still using Kernighan & Ritchie syntax here.
>> -I personally don't like this and especially in this documentation it
>> -cannot be of harm, so let's use ANSI. Finally Tim Bunce has announced
>> -interest in moving the DBI sources to ANSI as well.
>> +Since Perl 5.6 requires support for function prototypes (ANSI or ISO or
>> +Standard C), you should write your code using function prototypes too.
>
>Perl requires ANSI-C (as of ***long*** before 5.6)

You're right; Perl 5.005 requires ANSI C.  I checked in the 5.005_03
source and the INSTALL file discusses the need for an ANSI C compiler.
I checked the 5.004_04 INSTALL file and it makes no mention of needing
an ANSI C compiler, and I checked the source file sv.c and it does not
use prototypes.

>ANSI-C supports prototypes
>We DBD authors /should/ use prototypes
>
>I couldn't be more straight.

So, apart from noting that DBI 1.21 no longer supports Perl 5.004, and
changing the reference from 5.6 to 5.005, do you want me to add italics
to I<should>?  Or drop the prevarication about ANSI vs ISO C?  Or is it
basically OK as it stands?

-- 
Jonathan Leffler                           #include <disclaimer.h>
STSM, Informix Database Engineering, IBM Data Management Solutions
Phone: +1 650-926-6921                          Tie-line: 630-6921
Email: jleffler@us.ibm.com (jleffler@informix.com)
Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
            *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Please update your address book to use jleffler@us.ibm.com because
jleffler@informix.com will not work starting 2002-07-01.  Expect
slower responses because I can't use Lotus Notes as fast as Unix
email.  One day, this signature will shrink!

0
jleffler
2/13/2002 5:35:16 PM
On Wed 13 Feb 2002 18:35, Jonathan Leffler <jleffler@informix.com> wrote:
> On Wed, 13 Feb 2002, H.Merijn Brand wrote:
> 
> >On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> >> -Note that most people are still using Kernighan & Ritchie syntax here.
> >> -I personally don't like this and especially in this documentation it
> >> -cannot be of harm, so let's use ANSI. Finally Tim Bunce has announced
> >> -interest in moving the DBI sources to ANSI as well.
> >> +Since Perl 5.6 requires support for function prototypes (ANSI or ISO or
> >> +Standard C), you should write your code using function prototypes too.
> >
> >Perl requires ANSI-C (as of ***long*** before 5.6)
> 
> You're right; Perl 5.005 requires ANSI C.  I checked in the 5.005_03
> source and the INSTALL file discusses the need for an ANSI C compiler.
> I checked the 5.004_04 INSTALL file and it makes no mention of needing
> an ANSI C compiler, and I checked the source file sv.c and it does not
> use prototypes.
> 
> >ANSI-C supports prototypes
> >We DBD authors /should/ use prototypes
> >
> >I couldn't be more straight.
> 
> So, apart from noting that DBI 1.21 no longer supports Perl 5.004, and
> changing the reference from 5.6 to 5.005, do you want me to add italics
> to I<should>?  Or drop the prevarication about ANSI vs ISO C?  Or is it
> basically OK as it stands?

Choose your own wording, but what I mean is:

Since Perl 5.6 requires ANSI C (supporting function prototypes), you I<should>
write your code using function prototypes too.

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

0
h
2/13/2002 5:39:35 PM
On Wed, 13 Feb 2002, H.Merijn Brand wrote:
>On Wed 13 Feb 2002 18:35, Jonathan Leffler <jleffler@informix.com> wrote:
>> On Wed, 13 Feb 2002, H.Merijn Brand wrote:
>> >On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
>> >> -Note that most people are still using Kernighan & Ritchie syntax here.
>> >> -I personally don't like this and especially in this documentation it
>> >> -cannot be of harm, so let's use ANSI. Finally Tim Bunce has announced
>> >> -interest in moving the DBI sources to ANSI as well.
>> >> +Since Perl 5.6 requires support for function prototypes (ANSI or ISO or
>> >> +Standard C), you should write your code using function prototypes too.
>> >
>> >Perl requires ANSI-C (as of ***long*** before 5.6)
>>
>> You're right; Perl 5.005 requires ANSI C.  [...]
>>
>> >ANSI-C supports prototypes
>> >We DBD authors /should/ use prototypes
>> >
>> >I couldn't be more straight.
>>
>> So, apart from noting that DBI 1.21 no longer supports Perl 5.004, and
>> changing the reference from 5.6 to 5.005, do you want me to add italics
>> to I<should>?  Or drop the prevarication about ANSI vs ISO C?  Or is it
>> basically OK as it stands?
>
>Choose your own wording, but what I mean is:
>
>Since Perl 5.6 requires ANSI C (supporting function prototypes), you
>I<should> write your code using function prototypes too.

I've edited the paragraph to read:

	DBI 1.21 no longer supports Perl 5.004.  The source code for
	Perl 5.005 and later uses function prototypes, so users must
	have an ANSI C compiler to build Perl.  Therefore, you I<should>
	should write your DBD code using function prototypes too.

-- 
Jonathan Leffler                           #include <disclaimer.h>
STSM, Informix Database Engineering, IBM Data Management Solutions
Phone: +1 650-926-6921                          Tie-line: 630-6921
Email: jleffler@us.ibm.com (jleffler@informix.com)
Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
            *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Please update your address book to use jleffler@us.ibm.com because
jleffler@informix.com will not work starting 2002-07-01.  Expect
slower responses because I can't use Lotus Notes as fast as Unix
email.  One day, this signature will shrink!

0
jleffler
2/13/2002 6:19:20 PM
On Wed, 13 Feb 2002, H.Merijn Brand wrote:
>On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
>> +=over 4
>> +
>> +*FIX ME* If there are statements 'active' when the $dbh is destroyed,
>> +does DBI arrange to destroy those statement handles, or does the driver need to
>> +do the work itself?
>> +
>> +=back
>
>Depends on the database. In DBD-Unify I *have to* do it myself, but some
>guidelines would be much appreciated for future DBD's

At the moment, the DBD::Informix driver explicitly keeps track of
all the database handles it has, and for each database handle,
keeps a track of all the associated statement handles.  When a
database handle is destroyed, I have code that tracks through all
the associated statement handles and releases them.  *BUT* I've
never spotted any activity while doing this.  So, I think that
DBI is also keeping track of statement handles and calling the
statement handle release code before calling the database handle
release code, so my driver is doing unnecessary work.  I'd like
to get rid of the code that tracks statement handles (in
particular) and database handles.  But I'd like a clear statement
from those who can understand the DBI code that this is
unnecessary.  I also readily admit that I (DBD::Informix) could
be misusing the IMPSET and ACTIVE flags - the last time I really
experimented with them at all was back in the days of DBI 0.6x or
thereabouts, and lots of things have changed since then.

I note that with Informix, there are resources associated with a
prepared statement that should be released when the statement is
destroyed.  The active flag is only to be used for SELECT
statements.  I have to assume that the IMPSET flag should be set
for prepared statements so that they are destroyed correctly.

All this needs to be written out clearly (and with luck will be
by the time I've finished), but it needs accurate input - GIGO
applies.

-- 
Jonathan Leffler                           #include <disclaimer.h>
STSM, Informix Database Engineering, IBM Data Management Solutions
Phone: +1 650-926-6921                          Tie-line: 630-6921
Email: jleffler@us.ibm.com (jleffler@informix.com)
Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
            *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Please update your address book to use jleffler@us.ibm.com because
jleffler@informix.com will not work starting 2002-07-01.  Expect
slower responses because I can't use Lotus Notes as fast as Unix
email.  One day, this signature will shrink!

PS: GIGO = Garbage In, Garbage Out.

0
jleffler
2/13/2002 6:58:34 PM
On Wed, 13 Feb 2002, H.Merijn Brand wrote:
>On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
>> -The next thing is you really execute the statement. Note that you must
>> -prepare the attributes NUM_OF_FIELDS, NAME, ... when the statement is
>> -successfully executed if you have not already done so: They may be used even before a potential
>> -I<fetchrow>. In particular you have to tell DBI the number of fields,
>> -that the statement has, because it will be used by DBI internally.
>> +The next thing is you really execute the statement.
>> +Note that you must prepare the attributes NUM_OF_PARAMS, NUM_OF_FIELDS,
>> +NAME, etc when the statement is successfully executed if the driver has
>> +not already done so.
>> +They may be used even before a potential I<fetchrow>.
>> +In particular you have to tell DBI the number of fields, that the
>> +statement has, because it will be used by DBI internally.
>
>Maybe mention that these attributes might act different on positional
>parameters and returned values. For example in the DEC port of DBD-Unify,
>accessing the NAME field of positional parameters dumps core, where it works
>fine in the returned values. This is due to the database, not the DBD program.
>I've tested that with stand-alone code which also fails. (I have no DEC
>machines anymore, so I cannot test newer releases)
>
>Unify might be the odd one out here, but as this is aguideline to new DBD
>authors (and a reference to existing DBD authors that want to update their
>drivers to the latest DBI), it might be worth mentioning.

I need some clarification here...

    Positional parameters = 'input parameters'?
        That is, positional parameters are the values supplied to
        the execute statement for placeholders?
    Return values = 'output parameters'?
        That is, the return values are the values in the select-list
        of a SELECT statement?

Under Informix, the input parameters do not have names at all.  I
thought the $sth->{NAME} stuff only applied to the output parameters.
Am I missing something?  How do you get at the names of the positional
parameters in DBI?  Which DBMS provide names for the positional
parameters?  Given that some (possibly old) variants on preparse()
expect :name notation to mark a placeholder, I can see that you could
derive a name for such parameters.  Informix does not support that
notation, and has a separate meaning for the syntactic fragment
(dbase@server:owner.table or dbase:table or dbase:owner.table) so it is
not feasible to have DBI add such support for DBD::Informix.

-- 
Jonathan Leffler                           #include <disclaimer.h>
STSM, Informix Database Engineering, IBM Data Management Solutions
Phone: +1 650-926-6921                          Tie-line: 630-6921
Email: jleffler@us.ibm.com (jleffler@informix.com)
Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
            *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Please update your address book to use jleffler@us.ibm.com because
jleffler@informix.com will not work starting 2002-07-01.  Expect
slower responses because I can't use Lotus Notes as fast as Unix
email.  One day, this signature will shrink!

0
jleffler
2/13/2002 7:07:00 PM
On Wed 13 Feb 2002 20:07, Jonathan Leffler <jleffler@informix.com> wrote:
> On Wed, 13 Feb 2002, H.Merijn Brand wrote:
> >On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> >> -The next thing is you really execute the statement. Note that you must
> >> -prepare the attributes NUM_OF_FIELDS, NAME, ... when the statement is
> >> -successfully executed if you have not already done so: They may be used even before a potential
> >> -I<fetchrow>. In particular you have to tell DBI the number of fields,
> >> -that the statement has, because it will be used by DBI internally.
> >> +The next thing is you really execute the statement.
> >> +Note that you must prepare the attributes NUM_OF_PARAMS, NUM_OF_FIELDS,
> >> +NAME, etc when the statement is successfully executed if the driver has
> >> +not already done so.
> >> +They may be used even before a potential I<fetchrow>.
> >> +In particular you have to tell DBI the number of fields, that the
> >> +statement has, because it will be used by DBI internally.
> >
> >Maybe mention that these attributes might act different on positional
> >parameters and returned values. For example in the DEC port of DBD-Unify,
> >accessing the NAME field of positional parameters dumps core, where it works
> >fine in the returned values. This is due to the database, not the DBD program.
> >I've tested that with stand-alone code which also fails. (I have no DEC
> >machines anymore, so I cannot test newer releases)
> >
> >Unify might be the odd one out here, but as this is aguideline to new DBD
> >authors (and a reference to existing DBD authors that want to update their
> >drivers to the latest DBI), it might be worth mentioning.
> 
> I need some clarification here...
> 
>     Positional parameters = 'input parameters'?
>         That is, positional parameters are the values supplied to
>         the execute statement for placeholders?

Yes

>     Return values = 'output parameters'?
>         That is, the return values are the values in the select-list
>         of a SELECT statement?

Yes.

> Under Informix, the input parameters do not have names at all.  I
> thought the $sth->{NAME} stuff only applied to the output parameters.

DBD::Unify supports for this is based on E/SQL, which makes no difference in
the documentation among input (positional) or output parameters, but as the
code shows:

/* for output fields */
int dbd_fld_describe (SV *dbh, imp_sth_t *imp_sth, int num_fields)
{
    register	imp_fld_t	*f;
    register	int		i;

    dbg (3, "DBD::Unify::fld_describe %s (%d fields)\n", o_sql_nm, num_fields);

    unless (num_fields > 0 &&
           (imp_sth->fld = (imp_fld_t *)calloc (num_fields, sizeof (imp_fld_t))))
	return (0);

    for (fix = 1; fix <= num_fields; fix++) {
	f = &imp_sth->fld[fix - 1];
	EXEC SQL
	    GET DESCRIPTOR :o_sql_nm
	    VALUE :fix
		  :ftp = TYPE,
		  :fln = LENGTH,
		  :fpr = PRECISION,
		  :fic = INDICATOR,
		  :fsc = SCALE,
		  :fnl = NULLABLE,
		  :fnm = NAME;
	dbg (3, "    After get,      sqlcode = %d\n", SQLCODE);
	unless (sqlError (dbh))
	    return (0);

/* for input fields */
int dbd_prm_describe (SV *dbh, imp_sth_t *imp_sth, int num_params)
{
    register	imp_fld_t	*f;
    register	int		i;

    dbg (3, "DBD::Unify::prm_describe %s (%d params)\n", i_sql_nm, num_params);

    unless (num_params > 0 &&
           (imp_sth->prm = (imp_fld_t *)calloc (num_params, sizeof (imp_fld_t))))
	return (0);

    for (fix = 1; fix <= num_params; fix++) {
	f = &imp_sth->prm[fix - 1];
	EXEC SQL
	    GET DESCRIPTOR :i_sql_nm
	    VALUE :fix
		  :ftp = TYPE,
		  :fln = LENGTH,
		  :fpr = PRECISION,
		  :fic = INDICATOR,
		  :fsc = SCALE,
		  :fnl = NULLABLE/*, Core dump on OSF/1 & Solaris
		  :fnm = NAME     */;
	unless (sqlError (dbh))
	    return (0);

No name support for paramaters.

> Am I missing something?  How do you get at the names of the positional
> parameters in DBI?  Which DBMS provide names for the positional
> parameters?  Given that some (possibly old) variants on preparse()
> expect :name notation to mark a placeholder, I can see that you could
> derive a name for such parameters.  Informix does not support that
> notation, and has a separate meaning for the syntactic fragment
> (dbase@server:owner.table or dbase:table or dbase:owner.table) so it is
> not feasible to have DBI add such support for DBD::Informix.
> 
> -- 
> Jonathan Leffler                           #include <disclaimer.h>
> STSM, Informix Database Engineering, IBM Data Management Solutions
> Phone: +1 650-926-6921                          Tie-line: 630-6921
> Email: jleffler@us.ibm.com (jleffler@informix.com)
> Notes ID: Jonathan Leffler/Menlo Park/IBM@IBMUS
> Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
>             *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
> Please update your address book to use jleffler@us.ibm.com because
> jleffler@informix.com will not work starting 2002-07-01.  Expect
> slower responses because I can't use Lotus Notes as fast as Unix
> email.  One day, this signature will shrink!


-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
     WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/

0
h
2/14/2002 3:45:04 PM
On Wed, Feb 13, 2002 at 10:58:34AM -0800, Jonathan Leffler wrote:
> On Wed, 13 Feb 2002, H.Merijn Brand wrote:
> >On Wed 13 Feb 2002 02:02, Jonathan Leffler <jleffler@informix.com> wrote:
> >> +=over 4
> >> +
> >> +*FIX ME* If there are statements 'active' when the $dbh is destroyed,
> >> +does DBI arrange to destroy those statement handles, or does the driver need to
> >> +do the work itself?
> >> +
> >> +=back
> >
> >Depends on the database. In DBD-Unify I *have to* do it myself, but some
> >guidelines would be much appreciated for future DBD's
> 
> At the moment, the DBD::Informix driver explicitly keeps track of
> all the database handles it has, and for each database handle,
> keeps a track of all the associated statement handles.  When a
> database handle is destroyed, I have code that tracks through all
> the associated statement handles and releases them.  *BUT* I've
> never spotted any activity while doing this.  So, I think that
> DBI is also keeping track of statement handles and calling the
> statement handle release code before calling the database handle
> release code, so my driver is doing unnecessary work.  I'd like
> to get rid of the code that tracks statement handles (in
> particular) and database handles.  But I'd like a clear statement
> from those who can understand the DBI code that this is
> unnecessary.

That a part of the DBI I only think I understand on alternate Thursdays :)

But I can tell you that when a database handle is destroyed the DBI
cannot to anything with the corresponding statement handles because
it doesn't have a copy of those handles (as that would create a
reference loop.  (One day the DBI may use weak refs for that.)

But... the statement handles hold a reference to their parent
database handle (possibly the inner handle, I forget) and so a
database handle won't normaly be DESTROY'd till all its children are.

> All this needs to be written out clearly (and with luck will be
> by the time I've finished), but it needs accurate input - GIGO
> applies.

I'm suffering with a bit of a head cold right now so you're likely
to get garbage out whatever the input :)

I'll let you consolidate any other inputs and repost a fresh diff
and I'll aim to reply to that within a few days.

Many thanks for this work Jonathan!

Tim.
0
Tim
2/21/2002 9:09:30 PM
Reply:

Similar Artilces:

Patches for DBI v1.32
---559023410-851401618-1039913737=:6184 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Tim, Here's a new set of patches against the original DBI v1.32 for the files: Driver.xst dbd_xsh.h lib/DBI/DBD.pm The patches are gzipped. To apply them, use: gunzip DBI.patches.gz cd DBI-1.32 patch -p0 <../DBI.patches The DBD.pm file has undergone a whole lot more change -- it is, I think, in even better shape than the version shipped earlier. If you need them, I can redo the patches against that revised version of the file, but I'd rather no...

DBI-1.21 DBI.xs patch
--------------ms10979709E84C5FA689C39B1B Content-Type: multipart/mixed; boundary="------------EF8C4696EAE17FB10D560866" This is a multi-part message in MIME format. --------------EF8C4696EAE17FB10D560866 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Dear Tim, I receive the error "Can't read $DBI::err, last handle unknown or destroyed during global destruction" many times (and for $DBI::errstr too). I'm not able to say what is the reason of these errors. Setting the trace levelel to 10 didn't help, and trace files w...

More about DBI::DBD (v1.21)
Hi - another question: The sample code for DBD::Driver::db::prepare starts: sub prepare { my ($dbh, $statement, @attribs) = @_; # create a 'blank' sth my $sth = DBI::_new_sth($dbh, { 'Statement' => $statement, }); Question: does DBI keep track of the statement text, or do the DBD modules all have to do it? If DBI tracks it automatically, does that make the above code wrong, or just superfluous? If DBI does not track it, that presumably means that the DBD FETCH functions have to handle it, whereas if DBI does...

Problem / BUG with blob_read and DBI v1.21 and DBD::Oracle v1.12
I am trying to read from an oracle CLOB. When i call blob_read with 5 parameters then my script dies with a usage error; DBI blob_read: invalid number of parameters: handle + 5 Usage: $h->blob_read($field, $offset, $len [, \$buf [, $bufoffset]]) at test.pl line 112. It works correctly when only given the first 4 parameters. I tested the fifth parameter with values of 0 and indexes that were valid within $buf... Thanks! Mark. ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains ...

[perl5-dbi/DBI-Test] 259b89: perltidy lib/DBI/Mock.pm
----==_mimepart_51de492438906_56b10afdd8124440 Date: Wed, 10 Jul 2013 22:56:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <51de492439365_56b10afdd81245a8@hookshot-fe2-pe1-prd.aws.github.net.mail> Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 259b8946d0112c630dfc1d1807824fd6305ca46c https://github.com/perl5-dbi/DBI-Test/commit/259b8946d0112c630dfc1d1807824fd6305ca46c Author: Jens Rehsack <sno@netbsd.org> Date: 2013-07-10 (Wed, 10 Jul 2013) Changed ...

DBI w/ DBD:ODBC or DBI w/ DBD:mysql Which?
------=_NextPart_000_0009_01C1D022.ADFABA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am new to Perl DBI programming But it is fairly simple.. I am using both Mysql 3.23.44nt and 3.23.43 Linux..as well as PostgreSQL 7.1 Linux and on WinXP on Cygwin. Perl on Linux was straight forward but the Perl on WIn is a bit = Different. I ran a simple script to insert records in a table as test and it worked = but I am unsure that the WinXP install of Perl and DBI is correct that is do I = have the=20 correct modules in place. ...

DBI 1.38: Undefined subroutine &DBD::_::db::croak called at DBI.pm line 1496
--------------043611293F9F9B63EB9B52C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Tim, the attached patch adds 'Carp::' to all unqualified calls to carp() and croak(). You'll get the error message above with something like perl -MDBI -e 'DBI->connect()->primary_key($c,$s,$t)' Steffen --------------043611293F9F9B63EB9B52C5 Content-Type: text/plain; charset=us-ascii; name="DBI.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DBI.diff" *** DBI.orig Fri Aug 22 23:...

DBI w/ DBD:ODBC vs DBI w/ DBD:mysql
------=_NextPart_000_002D_01C1D002.8689BBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am new to Perl DBI programming But it is fairly simple.. I am using both Mysql 3.23.44nt and 3.23.43 Linux..as well as PostgreSQL 7.1 Linux and on WinXP on Cygwin. Perl on Linux was straight forward but the Perl on WIn is a bit = Different. I ran a simple script to insert records in a table as test and it worked = but I am unsure that the WinXP install of Perl and DBI is correct that is do I = have the=20 correct modules in place. ...

Incompatibility with DBI v1.56 / DBD::Sybase v1.08 / DBIx::ContextualFetch v1.03
Hello, We're running Perl v5.8.6 on Linux, Solaris Sparc, and Solaris x86. We're using the latest DBI/DBD related modules: o DBI v1.56 o DBD::Sybase v1.08 o DBIx::ContextualFetch v1.03 o Class::DBI v3.0.16 o Class::DBI::Sybase v0.5 o Ima::DBI v0.34 o etc We recently upgraded DBD::Sybase from v1.07 to v1.08. The upgrade resulted in the following problem on all platforms: Undefined subroutine &DBIx::ContextualFetch::st::DELETE I mentioned the problem to Michael Peppler; however, I don't think he's very familiar with DBIx::ContextualFetch and friends ....

[perl5-dbi/DBI-Test] 5cf68f: add lib/DBI/Test/DSN/Provider/Base.pm
----==_mimepart_5200b27ad097b_429583bd501034ce Date: Tue, 06 Aug 2013 01:23:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <5200b27ad1491_429583bd5010352a@hookshot-fe2-pe1-prd.aws.github.net.mail> Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: 5cf68fcc017e162265b676bf7343878aa2832462 https://github.com/perl5-dbi/DBI-Test/commit/5cf68fcc017e162265b676bf7343878aa2832462 Author: Jens Rehsack <sno@netbsd.org> Date: 2013-08-06 (Tue, 06 Aug 2013) Changed ...

[perl5-dbi/DBI-Test] a2d1b2: create separate tests for DBI and DBI::Mock ...
----==_mimepart_51f946a54bb1b_2af891bd4c100430 Date: Wed, 31 Jul 2013 10:17:25 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <51f946a54c721_2af891bd4c100582@hookshot-fe3-pe1-prd.aws.github.net.mail> Branch: refs/heads/master Home: https://github.com/perl5-dbi/DBI-Test Commit: a2d1b22d134be0ca353e0f0b312fb14da24c798e https://github.com/perl5-dbi/DBI-Test/commit/a2d1b22d134be0ca353e0f0b312fb14da24c798e Author: Jens Rehsack <sno@netbsd.org> Date: 2013-07-31 (Wed, 31 Jul 2013) Changed ...

multiple DBI::Format's in CPAN installing to different locations, and $VERSION bug in DBI-Shell-11.9/lib/DBI/Format/SQLMinus.pm
DBI::Format comes with DBI-1.32 in lib/DBI/Format.pm as VERSION 11.4 and DBI-Shell-11.9 in lib/DBI/Format.pm as VERSION 11.8 According to the .packlist files DBI installs Format.pm in /usr/local/lib/perl5/site_perl/5.9.0/i686-linux/DBI but DBI/Shell installs the newer version in /usr/local/lib/perl5/site_perl/5.9.0/DBI/Format.pm In my @INC, /usr/local/lib/perl5/site_perl/5.9.0/i686-linux (where DBI installs the older Format.pm) comes before /usr/local/lib/perl5/site_perl/5.9.0 (where the newer DBI-Shell is installed) This causes the older DBI::...

[perl5-dbi/dbi]
----==_mimepart_515e8f3785207_523740c1306299e Date: Fri, 05 Apr 2013 01:45:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <515e8f3787c27_523740c13063084@hookshot-fe5-pe1-prd.aws.github.net.mail> Branch: refs/heads/trunk Home: https://github.com/perl5-dbi/dbi ----==_mimepart_515e8f3785207_523740c1306299e-- ...

DBI: Can't locate DBI.pm
What's this error? The DBI package is not installed? "Software error: [Thu Mar 6 15:01:54 2003] DBI.pm: Can't locate DBI.pm in @INC (@INC contains: /usr/local/lib/perl5/5.00503/i386-freebsd /usr/local/lib/perl5/5.00503 /usr/local/lib/site_perl /usr/local/lib/site_perl .) at /usr/local/etc/httpd/vhosts/vencendo/criabasededados.pl line 6. BEGIN failed--compilation aborted at /usr/local/etc/httpd/vhosts/vencendo/criabasededados.pl line 6." Paulo _________________________________________________________________ MSN Hotmail, o maior webmail do Brasil. ...

Web resources about - Patch to DBI::DBD.pm (v1.21) - perl.dbi.dev

Resources last updated: 11/24/2015 2:28:38 AM