Re: [python-win32] Uninstallation Command Required

[Bob Kline]

Depends on how it was installed. If you used the installer from python.org,
it might look like this:

python-3.11.1-amd64.exe /uninstall /quiet > uninstall.log

(Adjust the name of the executable to match the version you installed.)

If you used some other distribution (for example, from ActiveState) follow
the instructions provided by that distributor.

On Wed, Sep 20, 2023 at 3:19 PM Sujith R  wrote:

> Hi Team,
>
> I need to uninstall python via windows command prompt. I tried lots of
> various commands but it’s not worked well. Can you please help me to solve
> this issue.
>
> SUMMARY: Need a proper uninstall command for windows
>
> Thanks in advance.
> ___
> python-win32 mailing list
> python-win32@python.org
> https://mail.python.org/mailman/listinfo/python-win32
>


-- 
Bob Kline
https://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Object type puzzle

[Bob Kline]

On Sat, Jan 7, 2023 at 2:14 PM Tim Roberts  wrote:

> ...
> Ah, you youngsters who don't remember the glory days. 

Well, I'll be 75 in a couple of weeks, so I don't know how well I
still qualify as a "youngster." 

It's more likely that I knew about that "feature" at one time (I used
Pine on Unix to read my email for quite a few years, and I wrote a
bunch of email gateways several decades back), and in my scramble to
keep up with the actual "youngsters" my brain pushes out to the bin
the things it decides it doesn't need any more (your description does
ring a bell). As time goes on, the ratio of what I once knew but have
forgotten to what I still remember changes faster than I'd like. ⏳
Your memory, on the other hand, seems to be doing just fine. 

Cheers,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Object type puzzle

[Bob Kline]

As a very minor side note, just so you know, it looks like there's a
bug in the mailing list software. I went back to the original of my
previous post, and the ">" character which appears at the beginning of
the paragraph beginning "From what I can tell ..." was not in the
message that I sent, but was added by the mailing list, making it look
as if that paragraph might have been part of the quoted message to
which I was replying, instead of what it actually was (part of my own
reply).

Cheers,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Object type puzzle

[Bob Kline]

On Tue, Jan 3, 2023 at 9:08 PM Mark Hammond  wrote:
> ...
> This is probably just defined by IDispatch and related interfaces. There
> is a good chance that JScript magically uses multiple interfaces at the
> same time for an object, whereas Python only tends to use one.

Right. Presumably JScript either examines the COM introspection
information and figures out which interface can handle the request or
(sloppier) it tries each in a try ... catch block until one doesn't
fail. (Same for VBScript.)

> I suspect the root of the problem is that Python ends up in
> https://github.com/mhammond/pywin32/blob/main/com/win32com/client/__init__.py#L38,
> and as you can see it only uses the first possible type info for the
> IDispatch. It would be interesting to know if the objects with this
> behaviour have multiple entries there with the one you care about being
> at somewhere other than 0.

From what I can tell (at least for the paths I tested this morning),
that helper function is never called without resultCLSID being set, so
that block of the code is never entered (for our application).

> But even if that's true, I'm not quite sure what you can do to smooth
> this over - we can't just make that code use, say, `[-1]` - but it still
> would be useful to identify if that's the problem.

Well, at least we have a workaround that works. And our consolation
prize is that the workaround is probably more efficient than the
dynamic interface navigation the scripting engine would do.

Again, thanks for all your patient help. The fact that this project
has successfully reached the point of user acceptance testing owes a
lot to your generous and capable assistance.


Gratefully,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Object type puzzle

[Bob Kline]

I've made good progress on our project to port our XMetaL JScript
macros to Python (see the thread from about a month ago referring to
the project). All the macros (a couple of hundred of them) have been
rewritten in Python, and they all appear to work correctly (though
testing in earnest is still to come).

One problem we ran into was that there are a number of XMetaL API
calls which are documented to return an object of a specific type but
which actually return an interface to the base type of the documented
type. For example, the Add() method of a CommandBarControls object is
documented to return a CommandBarButton object if the parameter
specifying the control type is 1, but a CommandBarPopup if the
parameter passed is 5. However, regardless of which value that
parameter is given, what is actually returned is a CommandBarControl
object, that is, an object of the base class. Clearly that
documentation assumes that the interface navigation between base and
derived classes will be transparent to the scripting code.

Here's the mystery part. When we used the properties of the returned
object in our JScript macros, the code worked as advertised. However,
the equivalent Python code blows up, with an error claiming that we
are trying to use a property which our object does not possess. And
the error message says that our object is a CommandBarControl object,
not a CommandBarButton or CommandBarPopup object. So the mystery is:
why does the JScript code work, when Python code doing the same thing
does not?

The vendor came up with a workaround, which is for us to explicitly
cast the interface which is returned to the type we need to use
ourselves. For example, replacing

button = toolbar.Controls.Add(1)

with

control = toolbar.Controls.Add(1)
button = win32com.client.CastTo(control, "CommandBarButton")

This works. We have over a dozen places in our code where we've had to
apply this workaround. However, I would like to solve the mystery if
that's possible, because I always prefer knowing how and why the tools
we use do what they do. Cuts down on the number of unpleasant
surprises. :-}

I can think of two possible explanations.

The first would be that the vendor is detecting when the scripting
engine is JScript and is behaving differently in that case, performing
the cast and actually returning the interface to the specific derived
class instead of the interface to the base class. It's hard to imagine
what the incentive would be for the vendor to do this (have the API
behave differently depending on what the scripting engine is). Also, I
asked them point blank if that's what's going on, and they said that
it isn't.

The other, more plausible explanation would be that JScript is
navigating between the interfaces using the introspection capabilities
provided by the COM architecture. When it sees a method call or
property access on an interface for which the method or property isn't
implemented, but for which derived classes exist which do implement
it, it figures out which one supports the method or property,
effectively doing the casting for us. The weak link in this
explanation is the question: what would the scripting engine do if
more than one derived class implemented the method invoked or the
property accessed? Presumably that would trigger an exception.

Normally I would clear up such a puzzle by reading the specification
for the underlying framework. However, when I asked the vendor for the
Windows Scripting Interface specification used to expose their
scripting API, they told me that such a document doesn't exist.

Assuming the second explanation above is correct, why is the Python
scripting support not performing the interface navigation which (for
example) JScript and VBScript are doing, and which the documentation
for the XMetaL APIs appears to assume will happen? Or is there a third
explanation for the mystery which has eluded me?

Thanks,
Bob Kline
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Windows scripting can't find _ctypes

[Bob Kline]

On Mon, Dec 19, 2022 at 9:40 AM Bob Kline  wrote:
> 
> Anyone else stumbled onto this problem?

I found a solution. If I add e:\Python\DLLs to the PYTHONPATH
environment variable, Windows script is able to import the ctypes
module. I would appear that something has changed in the communication
between Python and the pywin32 package, as I didn't have to do that
previously, and I assume that the change was introduced by the CPython
team, as I'm running the same version of pywin32 (305) now as I was
before the Python upgrade.

Hope this helps someone else.

Cheers,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Windows scripting can't find _ctypes

[Bob Kline]

I just ran into a snag after upgrading to Python 3.11.1. Running
Python 3.10.1 the ctypes module imports with no problems. Same under
Windows scripting using the pywin32 package. With 3.11.1 importing
ctypes directly still works. However, under Windows scripting using
the pywin32 package "import ctypes" fails with the following error
output:

IActiveScriptError QI - unknown IID {B21FB2A1-5B8F-4963-8C21-21450F84ED7F}
E:\tmp\test2.pys(12, 0) Python ActiveX Scripting Engine: Traceback
(most recent call last):
  File 

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

We have a glimmer of hope. Just got a fresh build of xmetal.exe from the
vendor, and it's not failing in my initial tests. Much more testing to do,
but this looks very promising. I've asked them to tell me about the fix,
but they've dodged that question so far.

So let me stop here and tell you how grateful I am for your patient
assistance. And (of course) for creating this package in the first place.


Many thanks,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

On Tue, Nov 29, 2022 at 6:19 PM Mark Hammond  wrote:
>
> On 30/11/2022 3:06 am, Bob Kline wrote:
> 
>> As a side note, imp.new_module() [3] was deprecated back in Python 3.4.
>
> Yep, you are looking at a very old version.

True, but I checked HEAD for the main branch, and the code [1] is
still calling the deprecated method.

Cheers,
Bob

[1] 
https://github.com/mhammond/pywin32/blob/main/com/win32comext/axscript/client/pyscript.py#L217
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

On Tue, Nov 29, 2022 at 6:23 PM Mark Hammond  wrote:

> The close method is 

Microsoft is not helping much here. The documentation to which you
linked has no information about this method other than that it returns
a 32-bit integer for which no semantics are given, and that it lives
in the Microsoft.VisualStudio.Debugger.Interop namespace. I'm having a
little difficulty figuring out how that namespace would be appropriate
for their general scripting language interface.

> It's worth pointing out that any "obvious" bug in pywin32
> here would probably be able to be reproduced in, and
> reported by, the various other hosts, including cscript.exe
> and wscript.exe (which themselves are just active script
> hosts, just like your problematic host)

I had that thought, too. But then I realized that cscript.exe and
wscript.exe use a model of a separate process for each invocation of a
single script. That script can be very complicated, but it's loaded,
parsed, and executed once. I can run a pretty complicated Python macro
once per XMetaL session (by which I mean separate process) without any
problem. If I want to run a script twice using cscript.exe I have to
launch two separate cscript.exe processes.

It occurred to me that a better comparison might be using Internet
Explorer, which can presumably run multiple scripts multiple times in
a single process. So I grabbed form.htm from axscript/Demos/client/ie
(I promise I'm looking at the correct repository now ), thinking I'd
see if clicking the Submit button multiple times caused any problems.
Unfortunately, the scripts didn't fire at all, and the browser's
console window didn't provide any explanation as to why. (By the way,
I had to fix the third INPUT element, which was malformed, as its tag
was missing its right angle bracket delimiter. IE may have been
tolerant of that broken syntax at some time in the past, but it
doesn't accept it now.)

Cheers,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

On Tue, Nov 29, 2022 at 6:19 PM Mark Hammond  wrote:

> ... the ax object isn't going to have a Reset - so whatever that's trying to 
> do isn't getting done.

How would we go about finding out what that missing method was
supposed to do, so that we can know whether the failure to do it is
related to the problem? One of the frustrations here is that while the
documentation for the host application says "You can use any scripting
language that conforms to the Microsoft Scripting Language Interface"
trying to find the specification for that interface on Microsoft's web
site turns up nothing. Has Microsoft published the spec and then gone
to the trouble of extirpating every trace of it? Do you have a copy?

> ... Yep, you are looking at a very old version.

Sorry for the old link. Don't have any idea how I ended up in that
repository. Obviously the copy I was hacking to get my debug logging
was the real thing, installed by pip. I'm suitably embarrassed that I
didn't notice that they didn't match.

> ... when I say I'm hoping to see a stack trace, I mean a native stack trace

I'll see what I can do to produce one.

Thanks,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

One more data point. I added a bit more to my logging and learned that the
seven calls to the ScriptItem constructor each time the macro is invoked
are for the seven global objects which the host application (XMetaL) makes
available to the scripts:

 * FormDriver
 * ActiveDocument
 * Selection
 * Application
 * FormFuncs
 * ResourceManager

So at least part of that puzzle is cleared up, though it's still somewhat
unsettling that only seven calls to ScriptItem.Close() are made, regardless
of how many ScriptItem objects have been instantiated during a session.

Cheers,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

Cranking up the microscope (or spelunking deeper, whichever metaphor
you prefer), the first thing I'll say is that this code is devilishly
complex.

Here's what I've found in the latest pass.

First, there's a minor bug at line 353 of pyscript.py [1], where
globalNameSpaceModule is set to None when it's
self.globalNameSpaceModule which should be set to None. The bug is
currently innocuous, as the only invocation of the method in which
that assignment is made in this version of the code is from
PyScript.Close(), and that method makes the correct assignment:

self.globalNameSpaceModule = None

It seems to me that there's a more serious problem at line 350 of that
module [2], where that same method appears to be invoking a method
which does not exist, at least as far as I can determine (bearing in
mind that I might not completely understand all the nuances of the
tricky code here).

self.globalNameSpaceModule.ax._Reset_()

Working backward, to see if I can figure out where _Reset_ would be
defined, I found this code in the PyScript class:

def InitNew(self):
framework.COMScript.InitNew(self)
import imp
self.scriptDispatch = None
self.globalNameSpaceModule = imp.new_module("__ax_main__")
self.globalNameSpaceModule.__dict__['ax'] = AXScriptAttribute(self)


It's not completely clear how this method gets invoked (I don't see
any calls to it, but I do see that "InitNew" appears as one of the
strings in the _public_methods_ array attribute of the base class),
but I can tell from my logging that it does get called. However it
gets invoked, that means that the _Reset_() call being made above is
on an instance of the AXScriptAttribute class, which—as far as I can
tell—has no _Reset_() method (and no base class from which it could
inherit that method). This is confirmed by an exception which is
caught at shutdown time in the PyScript.ResetNamespace() method. The
handler for that exception looks like this:

except AttributeError:
pass # ???

The obvious questions would be
  * what was the non-existent method expected to do?
  * could the fact that it didn't get done be causing my problem?

The ResetNamespace method has no documentation, so all I would have
for answers to those questions would be wild guesses.

As a side note, imp.new_module() [3] was deprecated back in Python 3.4.

I'm attaching the logs I captured. One set is for a session in which
the macro was only invoked once (and therefore didn't result in any
observable failures) and the other for the session in which the macro
was invoked twice, with the symptoms described earlier in this thread.
Please let me know if anything else stands out as potentially useful
in the logs.

Cheers,
Bob

[1] 
https://github.com/SublimeText/Pywin32/blob/master/lib/x64/win32comext/axscript/client/pyscript.py#L353
[2] 
https://github.com/SublimeText/Pywin32/blob/master/lib/x64/win32comext/axscript/client/pyscript.py#L350
[3] https://docs.python.org/3/library/imp.html#imp.new_module


pyscript-logs.tar
Description: Unix tar archive
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

On Mon, Nov 28, 2022 at 7:24 PM Mark Hammond  wrote:
> ...
> The absolute best thing for us would be to reproduce the crash in the
> test code at
> https://github.com/mhammond/pywin32/tree/main/com/win32comext/axscript/test.

I presume that would depend on getting the vendor to open the kimono
and reveal which calls to the scripting engine the application is
making at what times. One handicap I'm dealing with is the fact that I
don't have a good understanding of what the "Microsoft Scripting
Language Interface" is. Searching for it in MSDN turns up only an
article ("Using COM Objects in Windows Script Host") which describes
running scripts using WScript.exe or CScript.exe. It seems unlikely
that the XMetaL application would be launching a fresh CScript.exe or
WScript.exe process every time a macro is invoked (with the massive
performance hit that would introduce), so presumably they have a copy
of this elusive interface specification which they're following to
emulate what those applications are doing.

> The next best thing would probably be a stack trace of the crash.

Any tips for how I would go about obtaining such a thing? I suppose
it's possible that the crash happens while some Python code is
running, and I'd be able to wrap that code in a try block and dump a
stack track to a file (assuming I can guess what code that would be).
But it seems at least as likely that when the crash occurs (that is,
when the dialog window appears at logoff time reporting the memory
access violation) we are no longer anywhere near any of the Python
code. Perhaps the Python code (or C code underneath it) has done
something naughty (for example, trashing a pointer somewhere) well
before the actual crash happens and it only manifests itself at logoff
time when the OS forces the application to let go and really shut
down.

Any advice you can provide to help me get a better understanding of
how the moving parts interact and what I should try next would be
immensely appreciated.

Many thanks,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

On Mon, Nov 28, 2022 at 4:12 PM Bob Kline  wrote:
> 
> Perhaps, for example, I'll be able to find something which is supposed
> to get released at application shutdown time but which isn't. 

I've added some debug logging to the top of most methods in
pyscript.py, mostly just announcing that the method was invoked. I was
a little surprised to find that for each invocation of the macro seven
instances of the ScriptItem class were created, instead of just one.
So clearly I have yet to figure out exactly what a ScriptItem is. The
really interesting thing is that if I invoke the macro once for a
given run of the host application, the ScriptItem.Close() method is
called seven times, matching the seven times the ScriptItem
constructor is hit. However, if the macro is invoked twice for a run
of the host application, I still see only seven calls to
ScriptItem.Close(), even though there are now fourteen calls to the
ScriptItem constructor. Can I assume that this is a problem? Sure
smells like one. Where does the responsibility for calling the Close()
method ultimately fall?

-- 
Bob Kline
https://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Memory access violation using pywin32 as WSH

[Bob Kline]

We've got a project we've supported for many years which involves
using XMetaL (a commercial XML editor) customized with macros written
in JScript. The vendor claims that the scripting "can use any
scripting language that conforms to the Microsoft Scripting Language
Interface." Since JScript is much more restricted in what it can do,
and since our team is much more familiar with Python than with
JScript, we would like to switch to Python for our scripts. However, a
dirt-simple proof of concept fails with a memory access violation. We
created a macro file with a single macro which displays an alert box
with a simple string. If the lang attribute for the macro element (the
macros are stored in an XML file, with the code for each macro stored
in a MACRO element) is set to "JScript" the macro can be run an
unlimited number of times without any problems. If the lang attribute
is set to "Python" (the macro is so simple that the syntax is
identical for the two languages) the macro can be run once without any
apparent problems, as long as you close the XMetaL application and
launch it again before the next run of the macro. However, if XMetaL
is launched and the macro is run twice or more before shutting down
the application, it is no longer possible to launch it again until the
user logs off the machine and logs back in. When the user logs off, a
dialog box appears reporting a memory access violation ("xmetal.exe -
Application Error. The instruction at  referenced
memory at . The memory could not be read."). To be
clear — the macro does what it's supposed to (display a dialog box
with a string) each time it is run. The problem only manifests itself
when trying to launch the application again or when logging off the
machine. Interestingly, when the application is in this "I can't be
launched again and I will report a failure at logoff time" state there
is no evidence that the process is still hanging around. It doesn't
show up in Process Manager, for example. But it seems clear from the
title bar of the error dialog that it's coming from the application.

At this point I don't know for sure whether the problem is caused by
something the XMetaL application is doing wrong (and presumably
differently than what it does when the scripting engine is JScript) or
by something that pyscript.py is doing. I am aware that I could easily
get caught between two projects, each of which claims that the failure
must be caused by the other. I have reported the problem to the XMetaL
support team and I am waiting to hear what they have to say. I'm
hoping that the data point of "one macro invocation succeeds, two
macro invocations fail" provides a useful clue.

What would be helpful from the pywin32 team's side would be any
suggestions you might have for how I might go about tracking what's
going on, presumably by hacking pyscript.py and/or framework.py in
win32comext/axscript/client to add logging to the file system.
Perhaps, for example, I'll be able to find something which is supposed
to get released at application shutdown time but which isn't. I'm
still trying to absorb the axscript/client code and wrap my head
around what the processing flow is and what the different classes are
doing.

Any clues for where to start? Anyone else run into similar memory
access violations using Python as a Windows Scripting Host?

Many thanks!

-- 
Bob Kline
https://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Bob Kline]

On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond  wrote:

> 1) There's a relatively easy fix that can be made to the copy of adodbapi
> which is inside pywin32.

Right. Basically, I think what needs to happen is for the fork on
GitHub to be brought in sync with the working code on SF. I'm going to
guess it's not quite as simple as that, because we'd want to be
careful to preserve any patches which got applied on GitHub, but
didn't make it to the original repo. Don't know for sure that there
are any, but we should check.

> 2) There's a concern regarding some IronPython bindings for adodbapi which
> aren't in pywin32 and Vernon was asking something whether they should also
> be included in pywin32.

As I understand it, the code to support IronPython is already included
in what's on GitHub. I think Vernon's hoping that there's a way to
script an export of just the adodbapi portion of your GitHub repo for
the use of the IronPython users (who, as you correctly point out, have
no use for the pywin32 bits). If that's possible (and I can't see why
it wouldn't be, as GitHub is pretty easy to script), he would be able
to avoid the tedium and risks involved in having to maintain the same
code base in two different places. It would also eliminate the "where
am I supposed to file bugs" confusion, as well as make it easier to
persuade others to assist with maintenance of the code. Most of the
adodbapi code is common for IronPython and CPython users, and I don't
see that the presence of "if IronPython: ..." code in the
mhammond/pywin32 repo does any harm (after all, it's already there and
I'll bet no one has noticed).

I hope that makes things a little clearer. But this explanation is
speculation on my part, and I should really let Vernon say what he
means for #2.

Regards,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Bob Kline]

On Sun, Feb 25, 2018 at 12:04 PM, Preston Landers <pland...@gmail.com> wrote:

> Is there [any] reason you can't use PyODBC? 

A reasonable question. This is not for a new project. When it was
first started the analysis of the available options for database
connection libraries came to the conclusion that the PyODBC wasn't
ready for prime time. At this point, while it might be possible to do
the archaeological work needed to track down the specifics behind that
decision, it would almost certainly be more profitable to do a fresh
assessment at some point based on where the package is now. I can
imagine that after all this time it's likely that many of the flaws
have been addressed. Not a trivial exercise, you understand, to do all
the testing of a large application needed to make sure nothing gets
broken with a new database layer, so not something we'd undertake
lightly. Assuming the effort to clean up the rough edges of the
ADODB-base package goes smoothly we'll probably stick with what we're
using, at least for the immediate future.

But thanks for the suggestion. You never know. :-)

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Bob Kline]

On Sun, Feb 25, 2018 at 12:31 AM, Mark Hammond
 wrote:

> I'm afraid Bob is going to get quite frustrated if he gets upset about
> responses taking more than a few days to come in.

I'm going to assume you hadn't yet read the thread leading up to
Vernon's last message. Here is some historical context which you may
be missing.

The adodbapi package exists in two places, the original on
SourceForge, and the newer fork which forms a part of your pywin32
project on GitHub (migrated from its own earlier SourceForge hosting,
where the incorporation of the adodbapi fork had already taken place).
Vernon has provided no indication that I could find in the SourceForge
project, that bug reports should now be submitted to the GitHub fork,
and in fact there are explicit instructions to file adodbapi bug
reports on SF. Nevertheless, there are bug reports that have sat for
years in the SF tracker for the project with no maintainer responses
at all (I would provide more specifics, but SourceForge is actually
down at the moment), and I recently was advised on this mailing list
that I should be filing my bug reports for the package on GitHub, not
SourceForge.

As far as I can tell, the adodbapi fork in the pywin32 GitHub
repository has been completely broken for at least four years. So it's
impossible to import the adodbapi GitHub/pywin32 fork, much less run
the unit test suite one would normally incorporate into the
preparation of a pull request. Vernon replied to the bug reporting
this breakage (https://github.com/mhammond/pywin32/issues/671) in
2014, providing the workaround of installing the original SourceForge
adodbapi, but there's been no movement on that bug since then. He has
at various times since then mentioned the difficulties he has had with
his Windows development/testing platform and said that he's been
working on getting it functional again.

Here's my take on the current situation. Vernon has acknowledged the
problems I just described, has reached out asking for assistance in
getting them solved, and is appreciative of the offer I have made to
help. He indicated that he wouldn't be able to get back to me for a
week or so because of current work and family obligations, and I
thanked him for his reply and told him I was happy to wait until he
was able to come up for air. As far as I can tell, we're on the right
path to solving the problems.

> While pywin32 has moved to
> github, I honestly don't expect the release cadence, nor the amount of time
> I can offer the project to change from what it has been over the last few
> years.

There's nothing wrong with the release cadence. I just don't want more
years to go by before the problems with the adodbapi package are
addressed. I'm trying to help Vernon achieve that goal.

> There's no need to apologize for life getting in the way of maintaining free
> and open source software.

I absolutely agree. However, taking 30 seconds to write "sorry, I'm
not going to be able to look at this until [expected re-engagement
date]" (as Vernon did in his last reply) goes a long way when you're
trying to encourage assistance from your users.

Regards,
Bob
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Parameters in adodbapi [was Re: Bug reporting]

[Bob Kline]

On Wed, Feb 21, 2018 at 7:12 PM, Bob Kline <bkl...@rksystems.com> wrote:

> The solutions (for the two bugs my patch attempted to address) which
> come immediately to mind include: 

Here's what I think I've been able to determine at this point.

1. The adodbapi package uses two approaches to the ADO Parameter
objects needed for operations with placeholders. The approach adopted
currently for stored procedure invocation tries to use the Parameter
objects created by the underlying provider, based on the definition of
the column associated with the placeholder. For operations which are
not invoking stored procedures (and for stored procedures where the
provider fails to create Parameter objects) the package creates the
Parameter objects itself, based not on the column definitions
associated with the placeholders, but instead on the values being
plugged in for those placeholders.

2. Creating Parameter objects based on the values being passed for an
operation sometimes results in failure or an incorrect result. For
example, trying to pass None in the values list for a column defined
as "NTEXT NULL" fails on SQL Server with an exception complaining
"Operand type clash: int is incompatible with ntext." For another
example, passing an empty string ("") for a VARCHAR column results in
a single blank character being stored on SQL Server.

3. Some providers do a better job than others at figuring out what the
ADO data type code should be for a given column definition. For
example, the SQLOLEDB provider, used to talk to Microsoft's SQL
Server, selects adVarBinary for a column defined as varbinary(5),
whereas the Microsoft ACE provider, connected to an Access database,
thinks the correct type is adVarWChar for the same column definition,
with the result that an incorrect value is stored. The ODBC 5.3(w)
driver for MySQL has a similar problem (worse, actually, as it
discards information).

4. Running against MS SQL Server and PostgreSQL (I've completed the
setup of my test bed for the package), all tests in the unit test
suite pass using either approach to ADO Parameter objects. Running the
suite against an Access or MySQL database, one test fails when the
package uses the Parameter objects created by the ADO layer (because
of the problem described immediately above), but passes when the
package creates its own Parameter objects. All of the other tests pass
for Access. As I reported earlier in this thread, the test of storing
a value in a 'bit' column fails when running the suite against a MySQL
database no matter which approach to Parameter objects is used.

5. These observations seem to lead to the conclusion that we need one
approach to Parameter object handling when connected to SQL Server and
a different approach when we're talking to MySQL or an Access database
(or at least when using the driver/providers with which I've been
testing). PostgreSQL is the only DBMS which appears to work correctly
with either approach.

6. The package already has an extension attribute (dbms_name) on the
connection object identifying which DBMS we're connected to. My
recommendation would be to use that information to decide which
approach to take to Parameter objects, using the existing Parameter
Objects if the DBMS name is "Microsoft SQL Server" or if (preserving
the current behavior) the operation is the invocation of a stored
procedure. If you agree, I'll come up with a new pair of pull requests
to address the two bugs describe above in paragraph #2.

7. If it is unacceptable to change the current behavior silently for
connections to SQL Server, we would need a way for the programmer to
tell the package which approach is needed for handling Parameter
objects. The simplest way would be to have a module-level variable
(similar to the dateconverter variable, which is documented as
something the user can override). However, this would be awkward for a
program which needed to communicate with two different databases.
Perhaps a connection-level extension would be more appropriate, with
an optional keyword argument passed to the connect() function.
Presumably the default should be to keep the current behavior to avoid
introducing new breakage for existing code (though I suspect most of
the use of the package is for talking to SQL Server, possibly by a
large margin).

When you come up for air, Vernon, I'll be grateful for any corrections
you can provide for any errors I've made in this analysis. One thing I
should point out is that some of what I've written here is based on
the results of the regression test suite, and I can see that there are
places where certain of those tests are altered or even suppressed at
run time depending on which engine is in play. It's conceivable that
had the package always used Parameter object created internally by ADO
(when available) that tweaking would have been done differently, and
there would be no failures or errors from the test suite for th

Re: [python-win32] Bug reporting

[Bob Kline]

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

Re: [python-win32] Bug reporting

[Bob Kline]

[ 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 
...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 <bkl...@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
>

Re: [python-win32] Bug reporting

[Bob Kline]

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 
...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@*',
, '\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 <bkl...@rksystems.com> wrote:
> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondc...@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" <bkl...@rksystems.com> wrote:
>>>
>>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondc...@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 t

Re: [python-win32] Bug reporting

[Bob Kline]

On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondc...@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" <bkl...@rksystems.com> wrote:
>>
>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondc...@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:bkl...@rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Bob Kline]

So, could someone clear up a couple of odd little puzzles for me? If
the adodbapi project has really moved to GitHub, (1) why does the
readme file for the package on GitHub still point back to the
SourceForge page, which still tells people to file bug reports there?
and (2) why is the apibase.py file (without which adodbapi can't load)
not in the GitHub repo?

Thanks,
Bob

On Sat, Feb 17, 2018 at 6:20 PM, Bob Kline <bkl...@rksystems.com> wrote:
> Thanks for the tip, Max. I added a review to the SourceForge page so I
> could help others avoid wasting time there (I didn't find any other
> clues on the page about the move), and I submitted the patch I had
> posted there as a pull request on GitHub.
>
> Cheers,
> Bob
>
> On Sat, Feb 17, 2018 at 2:29 PM, Max Slimmer <maxslim...@gmail.com> wrote:
>> Bob,
>>
>> I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
>> moved to github a little bit ago. Maybe Vernon can confirm or deny but I
>> think submitting issues there is the preferred route.
>>
>> --Max III
>>
>> On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-requ...@python.org> wrote:
>>>
>>> Send python-win32 mailing list submissions to
>>> python-win32@python.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://mail.python.org/mailman/listinfo/python-win32
>>> or, via email, send a message with subject or body 'help' to
>>> python-win32-requ...@python.org
>>>
>>> You can reach the person managing the list at
>>> python-win32-ow...@python.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of python-win32 digest..."
>>>
>>> Today's Topics:
>>>
>>>1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>>>2. Bug reports (Bob Kline)
>>>
>>>
>>> -- Forwarded message --
>>> From: "Vernon D. Cole" <vernondc...@gmail.com>
>>> To: python-win32 <python-win32@python.org>
>>> Cc:
>>> Bcc:
>>> Date: Fri, 16 Feb 2018 21:01:37 -0700
>>> Subject: [python-win32] sudo.py -- publish to pypi or gist?
>>> I finished work on a new module today -- it is called "sudo.py" and does
>>> pretty much what you would expect.
>>>
>>> If executed as a main program, on Linux or MacOS, it just runs "sudo"
>>> which is not very exciting. On Windows, it requests elevation and runs a
>>> command as an Administrator, which is a capability I have been wanting for
>>> years.
>>>
>>> Or you can call it at the beginning of a Python program like this:
>>> >>> import sudo
>>> >>> sudo.run_elevated()  # run this script as an Administrator
>>> which creates a new window (on Windows) and runs the script (from the top)
>>> with elevated privileges.
>>>
>>> Of course it requires PyWin32 to perform all this magic on Windows.
>>>
>>> I want to publish it -- but in what form?
>>> If you care, please respond to this poll.
>>> --
>>> Vernon Cole
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: Bob Kline <bkl...@rksystems.com>
>>> To: python-win32 <python-win32@python.org>
>>> Cc:
>>> Bcc:
>>> Date: Sat, 17 Feb 2018 08:16:17 -0500
>>> Subject: [python-win32] Bug reports
>>> According to SourceForge [1]:
>>>
>>> > Best Way to Get Help
>>> > Python DB-API 2.0 module for ADO says the best way to get help with its
>>> > software is by using its ticket tracker: Bugs. [2]
>>>
>>> Is this true? I posted a bug report [3] a couple of weeks ago and I
>>> still haven't seen even an acknowledgment that the report has been
>>> seen. Is there another bug tracker somewhere I should be using? Has
>>> the project silently migrated to GitHub?
>>>
>>> Thanks!
>>>
>>> [1] https://sourceforge.net/projects/adodbapi/
>>> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
>>> https://sourceforge.net/p/adodbapi/bugs/
>>> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>>>
>>> --
>>> Bob Kline
>>> http://www.rksystems.com
>>> mailto:bkl...@rksystems.com
>>>
>>>
>>> ___
>>> python-win32 mailing list
>>> python-win32@python.org
>>> https://mail.python.org/mailman/listinfo/python-win32
>>>
>>
>>
>> ___
>> python-win32 mailing list
>> python-win32@python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkl...@rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

[Bob Kline]

Thanks for the tip, Max. I added a review to the SourceForge page so I
could help others avoid wasting time there (I didn't find any other
clues on the page about the move), and I submitted the patch I had
posted there as a pull request on GitHub.

Cheers,
Bob

On Sat, Feb 17, 2018 at 2:29 PM, Max Slimmer <maxslim...@gmail.com> wrote:
> Bob,
>
> I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
> moved to github a little bit ago. Maybe Vernon can confirm or deny but I
> think submitting issues there is the preferred route.
>
> --Max III
>
> On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-requ...@python.org> wrote:
>>
>> Send python-win32 mailing list submissions to
>> python-win32@python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.python.org/mailman/listinfo/python-win32
>> or, via email, send a message with subject or body 'help' to
>> python-win32-requ...@python.org
>>
>> You can reach the person managing the list at
>> python-win32-ow...@python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of python-win32 digest..."
>>
>> Today's Topics:
>>
>>1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>>2. Bug reports (Bob Kline)
>>
>>
>> -- Forwarded message --
>> From: "Vernon D. Cole" <vernondc...@gmail.com>
>> To: python-win32 <python-win32@python.org>
>> Cc:
>> Bcc:
>> Date: Fri, 16 Feb 2018 21:01:37 -0700
>> Subject: [python-win32] sudo.py -- publish to pypi or gist?
>> I finished work on a new module today -- it is called "sudo.py" and does
>> pretty much what you would expect.
>>
>> If executed as a main program, on Linux or MacOS, it just runs "sudo"
>> which is not very exciting. On Windows, it requests elevation and runs a
>> command as an Administrator, which is a capability I have been wanting for
>> years.
>>
>> Or you can call it at the beginning of a Python program like this:
>> >>> import sudo
>> >>> sudo.run_elevated()  # run this script as an Administrator
>> which creates a new window (on Windows) and runs the script (from the top)
>> with elevated privileges.
>>
>> Of course it requires PyWin32 to perform all this magic on Windows.
>>
>> I want to publish it -- but in what form?
>> If you care, please respond to this poll.
>> --
>> Vernon Cole
>>
>>
>>
>> -- Forwarded message --
>> From: Bob Kline <bkl...@rksystems.com>
>> To: python-win32 <python-win32@python.org>
>> Cc:
>> Bcc:
>> Date: Sat, 17 Feb 2018 08:16:17 -0500
>> Subject: [python-win32] Bug reports
>> According to SourceForge [1]:
>>
>> > Best Way to Get Help
>> > Python DB-API 2.0 module for ADO says the best way to get help with its
>> > software is by using its ticket tracker: Bugs. [2]
>>
>> Is this true? I posted a bug report [3] a couple of weeks ago and I
>> still haven't seen even an acknowledgment that the report has been
>> seen. Is there another bug tracker somewhere I should be using? Has
>> the project silently migrated to GitHub?
>>
>> Thanks!
>>
>> [1] https://sourceforge.net/projects/adodbapi/
>> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
>> https://sourceforge.net/p/adodbapi/bugs/
>> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>>
>> --
>> Bob Kline
>> http://www.rksystems.com
>> mailto:bkl...@rksystems.com
>>
>>
>> ___
>> python-win32 mailing list
>> python-win32@python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
> ___
> python-win32 mailing list
> python-win32@python.org
> https://mail.python.org/mailman/listinfo/python-win32
>



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Bug reports

[Bob Kline]

According to SourceForge [1]:

> Best Way to Get Help
> Python DB-API 2.0 module for ADO says the best way to get help with its 
> software is by using its ticket tracker: Bugs. [2]

Is this true? I posted a bug report [3] a couple of weeks ago and I
still haven't seen even an acknowledgment that the report has been
seen. Is there another bug tracker somewhere I should be using? Has
the project silently migrated to GitHub?

Thanks!

[1] https://sourceforge.net/projects/adodbapi/
[2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
https://sourceforge.net/p/adodbapi/bugs/
[3] https://sourceforge.net/p/adodbapi/bugs/27/

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

[Bob Kline]

On Mon, Nov 6, 2017 at 5:47 PM, Max Slimmer <maxslim...@gmail.com> wrote:

> If you don’t mind losing some precision you can do something like this:
> ... [code to override dateconverter] ...

That would address the first bug, at least for my own immediate
application. It would take more digging to determine how generally
applicable it would be for a patch to the package.

> Or maybe you can use datetime2.

Another possible solution, sidestepping the first bug altogether.

Thanks for your helpful suggestions. I'll need to scratch my head
further to see if I can solve the second problem (loss of precision
when running under Python 3). If I can't, I may take a different route
altogether, letting the application server decide what time it is
instead of the database server. In this approach, I would just create
a variable in Python to represent the current date/time with
sub-second precision stripped (or rounded away) and store that value.
That way, at the cost of some precision, I'll be able to guarantee
that Python 2 and Python 3 code (any code, really) will get the same
value from the database. In this particular instance, the consistency
is worth more than the precision.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

[Bob Kline]

On Tue, Nov 7, 2017 at 10:11 AM, Vernon D. Cole <vernondc...@gmail.com> wrote:

> Obviously Bob has found a where a value an internal form blows up when fed
> directly back into an INSERT. I suspect that if his row.date value was run
> through a real datetime object that things would magically work differently.

I'm not sure what that means. The value I get back from adodbapi from my SELECT
query *is* a Python datetime object:

>>> row = cursor.fetchone()
>>> type(row[0])


What would be the difference between that and a "real datetime object"?

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

[Bob Kline]

On Tue, Nov 7, 2017 at 10:49 AM, Dennis Lee Bieber
<wlfr...@ix.netcom.com> wrote:

> >> When running under Python 2.7.13, the first print statement shows that
> >> the datetime value has been correctly retrieved, preserving the
> >> precision:
> >>
> >> d=2017-11-04 07:52:18.11
> >>
> Given that string of 0s, the only thing I'd be able to conclude from
> the above is that the /formatting/ of the output specified a high
> precision, which may not be in the data itself.

The adodbapi package returns standard Python library datetime objects
for non-NULL values retrieved from SQL Server DATETIME columns, so
that's what row.d is. The fact that the printed representation of the
value has trailing zeros reflects the default formatting for datetime
objects.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

[Bob Kline]

On Mon, Nov 6, 2017 at 10:07 AM, Vernon D. Cole <vernondc...@gmail.com> wrote:

> [Sorry everyone. My kitten stepped on the keyboard and sent out a one-letter
> reply.]

Always good to have helpful assistants. :-)

> Yes, patches are accepted and welcome.  My last remaining Windows
> development environment (I work mostly on Ubuntu these years) died several
> months ago leaving me high and dry to do maintenance.  I have purchased its
> replacement and promise to get back to work.  An assistant administrator for
> adodbapi would be welcome, too.  I am 67 and will not last forever.
> I also have a plan for a MSSQL Server test bed to be available for
> volunteers to use for testing.

I'm happy to contribute what I can, but you're younger than I am. :-)

>   What SQL engine and version are you running?

I have reproduced this with several SQL Server versions. For example:

 * Microsoft SQL Server 2017 (RC2) - 14.0.900.75 (X64) Jul 27 2017
08:53:49 Developer Edition on Linux (Ubuntu 17.04)
 * Microsoft SQL Server 2008 R2 (SP3) - 10.50.6220.0 (X64) Mar 19 2015
12:32:14 Enterprise Edition on Windows NT 6.1 SP1
 * Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) Oct
28 2016 18:17:30 Developer Edition on Windows Server 2012 R2

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] datetime values in adodbapi

[Bob Kline]

On Mon, Nov 6, 2017 at 9:59 AM, Vernon D. Cole <vernondc...@gmail.com> wrote:

> On Sat, Nov 4, 2017 at 6:27 AM, Bob Kline <bkl...@rksystems.com> wrote:
>>
>> The adodbapi package does not seem to handle datetime values 
>
> Y

You hit the Send button too soon, right?

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] datetime values in adodbapi

[Bob Kline]

The adodbapi package does not seem to handle datetime values appropriately.

import adodbapi
print(adodbapi.version)
cursor = adodbapi.connect(...)
cursor.execute("CREATE TABLE #t (i INT, d DATETIME)")
cursor.execute("INSERT INTO #t VALUES (42, GETDATE())")
cursor.execute("SELECT * FROM #t")
row = cursor.fetchone()
print("d={}".format(row.d))
cursor.execute("INSERT INTO #t VALUES (?, ?)", (43, row.d))
cursor.execute("SELECT * FROM #t WHERE i = 43")
row = cursor.fetchone()
print("d={}".format(row.d))

When running under Python 2.7.13, the first print statement shows that
the datetime value has been correctly retrieved, preserving the
precision:

d=2017-11-04 07:52:18.11

but then when the second INSERT is executed an exception is raised:

pywintypes.com_error: (-2147352567, 'Exception occurred.', (0,
u'ADODB.Parameter', u'Application uses a value of the wrong type for
the current operation.', u'C:\\WINDOWS\\HELP\\ADO270.CHM', 1240652,
-2146824867), None)

So the package isn't allowing the script to use the same value it was
given as a valid value for the d column by the package itself.

When the script is run under Python 3.6.0, the exception is not
raised, but that's only because the datetime precision has been
discarded:

d=2017-11-04 08:15:37
d=2017-11-04 08:15:37

I get the same behavior with adodbapi 2.6.0.6 (which I downloaded from
the link which indicated (http://adodbapi.sourceforge.net/index.html)
that this is the latest version) and on 2.6.0.7, which is what pip
installed.

I would like to help get both of these behaviors corrected (failure to
store datetime values with microsecond precision in Python 2.x, as
well as failure to preserve sub-second precision in retrieved values
in Python 3.x). Before I dig in to do the work, though, I want to
check in here to make sure patches are accepted so I don't spend time
on something that's not wanted.

Thanks!

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32