Thanks for the help Tim.
Tim Bunce wrote:
On Mon, Nov 05, 2007 at 03:11:13PM +0000, Martin Evans wrote:
I have almost been able to answer all of my questions:
Martin Evans wrote:
Hi,
I am almost finished a number of changes to DBD::ODBC which a) make it work
on win64 platforms and b) reduce the number of ODBC calls required for
select statements. I would like to tidy up some of DBD::ODBC which may have
fallen behind DBI::DBD changes/improvements but I am having some difficulty
deciding what is old/deprecated and what the new "methods" are.
Specifically:
o can I now throw away any DBIh_EVENT2 calls as they are now noops?
e.g. DBIh_EVENT2(drh, ERROR_event, DBIc_ERR(imp_drh),
DBIc_ERRSTR(imp_drh));
Should have pointed out I had read DBI::DBD about this but as I do not know
what DBIh_EVENT2 did I do not know if it is a simple delete these calls or
replace with something else.
They can be deleted.
Thanks, they have now gone. I notice a number of other DBDs still have
these too.
o in the connect/login method how do I signal a warning?
Specifically, I have changed the code which required two passes through the
same metadata calls to work out how much memory was required to store
column names to use SQLGetInfo(SQL_MAX_COLUMN_NAME_LEN) but would like to
warn if this result used was pinned at what I have decided is a reasonable
maximum.
I found the following in a post on dbi-dev back in April
DBIh_SET_ERR_CHAR (h, imp_xxh, "0", 0, what)
I should point out I needed to add a couple of Nullch args added to the end
as the macro DBIh_SET_ERR_CHAR needs 7 args.
Thanks. Patches to the DBI::DBD docs are *most welcome*!
I'll change it and commit to subversion later this morning.
This works. Out of interest, the set_err docs also say setting err to "" is
an informational state. Under what conditions do/can you see those?
Unlike warnings (where err is 0 and $h->{PrintWarn}=1 enables output)
there's no automatic output for informational states.
(I could probably be persuaded to add a PrintInfo attribute,
especially if a patch with docs and tests was offered :-)
Steffen pointed me in the right direction. I've now changed DBD::ODBC so
that a few places which were discarding informational messages are now
returning them. I'll consider your PrintInfo suggestion after I get the
next DBD::ODBC released.
Obviously I've looked at DBI::DBD but it seems more orientated to writing a
new DBD than historical changes in DBI internals.
Are there any other changes in DBI::DBD that DBD::ODBC may have fallend
behind on I should look for?
Any help would be much appreciated.
Martin
In the same post referred to above I found a number of comments from Tim
about DBD::mysql some of them may seem to apply to DBD::ODBC too (see
http://www.mail-archive.com/[email protected]/msg04725.html). Specifically:
"DBIc_ERR and DBIc_ERRSTR, and DBIc_STATE should not be set directly."
which DBD::ODBC seems to do quite a bit:-(
The DBIh_SET_ERR* macros are the way to go.
I've now gone that way.
Thanks again Tim.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
