[resent as the original bounced (eventually) due to some configuration changes]
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.
> > 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*!
> 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 :-)
> > 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.
Tim.
