python-sybase-misc

Re: [python-sybase] Bug tracking is where

[Greg W. <gwa...@py...>]

On 10 August 2006, Clinton James said:
> I have a patch for 64 bit machines.  Where is bug tracking? I can't seem 
> to find it.

Seems to be right here on this list.  Post your patch if it's not too
big.

        Greg

[python-sybase] Bug tracking is where

[Clinton J. <cj...@ca...>]

I have a patch for 64 bit machines.  Where is bug tracking? I can't seem 
to find it.

Re: [python-sybase] passing a date as a parameter in a select query

[Python <py...@ve...>]

On Fri, 2006-08-04 at 09:41 +0200, Marcos Sánchez Provencio wrote:
> Not a solution, but it might help.
This is a good enough solution for me.  I can deal with some funny
string formatting.

> MS SQL seems to understand {d'2006-08-03'} as a correct date value.
> 
> El jue, 03-08-2006 a las 20:14 -0400, Python escribió:
> > 2006-08-03
> 
-- 
Lloyd Kvam
Venix Corp

Re: [python-sybase] passing a date as a parameter in a select query

[Marcos P. <ma...@bu...>]

Not a solution, but it might help.
MS SQL seems to understand {d'2006-08-03'} as a correct date value.

El jue, 03-08-2006 a las 20:14 -0400, Python escribió:
> 2006-08-03

[python-sybase] passing a date as a parameter in a select query

[Python <py...@ve...>]

I am running Linux with freetds and connecting to a MS SQL server.  I'd
like to select records newer than a specified datetime value, but have
been unsuccessful.

>>> td = DT.today()
(imported mx.DateTime as DT)

>>> nsql.execute("select * from IMAGES where updated > @latest", {'@latest': td})
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/lkvam/load.py", line 68, in execute
    curs.execute(cmd, parms)
  File "/usr/lib/python2.3/site-packages/Sybase.py", line 759, in
execute
    buf = DataBuf(value)
TypeError: unsupported parameter type
>>> td
<DateTime object for '2006-08-03 00:00:00.00' at b7ccc0c8>

The Sybase module is importing mx.DateTime
>>> ln.Sybase.use_datetime
1
>>> ln.Sybase.DateTime
<module 'mx.DateTime' from '/usr/lib/python2.3/site-packages/mx/DateTime/__init__.pyc'>

I looked at the C code to try to get a handle on DataBuf, but did not
figure it out.

I also tried to simply specify the date as a string in the SELECT query,
but could not figure out a pattern that worked (I mostly use MySQL).  

Any help would be greatly appreciated.

-- 
Lloyd Kvam
Venix Corp

Re: [python-sybase] Small patch: factor out Cursor._checkready()

[Andrew M. <an...@ob...>]

>Here's a small patch that I posted a few weeks ago.  I think it got lost
>in the shuffle, since I never saw a response to my post.  It's a pure
>refactoring: should have absolutely no effect on behaviour.  I've been
>using it on my test server for several weeks now and it seems fine.
>
>Andrew or Dave, can you give thumbs up or thumbs down on this one?

Sorry - Yes, I saw it. I was hoping to get sybase installed and working
so I could at least give things a cursory test, but I've not had time.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

[python-sybase] Small patch: factor out Cursor._checkready()

[Greg W. <gwa...@py...>]

Here's a small patch that I posted a few weeks ago.  I think it got lost
in the shuffle, since I never saw a response to my post.  It's a pure
refactoring: should have absolutely no effect on behaviour.  I've been
using it on my test server for several weeks now and it seems fine.

Andrew or Dave, can you give thumbs up or thumbs down on this one?

        Greg

Re: [python-sybase] How to deal with DatabaseError

[Andrew M. <an...@ob...>]

>What, in every script or module that does database interaction?  No thanks.
>And what about the mythical script that migrates data from Sybase to
>Postgres using both drivers?

Well, if you have a large system composed of many modules, it doesn't seem
like much of an additional impost to put the "import...as" stuff in a
module (I've found that I invariably end up with a module that wraps the
dbapi to some degree other anyway).

If you're mixing adapters, sure, it's somewhat more painful. I guess you
could use something like:

    try:
        ... logic ..
    except (sybase.DatabaseError, PgSQL.DatabaseError), e:
        ... error logic...

If you have a common module, you can put that tuple in it, eg:

    DatabaseError = sybase.DatabaseError, PgSQL.DatabaseError

and then just catch with the tuple:

    try:
        ... logic ..
    except DatabaseError, e:
        ... error logic...

>        All exception classes defined by the DB API standard should be
>        exposed on the Connection objects as attributes (in addition
>        to being available at module scope).
[...]
>Obviously this is no good unless all drivers that you want to use support
>it.  I'll go see if I can whip up a patch for python-sybase.  In the worst
>case, I could monkey-patch those attributes in to every Connection in my
>abstraction layer.  (Blech.)

I must admit, I've never noticed that in the DBAPI spec, and a quick
survey suggests support for it is the exception rather than the rule.
It also doesn't help your second case above.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] How to deal with DatabaseError

[Greg W. <gwa...@py...>]

On 19 July 2006, I said:
> Obviously this is no good unless all drivers that you want to use support
> it.  I'll go see if I can whip up a patch for python-sybase.  In the worst
> case, I could monkey-patch those attributes in to every Connection in my
> abstraction layer.  (Blech.)

Patch attached.

        Greg

Re: [python-sybase] How to deal with DatabaseError

[Greg W. <gwa...@py...>]

On 20 July 2006, Andrew McNamara said:
> >Am I the only one who thinks that there's an ugly flaw in the Python
> >Database API [...]
> 
> Only one? 8-)

No comment.  (This is the ugly flaw that's annoying me today.)

> I've seen people use things like:
> 
>     if ...:
>         from pyPgSQL import PgSQL as dbapi2
>     elif ...:
>         import psycopg2 as dbapi2
>     elif ...:
>         import sybase as dbapi2

What, in every script or module that does database interaction?  No thanks.
And what about the mythical script that migrates data from Sybase to
Postgres using both drivers?

BTW, PEP 249 (DB-API 2.0) has this under "Optional DB API Extensions":

    Connection Attributes .Error, .ProgrammingError, etc.

        All exception classes defined by the DB API standard should be
        exposed on the Connection objects as attributes (in addition
        to being available at module scope).

        These attributes simplify error handling in multi-connection
        environments.

        Warning Message: "DB-API extension connection.<exception> used"

Obviously this is no good unless all drivers that you want to use support
it.  I'll go see if I can whip up a patch for python-sybase.  In the worst
case, I could monkey-patch those attributes in to every Connection in my
abstraction layer.  (Blech.)

        Greg

Re: [python-sybase] How to deal with DatabaseError

[Andrew M. <an...@ob...>]

>Am I the only one who thinks that there's an ugly flaw in the Python
>Database API [...]

Only one? 8-)

>Are there other techniques for dealing with this flaw that I haven't
>thought of?

I've seen people use things like:

    if ...:
        from pyPgSQL import PgSQL as dbapi2
    elif ...:
        import psycopg2 as dbapi2
    elif ...:
        import sybase as dbapi2

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

[python-sybase] How to deal with DatabaseError

[Greg W. <gwa...@py...>]

Am I the only one who thinks that there's an ugly flaw in the Python
Database API and it's called DatabaseError?  The fact that every driver
module has to implement and export its own DatabaseError, with no
commonality between the different modules, makes life unnecessarily
difficult.  (We're planning on migrating away from Sybase 11 to something
else, quite possibly Postgres, over the next year or so ... so I cannot
afford to write piles of code that catch Sybase.DatabaseError.)

I can only see two ways to workaround this flaw:

  * write a layer that wraps the DB-API and provides its own
    DatabaseError class, which is just an alias for (e.g.)
    Sybase.DatabaseError.  My abstraction layer (so far) is a
    ConnectionFactory class, but I suspect I'll need to add more classes
    than that.  Right now, I'm starting to write code like this:

      factory = getConnectionFactory(...)
      conn = factory.connect(...)

      try:
         # do stuff with conn
      catch factory.getDatabaseError(), err:
         # handle the error

    (Hmmm: I'm also writing something to wrap the connection; maybe that's
    where the DatabaseError class should be available).

  * write a layer that wraps the DB-API and translates every (e.g.)
    Sybase.DatabaseError to its own DatabaseError.  This will make more
    sense to the Java-heads around here, but it also means that *every*
    database operation will have to go through the abstraction/translation
    layer.  Yuck.

Are there other techniques for dealing with this flaw that I haven't
thought of?

        Greg

Re: [python-sybase] On the subject of patches

[Greg W. <gwa...@py...>]

On 07 July 2006, Harri Pasanen said:
> I've done a small patch to use the built-in datetime type for python 
> 2.x, x >= 3, which I find useful.  (I'm only reading datetime 
> objects, not writing them, not sure if the sybase module would 
> support writing them anyway, except as strings?)

If you post your patch here, I can test with an old Sybase (11.0.3).

        Greg

Re: [python-sybase] Re: This routine cannot be called because another command structure has results pending

[Andrew M. <an...@ob...>]

>I tried the "_close_fetcher" solution, but it has caused other problems.
>Specifically, it throws off the lock count and I end up getting:
>
>     AssertionError: release() of un-acquire()d lock

Ah, that's a shame. So much for the change being simple and obviously
correct!

>What has been working for me is simply clearing the command once the lock
>count reaches zero.  Here is what my version of _FetchLazy._unlock looks like:
>
>     def _unlock(self):
>         self._lock_count = self._lock_count - 1
>         _ctx.debug_msg('_unlock: count -> %d\n' % self._lock_count)
>         #!!! Added by DRC: Once there are no more locks, clear the command
>         if self._lock_count == 0:
>             status = self._cmd.ct_cancel(CS_CANCEL_ALL)
>         #!!!
>         self._owner._unlock()

Well, that looks good, but I've said that before... 8-)

Greg?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

[python-sybase] Re: This routine cannot be called because another command structure has results pending

[Don C. <ch...@st...>]

I tried the "_close_fetcher" solution, but it has caused other problems.
Specifically, it throws off the lock count and I end up getting:

     AssertionError: release() of un-acquire()d lock

What has been working for me is simply clearing the command once the lock
count reaches zero.  Here is what my version of _FetchLazy._unlock looks like:

     def _unlock(self):
         self._lock_count = self._lock_count - 1
         _ctx.debug_msg('_unlock: count -> %d\n' % self._lock_count)
         #!!! Added by DRC: Once there are no more locks, clear the command
         if self._lock_count == 0:
             status = self._cmd.ct_cancel(CS_CANCEL_ALL)
         #!!!
         self._owner._unlock()

-- 
+++++++++++++++++++++++++++++++++
Don Chance
Computer Sciences Corp.
Space Telescope Science Institute
3700 San Martin Drive
Baltimore, MD 21218
410-338-4941
+++++++++++++++++++++++++++++++++

Re: [python-sybase] On the subject of patches

[Andrew M. <an...@ob...>]

>I've done a small patch to use the built-in datetime type for python 
>2.x, x >= 3, which I find useful.  (I'm only reading datetime 
>objects, not writing them, not sure if the sybase module would 
>support writing them anyway, except as strings?)

I don't imagine the situation would be any different to the mx.DateTime
types - how are they written (I've had a quick look at the source, and
there doesn't appear to be any special support, so I presume you convert
them to strings first)?

>I've actually been using the Sybase module against Sybase 12.0 and 
>12.5.x databases, on linux, windows, Solaris, hpux 11.11 (pa-risc).   
>Not very heavily and not all of it, but still a fair amount.
>
>I've noticed that the code is not 64 bit clean, on Mandriva 2006 
>64 bit it does not compile/work correctly.  Solaris 64 bit 
>is the same or similar, does not work  Is there a patch for that, or 
>should I roll my sleeves?

If you have experience doing that sort of thing, any patches you supply
would be valuable. 

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] Migrating from Java to Python

[Andrew M. <an...@ob...>]

>See, these Java freaks gave me this JDBC URL:
>
>		jdbc:sybase::Tds:espresso.my.org:4100/beandb
>
>How in the heck do you map that to arguments in Sybase.connect()?

I think that's actually a DSN (distinguished service name), rather than a
URL. Same idea, just a different format. The first 4 fields appear to be
specific to JDBC. That leaves:

    hostname: espresso.my.org (the database server)
    server port: 4100
    database name: beandb

One of the old hands will have to tell you how to get python-sybase to
connect to anything other than localhost (the doco doesn't tell me!)

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] Patches and maintenance (was Re: This routine cannot be called because another command structure has results pending)

[<sk...@po...>]

    Greg> I'm willing to test out patches posted to this list.  I only have
    Greg> access to a 6-year old version of Sybase (11.0.3) though.  I
    Greg> suppose that's useful for testing compatibility with old versions.

Me too, though I have Sybase 12.5.something at work.

Skip

[python-sybase] Re: Migrating from Java to Python

[Sean K. <ke...@se...>]

>
> 		jdbc:sybase::Tds:espresso.my.org:4100/beandb
>
> How in the heck do you map that to arguments in Sybase.connect()?

Forgive the follow-up to my own posting, but I've just discovered the  
dsedit program and its ability to  create the missing "interfaces"  
file.  All is happy now.

Best wishes,
Sean.

[python-sybase] On the subject of patches

[Harri P. <har...@tr...>]

I've done a small patch to use the built-in datetime type for python 
2.x, x >= 3, which I find useful.  (I'm only reading datetime 
objects, not writing them, not sure if the sybase module would 
support writing them anyway, except as strings?)

I've actually been using the Sybase module against Sybase 12.0 and 
12.5.x databases, on linux, windows, Solaris, hpux 11.11 (pa-risc).   
Not very heavily and not all of it, but still a fair amount.

I've noticed that the code is not 64 bit clean, on Mandriva 2006 
64 bit it does not compile/work correctly.  Solaris 64 bit 
is the same or similar, does not work  Is there a patch for that, or 
should I roll my sleeves?


-Harri


Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Trema does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Trema does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of Trema are neither given nor endorsed by the company or its directors. A list of Trema's directors is available on our web site: www.trema.com

[python-sybase] Migrating from Java to Python

[Sean K. <ke...@se...>]

Folks:

I've got to write a Python client application running on Linux that  
gets data from a Sybase database maintained by a bunch of Java  
freaks.  I know little about Sybase but (miraculously?) got the  
Developer Edition of ASE15 installed as well as the Python Sybase  
0.34 module installed.

Now I'm stuck.

See, these Java freaks gave me this JDBC URL:

		jdbc:sybase::Tds:espresso.my.org:4100/beandb

How in the heck do you map that to arguments in Sybase.connect()?

Thanks,
Sean.

[python-sybase] Patches and maintenance (was Re: This routine cannot be called because another command structure has results pending)

[Greg W. <gwa...@py...>]

On 07 July 2006, Andrew McNamara said:
> If someone is offering to put pre-release code through it's paces,
> we can do that without SF (yeah, it's a pretty clunky way of doing it,
> but we all did somehow get by before the SF, and even IP connectivity 8-)

I'm willing to test out patches posted to this list.  I only have access
to a 6-year old version of Sybase (11.0.3) though.  I suppose that's
useful for testing compatibility with old versions.

> Obviously Greg's patch should go in - are there any other patches vs
> 0.37 that should be applied? I'll put together a devel snapshot for you
> to download and test, and if all goes well, we'll call that 0.38.

I noticed some copy 'n pasted code, which always rubs me the wrong way;
here's a patch to correct it.  It's running fine on my development
server right now.

        Greg

P.S. patch is relative to my '_close_fetcher()' patch.

P.P.S. I just realized that perhaps I should have called it
'_closefetcher()' for consistency with the rest of the code.  Andrew,
please rename it if you feel that's the right thing to do.  Stylistic
consistency is more important than worrying about hurting some
contributor's feelings!

Re: [python-sybase] Re: This routine cannot be called because another command structure has results pending

[Andrew M. <an...@ob...>]

>    Greg> Agreed.  In my experience, checking in patches is the least
>    Greg> time-consuming part of maintaining a stable project.  Merely
>    Greg> opening checkins to more developers won't help much.
>
>OTOH, if the Object Craft folks don't have Sybase available to test against,
>perhaps moving to SF would prompt someone with Sybase access to take over
>much of the vetting process.

If someone is offering to put pre-release code through it's paces,
we can do that without SF (yeah, it's a pretty clunky way of doing it,
but we all did somehow get by before the SF, and even IP connectivity 8-)

Obviously Greg's patch should go in - are there any other patches vs
0.37 that should be applied? I'll put together a devel snapshot for you
to download and test, and if all goes well, we'll call that 0.38.

In some ways, this situation is no worse than the linux kernel -
multiple repositories, patches being mailed around and being applied
without testing (since Andrew Morton and Linus can only ever have a
small subset of the hardware available). But if I can find time, I'll
have another go at installing Sybase.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] Re: This routine cannot be called because another command structure has results pending

[<sk...@po...>]

    >> That raises the question - should the project be moved to
    >> Sourceforge? I'm not convinced the move would solve anything:

    Greg> Agreed.  In my experience, checking in patches is the least
    Greg> time-consuming part of maintaining a stable project.  Merely
    Greg> opening checkins to more developers won't help much.

OTOH, if the Object Craft folks don't have Sybase available to test against,
perhaps moving to SF would prompt someone with Sybase access to take over
much of the vetting process.

Skip

Re: [python-sybase] Re: This routine cannot be called because another command structure has results pending

[Greg W. <gwa...@py...>]

On 06 July 2006, Andrew McNamara said:
> Dave's tied up with other stuff at the moment, but I've run this by him,
> and he says your patch looks good.

Yeah, I know how it goes.  Nice, stable codebase that's been humming
along just fine for years and some yahoo finds a bug.  The longer since
the last release, the harder it is to find time for the next one.

> As to whether it make it into a future release, I can certainly apply
> it to the repository, but neither Dave nor I have a Sybase installation
> to test it against at the moment (and neither of us can really spare
> the time).

Knowing that it's checked in is good enough for me.  Would be nice to
see a 0.38 release someday, but I've no objection if it waits until you
guys are good and ready.

> That raises the question - should the project be moved to Sourceforge? I'm
> not convinced the move would solve anything:

Agreed.  In my experience, checking in patches is the least
time-consuming part of maintaining a stable project.  Merely opening
checkins to more developers won't help much.

        Greg