On Wed, Feb 21, 2018 at 10:26 AM, Bob Kline <bkl...@rksystems.com> wrote:
> Without the patch, SQL Server is unable to store a NULL value or an
> empty string properly using placeholders. So we need to find out why
> that is, and come up with a version of the patch which fixes the
> second problem in SQL Server without introducing the first problem in
> Access.
The original code only tries to use ADO's existing parameters if a
stored procedure is being invoked. The comment said:
# needed only if we are calling a stored procedure
Can you tell us why this would be true? Do we know for sure that the
binary-handling problem I ran into doesn't bite us if we're in a
stored procedure?
The solutions (for the two bugs my patch attempted to address) which
come immediately to mind include:
1. figure out exactly what the difference is in the behavior or
ADO's parms and the ones the code replaces them with; base the
solution on this understanding;
2. if it is possible to detect at this point in the code which DBMS
engine is being used, then branch in the logic based on that
knowledge; or
3. allow the user of the package to control whether we try to use
ADO's parameter list
Clearly, the first solution is the ideal choice, if we can pull it
off. I'm not sure about the relative merits of the other two. The
second option has the advantage of avoiding bug reports from users who
didn't manage to find the documentation about setting the special
option to avoid the bugs we're trying to fix (as would be required by
option #3). The last option gives the users who do read all the
documentation the flexibility to control the behavior, with perhaps
the better chance of avoiding the bugs we're wrestling with. It (that
is, the attractiveness of option #2) partly depends on (a) how
reliable our detection of which DBMS we're talking to is and (b) how
confident we are that we know which paths will produce the desired
behavior for which DBMS engines.
You might have thought of other solutions which haven't occurred to me
yet. I'm all ears. :-)
Cheers,
Bob
_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
