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