[DB-SIG] Re: DB-SIG digest, Vol 1 #445 - 1 msg

[John Shafaee]

I agree with your approach. I wrote my own DB factory class and DB interface
wrapper which simply grabs the DB warning exceptions and ignores them (well,
it makes note of them silently). THis has worked very well for me and has
passed the test of time.

It would be great to have this support at a lower level as it will make
working with stored procedures a lot easier, as you have already noted.

John S

db-sig-request@python.org wrote:

> Send DB-SIG mailing list submissions to
>         db-sig@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.python.org/mailman/listinfo/db-sig
> or, via email, send a message with subject or body 'help' to
>         db-sig-request@python.org
>
> You can reach the person managing the list at
>         db-sig-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DB-SIG digest..."
>
>   ------------------------------------------------------------------------
> Today's Topics:
>
>    1. How to handle database warnings ? (M.-A. Lemburg)
>
>   ------------------------------------------------------------------------
>
> Subject: [DB-SIG] How to handle database warnings ?
> Date: Fri, 20 Jul 2001 20:07:24 +0200
> From: "M.-A. Lemburg" <mal@lemburg.com>
> Organization: eGenix.com Software GmbH -- http://www.egenix.com/
> To: "DB-SIG @ Python.org" <db-sig@python.org>
>
> I am currently working on a modification to mxODBC which solves
> the problems users sometimes have with database warnings.
> Since I think that some other database modules may have the
> same problem, I would like to get your opinion about this.
>
> mxODBC currently converts most warnings from the database
> into Python exceptions. This sometimes causes failure of
> more complex operations like e.g. calling stored procedures.
>
> To solve this, I've added a list attribute .messages to both
> connection and cursor objects which will hold the error
> and warning messages generated by the low-level code in the
> order they are generated by the database. Errors will still be
> reported using Python exceptions, but I am planning
> to drop the exception mechanism for warnings.
>
> The latter will then only be available by looking at the
> .messages list.
>
> Now to make this easy and also to avoid the generation of
> large message lists, I am thinking of auto-clearing the
> .messages lists after prior to all method calls.
>
> This would then enable code like:
>
>    c.execute(sql)
>    if c.messages:
>       # got some warnings
>       print c.messages
>    for row in c.fetchall():
>       ...
>
> What do you think ?
>
> --
> Marc-Andre Lemburg
> CEO eGenix.com Software GmbH
> ______________________________________________________________________
> Company & Consulting:                           http://www.egenix.com/
> Python Software:                        http://www.lemburg.com/python/