[python-win32] Bug reporting
Bob Kline
bkline at rksystems.com
Wed Feb 21 10:26:27 EST 2018
[ Having a conversation with myself again :-) ]
It looks as if the second problem I reported with the Access suite is
a result of one of my patches. Apparently with the patch Access (but
not SQL Server) treats binary values incorrectly (at least sometimes).
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.
I have added MySQL to my test bed. That flushed out yet another error.
This is the output run using the unpatched (except for configuration
settings in adodbapitestconfig.py, of course, and supplying the
missing ../examples/adotest.mdb file) code base pulled directly from
the Mercurial server (hg clone http://hg.code.sf.net/p/adodbapi/code
adodbapi):
Z:\repos\adodbapi\test>python adodbapitest.py --mysql
2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
node=xp: is64bit.os()= True, is64bit.Python()= True
adodbapi v2.6.1.3
testADOdbapiConfig.py v 2.6.0.A00
...copying test ACCESS db to
c:\users\bkline\appdata\local\temp\adodbapi_test\xx_T949JL5KW.mdb
...Testing ACCESS connection...
(successful)
...Testing MS-SQL login...
(successful)
...Testing MySql login...
(successful)
Unit tests version 2.6.1.0 for adodbapi
Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
object at 0x0000000006510CF8>
...................................................................................................................ADO
Errors:(1)
Description: [MySQL][ODBC 5.3(w)
Driver][mysqld-5.7.21-0ubuntu0.17.10.1]Data too long for column
'fldData' at row 1
Error: -2147467259 unknown
Source: Microsoft OLE DB Provider for ODBC Drivers
NativeError: 1406
SQL State: S1000
E...........................
======================================================================
ERROR: testDataTypeInt (__main__.TestADOwithMySql)
----------------------------------------------------------------------
Traceback (most recent call last):
File "adodbapitest.py", line 356, in testDataTypeInt
self.helpTestDataType("bit",'NUMBER',1) #Does not work correctly with access
File "adodbapitest.py", line 287, in helpTestDataType
crsr.execute("INSERT INTO xx_%s (fldId,fldData) VALUES (?,?)" %
config.tmp, (fldId, inParam))
File "Z:\repos\adodbapi\adodbapi.py", line 879, in execute
self._execute_command()
File "Z:\repos\adodbapi\adodbapi.py", line 694, in _execute_command
self._raiseCursorError(klass, _message)
File "Z:\repos\adodbapi\adodbapi.py", line 567, in _raiseCursorError
eh(self.connection, self, errorclass, errorvalue)
File "Z:\repos\adodbapi\apibase.py", line 54, in standardErrorHandler
raise errorclass(errorvalue)
DatabaseError: (-2147352567, 'Exception occurred.', (0, u'Microsoft
OLE DB Provider for ODBC Drivers', u"[MySQL][ODBC 5.3(w)
Driver][mysqld-5.7.21-0ubuntu0.17.10.1]Data too long for column
'fldData' at row 1", None, 0, -2147467259), None)
Command:
INSERT INTO xx_T949JL5KW (fldId,fldData) VALUES (?,?)
Parameters:
[Name: p0, Dir.: Input, Type: adInteger, Size: 0, Value: "2",
Precision: 0, NumericScale: 0
Name: p1, Dir.: Input, Type: adInteger, Size: 0, Value: "1",
Precision: 0, NumericScale: 0]
----------------------------------------------------------------------
Ran 143 tests in 35.413s
FAILED (errors=1)
Thanks,
Bob
On Wed, Feb 21, 2018 at 7:31 AM, Bob Kline <bkline at rksystems.com> wrote:
> Hi, Vernon. I'm afraid I'm going to start sounding like an annoying
> nag. :-) If you really want help with this project, you need to meet
> me half way. If you're swamped with work right now, please at least
> write back and say something like "I'm buried under a project right
> now, and I won't be able to get back to you until next Friday." If
> you're in hospital with a serious illness, I sincerely apologize and
> I'll back off. If you'd prefer to take this thread offline, that's
> fine with me, too.
>
> I asked for guidance in getting the regression tests running (if we're
> going to attract maintainers, one of the first things that needs to
> happen is for the configuration script for the test suite to be made
> much simpler to adapt to a specific platform, with all of the values
> which need to be modified collected in one place with clear
> documentation for what each of them means), but I didn't see anything
> from you in response to that request, so I plunged in on my own. I've
> got the SQL Server and Access tests running, and expect it won't be
> too long before I've got the other back ends set up and plugged in. I
> ran into two problems with the Access tests. The first is that
> setuptestframework.py tries to copy a file from
> ../examples/adotest.mdb and that file doesn't exist (except perhaps on
> your own machine). I solved that by firing up Access and creating the
> missing file myself. The second problem is that one of the tests in
> the suite fails. From the error message, it appears that the package
> (or perhaps something else in the stack) is trying to treat a binary
> value as a string (note the presence of the null terminator at the end
> of the value and the extra quote marks in the repr() output):
>
> C:\Python\Lib\site-packages\adodbapi\test>adodbapitest.py
> 2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
> node=xp: is64bit.os()= True, is64bit.Python()= True
> adodbapi v2.6.0.7
> testADOdbapiConfig.py v 2.6.0.A00
> ...copying test ACCESS db to
> c:\users\bkline\appdata\local\temp\adodbapi_test\xx_COU8KEJ7K.mdb
> ...Testing ACCESS connection...
> (successful)
> ...Testing MS-SQL login...
> (successful)
> Unit tests version 2.6.0.6 for adodbapi
> Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
> object at 0x0000000005970C18>
> ...............................F.......................................................................
> ======================================================================
> FAIL: testDataTypeBinary (__main__.TestADOwithAccessDB)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
> line 395, in testDataTypeBinary
> allowedReturnValues=arv)
> File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
> line 314, in helpTestDataType
> 'Value "%s" not in %s' % (repr(rs[0]), allowedReturnValues))
> AssertionError: Value "'\x07\x00\xe2@\x00'" not in ['\x07\x00\xe2@*',
> <read-only buffer for 0x0000000005183990, size -1, offset 0 at
> 0x0000000005A0D6C0>, '\x07\x00\xe2@*']
>
> ----------------------------------------------------------------------
> Ran 103 tests in 8.394s
>
> FAILED (failures=1)
>
> I get the same failure if I use a more modern .accdb file.
>
> Again, I apologize for this blunt message, but you've done some good
> work on this package, and it's worth getting it back on the road.
>
> Regards,
> Bob Kline
>
> On Mon, Feb 19, 2018 at 11:59 AM, Bob Kline <bkline at rksystems.com> wrote:
>> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
>>
>>> Sounds like a good plan.
>>
>> As in, "yes, let's consolidate the project in one place (under pywin
>> on GitHub)"? Or did you mean "yes, I agree we should have the
>> discussion about whether we have to maintain the package in more than
>> one place"? If the former, I'll be happy to get the ball rolling by
>> starting the analysis for topping up the GitHub repo from the
>> SourceForge oledbapi repo. If the latter, I guess the first step in
>> that discussion would be for you to lay out the reason(s) why it
>> wouldn't work to maintain the project just on GitHub (under pywin). Or
>> perhaps you intended some third interpretation of "good plan."
>>
>> Cheers,
>> Bob
>>
>>>
>>> On Feb 19, 2018 04:57, "Bob Kline" <bkline at rksystems.com> wrote:
>>>>
>>>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com>
>>>> wrote:
>>>>
>>>> > I will try to clear this up as much as I can...
>>>>
>>>> Thanks very much for your reply, Vernon.
>>>>
>>>> > Adodbapi lives in two places, as a stand-alone project on Sourceforge,
>>>> > and
>>>> > integrated with PyWin32.
>>>>
>>>> Well, I wouldn't go so far as saying it "lives" in the GitHub project;
>>>> more like it's on life support. :-) As far as I can tell, it's never
>>>> actually been usable from that repo, as the required apibase.py file
>>>> didn't make it to the party.
>>>>
>>>> > The Sourceforge project is needed for Iron Python, and has more
>>>> > documentation, and, originally, a faster upgrade cycle.
>>>>
>>>> I see, however, that the code to support IronPython is in both places,
>>>> documentation can easily be enhanced, and (as you acknowledge) the
>>>> upgrade cycle for the SourceForge project has gone walkabout. It would
>>>> seem ideal (if nothing else, from the perspective of the attempt to
>>>> attract more maintainers) if we didn't have to maintain two separate
>>>> code bases.
>>>>
>>>> > The SF code was copied to pywin32 for easier installation and more
>>>> > convenience, but the file layout is slightly different. I did not have
>>>> > the
>>>> > capability to test the pywin32 installation so was unaware of the
>>>> > problem
>>>> > until too late. Then I went to work for another company which did not
>>>> > use
>>>> > Windows at all, so everything got kind of lost.
>>>> >
>>>> > The move of pywin32 to GitHub, along with improved testing there will
>>>> > help
>>>> > to fix things. I am also building an SQL server test bench which I hope
>>>> > will be permanent. A patch has been submitted to fix the "missing file"
>>>> > problem, and I have changed my SF notifications to a different email
>>>> > address
>>>> > that I check more frequently.
>>>> >
>>>> > The python-win project is the preferred maintenance place.
>>>>
>>>> Perhaps a note on the SourceForge page to that effect would be
>>>> appropriate.
>>>>
>>>> > Meanwhile ... I am not getting any younger and an active back-up
>>>> > maintainer
>>>> > for the home adodbapi project would be very welcome if someone were
>>>> > willing
>>>> > to help out. At the present moment the "bus size" is one -- which is a
>>>> > bad
>>>> > thing.
>>>>
>>>> I'm happy to do what I can, though as I pointed out in an earlier
>>>> thread, you're younger than I am. :-)
>>>>
>>>> If you provide instructions for getting the regression tests running,
>>>> I'll try to replicate them here.
>>>>
>>>> Let's first decide the question of how many places we're going to
>>>> maintain the package. I vote for one (on GitHub). If (for whatever
>>>> reason) it's necessary to maintain it in two places, let's (a) decide
>>>> whether it's possible to keep the two places synchronized so they
>>>> don't drift into forks of each other; (b) figure out how such
>>>> synchronization will be accomplished; and most important (c) make it
>>>> very clear in both locations what the relationship is between the two
>>>> repositories, telling everyone which one should be used in which
>>>> situation, where to file issue tracking tickets, etc.
>>>>
>>>> Thanks again for your willingness to bring this project back to life.
>>>>
>>>> --
>>>> Bob Kline
>>>> http://www.rksystems.com
>>>> mailto:bkline at rksystems.com
>>
>>
>>
>> --
>> Bob Kline
>> http://www.rksystems.com
>> mailto:bkline at rksystems.com
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com
--
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com
More information about the python-win32
mailing list