python-sybase-misc

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[hopfgartner <hop...@ro...>]

On Tue, 10 Sep 2002 10:46:22 +0200
 Harri Pasanen <har...@tr...> wrote:
> 
> I saw exactly the same thing.   If you feel adventurous
> you can apply the 
> quick and dirty patch I have attached to effectively
> remove the threading 
> support which I suspect you are not using anyway.
> 
> Note that the patch is in no way cleaned to be final, it
> just works for me.
> 
> Just copy the Sybase.py from
> /usr/lib/python2.2/site-packages/Sybase.py
> to your test script directory, and run:
> 
> patch < Sybase.py.test-patch
> 
> Then your script has a chance of passing this hurdle...
> 
> -Harri

The message changed, the result is the same:

Traceback (most recent call last):
  File "sqlDumpTbl.py", line 143, in ?
    dump.dump()
  File "sqlDump.py", line 64, in dump
    obj_text = self.get_obj_definition(sp[0])
  File "sqlDumpTbl.py", line 31, in get_obj_definition
    self.sql_cursor.execute('SELECT name FROM sysobjects
WHERE id = ' +
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
323, in execute
    self.nextset()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
422, in nextset
    self._raise_error(Error, 'ct_cancel')
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
259, in _raise_error
    raise exc(text)
Sybase.Error: ct_cancel

The strange thing is, that the first query has alredy
succeded at this point. The failure happens always at the
second query.

Peter

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

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

On Tuesday 10 September 2002 10:18, hopfgartner wrote:
>
> Here we go:
>
> Traceback (most recent call last):
>   File "sqlDumpTbl.py", line 143, in ?
>     dump.dump()
>   File "sqlDump.py", line 64, in dump
>     obj_text =3D self.get_obj_definition(sp[0])
>   File "sqlDumpTbl.py", line 31, in get_obj_definition
>     self.sql_cursor.execute('SELECT name FROM sysobjects
> WHERE id =3D ' +
>   File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 346, in execute
>     self._unlock()
>   File "/usr/lib/python2.1/site-packages/Sybase.py", line
> 259, in _unlock
>     self._owner._lock.release()
>   File "/usr/lib/python2.1/threading.py", line 101, in
> release
>     assert self.__owner is me, "release() of un-acquire()d
> lock"
> AssertionError: release() of un-acquire()d lock
>

I saw exactly the same thing.   If you feel adventurous you can apply the=
=20
quick and dirty patch I have attached to effectively remove the threading=
=20
support which I suspect you are not using anyway.

Note that the patch is in no way cleaned to be final, it just works for m=
e.

Just copy the Sybase.py from /usr/lib/python2.2/site-packages/Sybase.py
to your test script directory, and run:

patch < Sybase.py.test-patch

Then your script has a chance of passing this hurdle...

-Harri

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[hopfgartner <hop...@ro...>]

> 
> Kevin> All I can suggest is that you use the _very_
> lastest FreeTDS
> Kevin> library.  The last released version had some
> rather nasty bugs
> Kevin> in it.
> 

Ok, I've got the cvs-sources, build them, rebuild the
sybase-python package and run my scripts again.

> >> As soon as I have again the chance to connect to the
> SQL Server
> >> (it's at a customers place) I will paste you the exact
> message
> >> (something about threads and relesing a lock that has
> not been
> >> set).

Here we go:

Traceback (most recent call last):
  File "sqlDumpTbl.py", line 143, in ?
    dump.dump()
  File "sqlDump.py", line 64, in dump
    obj_text = self.get_obj_definition(sp[0])
  File "sqlDumpTbl.py", line 31, in get_obj_definition
    self.sql_cursor.execute('SELECT name FROM sysobjects
WHERE id = ' +
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
346, in execute
    self._unlock()
  File "/usr/lib/python2.1/site-packages/Sybase.py", line
259, in _unlock
    self._owner._lock.release()
  File "/usr/lib/python2.1/threading.py", line 101, in
release
    assert self.__owner is me, "release() of un-acquire()d
lock"
AssertionError: release() of un-acquire()d lock


> 
> Kevin> Ah!  I've run into this myself.  I'll dig up my
> patches that
> Kevin> re-work the Sybase module locking code that fixes
> it (though
> Kevin> I'm not sure if I'm just working around errors in
> the FreeTDS
> Kevin> LibCT implementation or unsafe assumptions that
> David Cole made
> Kevin> about Sybase's implementation).
> 
> I am very keen to get the module working with FreeTDS.  I
> think the
> future of the module is largely tied to the success of
> FreeTDS.
> 
> - Dave

I agree perfectly with you. Let me know if I can help.

> 
> -- 
> http://www.object-craft.com.au
> 
> _______________________________________________
> Python-sybase mailing list
> Pyt...@ob...
>
https://object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase

Peter

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

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

On Tuesday 10 September 2002 02:31, Dave Cole wrote:
> >>>>> "Kevin" =3D=3D Kevin Jacobs <ja...@pe...> wri=
tes:
>
> Kevin> On 9 Sep 2002, Peter Hopfgartner wrote:
> >> I'm trying to use the Sybase module from a Debian Linux 3.0 system
> >> (Python 2.1.3, FreeTDS 0.53).
> >>
> >> I've set up some Python code in order to create ASCII file
> >> containing the database scheme, functions and stored
> >> procedures. The code runs fine when connecting through ODBC from a
> >> Windows computer. It crashes when connecting from the Linux client,
> >> as soon as the 2nd query is run.
> >>
> >> Has there already been some work done on it, both from the FreeTDS
> >> side (version 0.60rc1 came out these days, should I install it?)
> >> and the Sybase module side. Can I help in debugging the problem?
>
> Kevin> All I can suggest is that you use the _very_ lastest FreeTDS
> Kevin> library.  The last released version had some rather nasty bugs
> Kevin> in it.
>
> >> As soon as I have again the chance to connect to the SQL Server
> >> (it's at a customers place) I will paste you the exact message
> >> (something about threads and relesing a lock that has not been
> >> set).
>
> Kevin> Ah!  I've run into this myself.  I'll dig up my patches that
> Kevin> re-work the Sybase module locking code that fixes it (though
> Kevin> I'm not sure if I'm just working around errors in the FreeTDS
> Kevin> LibCT implementation or unsafe assumptions that David Cole made
> Kevin> about Sybase's implementation).
>
> I am very keen to get the module working with FreeTDS.  I think the
> future of the module is largely tied to the success of FreeTDS.
>

I also played with the Sybase module + FreeTDS combo, using FreeTDS curre=
nt=20
snapshot.

I ran into some problems where the equivalent code that ran against a Syb=
ase=20
db would halt with some error message when running against MS-SQL server.=
 =20
Some things I was able to sort out just by closing and reallocating a  cu=
rsor=20
prior to continuing.  Note that I've had similar problems with Sybase mod=
ule=20
against Sybase DB, where I need to read all the result sets from a cursor=
=20
before I can successfully run a stored procedure.

With Sybase+FreeTDS I then had the next problem with some threading asser=
ts=20
failing.   As I'm not using threads in my script, I boldly removed all=20
threading and locking support from Sybase.py, and everything I was doing=20
starting working.  Now the only remaining problem I have is that some sto=
red=20
procedure calls are segfaulting.

I heard a rumour the FreeTDS does not have support for on the wire proced=
ure=20
calls / parameter binding.  If that is true, so it may not be at the leve=
l=20
off Sybase libs for some time.



-Harri

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[Dave C. <dj...@ob...>]

>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes:

Kevin> On 9 Sep 2002, Peter Hopfgartner wrote:
>> I'm trying to use the Sybase module from a Debian Linux 3.0 system
>> (Python 2.1.3, FreeTDS 0.53).
>> 
>> I've set up some Python code in order to create ASCII file
>> containing the database scheme, functions and stored
>> procedures. The code runs fine when connecting through ODBC from a
>> Windows computer. It crashes when connecting from the Linux client,
>> as soon as the 2nd query is run.
>> 
>> Has there already been some work done on it, both from the FreeTDS
>> side (version 0.60rc1 came out these days, should I install it?)
>> and the Sybase module side. Can I help in debugging the problem?

Kevin> All I can suggest is that you use the _very_ lastest FreeTDS
Kevin> library.  The last released version had some rather nasty bugs
Kevin> in it.

>> As soon as I have again the chance to connect to the SQL Server
>> (it's at a customers place) I will paste you the exact message
>> (something about threads and relesing a lock that has not been
>> set).

Kevin> Ah!  I've run into this myself.  I'll dig up my patches that
Kevin> re-work the Sybase module locking code that fixes it (though
Kevin> I'm not sure if I'm just working around errors in the FreeTDS
Kevin> LibCT implementation or unsafe assumptions that David Cole made
Kevin> about Sybase's implementation).

I am very keen to get the module working with FreeTDS.  I think the
future of the module is largely tied to the success of FreeTDS.

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] Segentation faults when connecting to SQL Server 2000

[Kevin J. <ja...@pe...>]

On 9 Sep 2002, Peter Hopfgartner wrote:
> I'm trying to use the Sybase module from a Debian Linux 3.0 system
> (Python 2.1.3, FreeTDS 0.53).
> 
> I've set up some Python code in order to create ASCII file containing
> the database scheme, functions and stored procedures. The code runs fine
> when connecting through ODBC from a Windows computer. It crashes when
> connecting from the Linux client, as soon as the 2nd query is run.
> 
> Has there already been some work done on it, both from the FreeTDS side
> (version  0.60rc1 came out these days, should I install it?) and the
> Sybase module side. Can I help in debugging the problem?

All I can suggest is that you use the _very_ lastest FreeTDS library.  The
last released version had some rather nasty bugs in it.

> As soon as I have again the chance to connect to the  SQL Server (it's
> at a customers place) I will paste you the exact message (something
> about threads and relesing a lock that has not been set).

Ah!  I've run into this myself.  I'll dig up my patches that re-work the
Sybase module locking code that fixes it (though I'm not sure if I'm just
working around errors in the FreeTDS LibCT implementation or unsafe
assumptions that David Cole made about Sybase's implementation).

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

[python-sybase] Segentation faults when connecting to SQL Server 2000

[Peter H. <hop...@ro...>]

Hi,

I'm trying to use the Sybase module from a Debian Linux 3.0 system
(Python 2.1.3, FreeTDS 0.53).

I've set up some Python code in order to create ASCII file containing
the database scheme, functions and stored procedures. The code runs fine
when connecting through ODBC from a Windows computer. It crashes when
connecting from the Linux client, as soon as the 2nd query is run.

Has there already been some work done on it, both from the FreeTDS side
(version  0.60rc1 came out these days, should I install it?) and the
Sybase module side. Can I help in debugging the problem?

As soon as I have again the chance to connect to the  SQL Server (it's
at a customers place) I will paste you the exact message (something
about threads and relesing a lock that has not been set).

Let me know if I can help,

Peter

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes:

>> Have you submitted the patch to the FreeTDS dude(s)?

Kevin> I've sent it in, but I'm not sure it is 100% correct yet --
Kevin> there may be more cases that need to be mapped to
Kevin> CS_SUCCEED/CS_FAIL.  Do you know where I could find an online
Kevin> spec for the CT lib?

Try here:

        http://sybooks.sybase.com/cng1250e.html

Specifically here:

        http://download.sybase.com/pdfdocs/cng1250e/ctref.pdf

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

On 12 Jul 2002, Dave Cole wrote:
> Kevin> On 11 Jul 2002, Dave Cole wrote:
> Kevin> > Thank you very much for that patch.  I will apply it this weekend if
> Kevin> > other family events do not prevent me.
> Kevin> 
> Kevin> Here is another small patch for FreeTDS that really helps:
> Kevin> 
> Kevin> --- ct.c~	Thu Jul 11 09:48:00 2002
> Kevin> +++ ct.c	Thu Jul 11 09:48:00 2002
> Kevin> @@ -807,6 +807,8 @@
> Kevin>        if (cmd->con->tds_socket) {
> Kevin>           tds_free_all_results(cmd->con->tds_socket);
> Kevin>        }
> Kevin> +      if (ret == CS_END_DATA)
> Kevin> +         ret = CS_SUCCEED;
> Kevin>        return ret;
> Kevin>     }
> Kevin>  
> Kevin> Otherwise, ct_cancel returns CS_END_DATA instead of CS_SUCCEED.
> 
> That is awesome debugging work.
> 
> Have you submitted the patch to the FreeTDS dude(s)?

I've sent it in, but I'm not sure it is 100% correct yet -- there may be
more cases that need to be mapped to CS_SUCCEED/CS_FAIL.  Do you know
where I could find an online spec for the CT lib?

Thanks,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

Kevin> On 11 Jul 2002, Dave Cole wrote:
Kevin> > Thank you very much for that patch.  I will apply it this weekend if
Kevin> > other family events do not prevent me.
Kevin> 
Kevin> Here is another small patch for FreeTDS that really helps:
Kevin> 
Kevin> --- ct.c~	Thu Jul 11 09:48:00 2002
Kevin> +++ ct.c	Thu Jul 11 09:48:00 2002
Kevin> @@ -807,6 +807,8 @@
Kevin>        if (cmd->con->tds_socket) {
Kevin>           tds_free_all_results(cmd->con->tds_socket);
Kevin>        }
Kevin> +      if (ret == CS_END_DATA)
Kevin> +         ret = CS_SUCCEED;
Kevin>        return ret;
Kevin>     }
Kevin>  
Kevin> Otherwise, ct_cancel returns CS_END_DATA instead of CS_SUCCEED.

That is awesome debugging work.

Have you submitted the patch to the FreeTDS dude(s)?

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

On 11 Jul 2002, Dave Cole wrote:
> Thank you very much for that patch.  I will apply it this weekend if
> other family events do not prevent me.

Here is another small patch for FreeTDS that really helps:

--- ct.c~	Thu Jul 11 09:48:00 2002
+++ ct.c	Thu Jul 11 09:48:00 2002
@@ -807,6 +807,8 @@
       if (cmd->con->tds_socket) {
          tds_free_all_results(cmd->con->tds_socket);
       }
+      if (ret == CS_END_DATA)
+         ret = CS_SUCCEED;
       return ret;
    }
 
Otherwise, ct_cancel returns CS_END_DATA instead of CS_SUCCEED.

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes:

Kevin> On 10 Jul 2002, Dave Cole wrote:
>> Thanks for putting the time into getting it to work.  With one
>> thing or another I have not been able to spend enough time on the
>> Sybase module of late.

Kevin> Attached is the diff to your Sybase module -- it includes
Kevin> mostly cosmetic changes, but overall, there isn't anything
Kevin> major.  It does need to build against the latest FreeTDS CVS,
Kevin> since their last release is total crap.

Thank you very much for that patch.  I will apply it this weekend if
other family events do not prevent me.

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

On Wed, 10 Jul 2002, Kevin Jacobs wrote:

> > Here is the current issue I'm working on.  My app is
> > single-threaded, so I'm a little confused as to why this happens:
> > 
> > Traceback:
> >       Traceback (most recent call last):
> [...]
> >       AssertionError: release() of un-acquire()d lock
> 
> Never mind -- after looking at the code, it is clear why it is
> blowing up.  Can you explain what the unlock in the try-except block
> is supposed to be doing?  Can that if-statement be safely deleted?
> 
>     def close(self):
>         '''DB-API Cursor.close()
>         '''
>         self._lock()
>         try:
>             if self._state == _CUR_CLOSED:
>                 self._raise_error(Error, 'cursor is closed')
>             if self._state != _CUR_IDLE:
>                 status = self._cmd.ct_cancel(CS_CANCEL_ALL)
>                 if status == CS_SUCCEED:
>                     self._unlock()
>             self._cmd = None
>             self._state = _CUR_CLOSED
>         finally:
>             self._unlock()

The Python locks are being used in a reentrant manner to make the
cursors thread safe.

Each method which alters the cursor object protects itself by
obtaining the lock at the start of the method and releasing at the
end.  Some sequences of cursor operations must be keep the cursor
under the control of the same thread for the entire sequence of
operations.  If you look at the callproc() method you will see the
beginning of such a sequence:

    if self._state == _CUR_IDLE:
        # At the start of a command acquire an extra lock -
        # when the cursor is idle again the extra lock will be
        # released.
        self._lock()

And again in the execute() method:

    # At the start of a command acquire an extra lock - when
    # the cursor is idle again the extra lock will be
    # released.
    self._lock()

If you look through the rest of the cursor code you will see places
where the balancing _unlock() method is called.  Once all of the
results have been fetched.  Following it through:

* Each row is fetched via the fetchone() method via the function
  _fetch_rows().  If no row could be fetched (None returned) the
  cursor has reached the end of a result set.

* At the end of result set the number of rows fetched is determined
  via the _fetch_rowcount() method.  If this method discovers that
  there are no more result sets (CS_END_RESULTS from ct library) it
  sets the cursor idle and performs the balancing _unlock()

Most of the other places in the code with do the balancing _unlock()
are variants of this.  When you close() a cursor while there are still
outstanding results then the code does the _unlock().  Likewise when
there is some sort of error returned by the Sybase ct_ library.

Hope this makes things a bit more clear.

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes:

Kevin> On 10 Jul 2002, Dave Cole wrote:
>> Thanks for putting the time into getting it to work.  With one
>> thing or another I have not been able to spend enough time on the
>> Sybase module of late.

Kevin> One thing: have you tested your modules with pymalloc?  The
Kevin> segfault on exit only seems occur when running against
Kevin> pymalloc.  I don't have the Sybase modules handy, so I'm trying
Kevin> to figure out if a double-free is coming from freetds or from
Kevin> the module.

I haven't tested with pymalloc as I just use the Debian python
packages for doing development.  If anyone else is able to do this for
me it would be very helpful.

If I build a special version of Python and configure like this:
        
        configure --prefix=$HOME/debug --with-pydebug

will it install files in any location other than the directory tree
below my home directory?

- Dave

-- 
http://www.object-craft.com.au

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

On Wed, 10 Jul 2002, Kevin Jacobs wrote:
> Here is the current issue I'm working on.  My app is single-threaded, so I'm
> a little confused as to why this happens:
> 
> Traceback:
>       Traceback (most recent call last):
[...]
>       AssertionError: release() of un-acquire()d lock

Never mind -- after looking at the code, it is clear why it is blowing up. 
Can you explain what the unlock in the try-except block is supposed to be
doing?  Can that if-statement be safely deleted?

    def close(self):
        '''DB-API Cursor.close()
        '''
        self._lock()
        try:
            if self._state == _CUR_CLOSED:
                self._raise_error(Error, 'cursor is closed')
            if self._state != _CUR_IDLE:
                status = self._cmd.ct_cancel(CS_CANCEL_ALL)
                if status == CS_SUCCEED:
                    self._unlock()
            self._cmd = None
            self._state = _CUR_CLOSED
        finally:
            self._unlock()

Thanks,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

On 10 Jul 2002, Dave Cole wrote:
> Thanks for putting the time into getting it to work.  With one thing
> or another I have not been able to spend enough time on the Sybase
> module of late.

Attached is the diff to your Sybase module -- it includes mostly cosmetic
changes, but overall, there isn't anything major.  It does need to build
against the latest FreeTDS CVS, since their last release is total crap.

Here is the current issue I'm working on.  My app is single-threaded, so I'm
a little confused as to why this happens:

Traceback:
      Traceback (most recent call last):
        File "./Server/connection_controller.py", line 446, in process_cmd
        File "./Server/connection_controller.py", line 506, in cmd_report
        File "/home/jacobs/projects/CGF/TradeSP/Reports/actualsummary.py", line 201, in generate
          D_Deductions = hash3( ts_queries.getDeductionsByCustomer(s, None, operCustomers, fy=fy) )
        File "./Lib/dblib.py", line 666, in __new__
        File "/home/jacobs/projects/CGF/Lib/ts_queries.py", line 3069, in run
          Deductions = dbcon.quickQuery(sql)
        File "./Lib/dblib.py", line 162, in quickQuery
        File "/usr/lib/python2.3/site-packages/Sybase.py", line 321, in close
          self._unlock()
        File "/usr/lib/python2.3/site-packages/Sybase.py", line 259, in _unlock
          self._owner._lock.release()
        File "/usr/lib/python2.3/threading.py", line 101, in release
          assert self.__owner is me, "release() of un-acquire()d lock"
      AssertionError: release() of un-acquire()d lock

Thanks,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

On 10 Jul 2002, Dave Cole wrote:
> Thanks for putting the time into getting it to work.  With one thing
> or another I have not been able to spend enough time on the Sybase
> module of late.

One thing:  have you tested your modules with pymalloc?  The segfault on
exit only seems occur when running against pymalloc.  I don't have the
Sybase modules handy, so I'm trying to figure out if a double-free is coming
from freetds or from the module.

-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Dave C. <dj...@ob...>]

>>>>> "Kevin" == Kevin Jacobs <ja...@pe...> writes:

Kevin> Hi Dave and company, Just thought I'd let you all know that
Kevin> I've gotten a version of Python-Sybase-0.35pre1 + FreeTDS 0.53
Kevin> to connect to MS SQL Server 2000 using TDS 7.0.  In fact, it
Kevin> does much more than just connect!  It can execute queries and
Kevin> seems to correctly return all of the data values I have tried.
Kevin> It crashes upon exit, but that is fairly problem.

Kevin> I'll work up diffs, though not much had to be changed.

Kevin> Thanks Dave!

Thanks for putting the time into getting it to work.  With one thing
or another I have not been able to spend enough time on the Sybase
module of late.

- Dave

-- 
http://www.object-craft.com.au

[python-sybase] FreeTDS + Sybase Module = MS SQL 2000

[Kevin J. <ja...@pe...>]

Hi Dave and company,

Just thought I'd let you all know that I've gotten a version of
Python-Sybase-0.35pre1 + FreeTDS 0.53 to connect to MS SQL Server 2000 using
TDS 7.0.  In fact, it does much more than just connect!  It can execute
queries and seems to correctly return all of the data values I have tried.
It crashes upon exit, but that is fairly problem.

I'll work up diffs, though not much had to be changed.

Thanks Dave!

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: ja...@th...
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Re: [python-sybase] still problem with pending results

[Dave C. <dj...@ob...>]

> Hello, some time ago in april I've once sent a mail to this
> group. However I still do not get things to run properly. I have
> tried to following code with python2.2 on Linux, Sybase 11.9.2, with
> python-sybase adapter V0.34 and V0.35pre2. Both fail with slightly
> different messages. What I actually want to do is just to close the
> cursor c1, open a new cursor c2 and then run the correct SQL
> there. But this also fails which is why I tried to do what Harri
> Pasanen suggested - unfortunately without success. Any ideas?

One thing which would really help would be to insert the following
line after import Sybase:

Sybase._ctx.debug = 1

This will turn on quite a lot of debugging which should help me
pinpoint what is going wrong.

> ---------------------------------------------------------
> import Sybase
> 
> db = Sybase.connect('monkey', 'cenix_admin', 'blabli1', 'cenix_lab')
> c1 = db.cursor()
> try:
>     # produce an error - THE TABLE 'DUMMY' DOES NOT EXIST
>     c1.execute('select * from dummy')
> except:
>     print 'select failed'
> 
> c1.close()
> db.commit()
> 
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 603,
> in commit
>      self.execute('commit transaction')
>    File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 633,
> in execute
>      self._raise_error(Error, 'ct_send')
>    File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 525,
> in _raise_error
>      raise exc(text)
> Sybase.Error: ct_send
> Layer: 1, Origin: 1
> ct_cmd_drop(): user api layer: external error: This routine can be
> called only if the command
> structure is idle.
> Layer: 1, Origin: 1
> ct_send(): user api layer: external error: This routine cannot be
> called because another command structure has results pending.

- Dave

-- 
http://www.object-craft.com.au

[python-sybase] still problem with pending results

[Ralph H. <he...@ce...>]

Hello,

some time ago in april I've once sent a mail to this group. However
I still do not get things to run properly. I have tried to following
code with python2.2 on Linux, Sybase 11.9.2, with python-sybase
adapter V0.34 and V0.35pre2. Both fail with slightly different
messages. What I actually want to do is just to close the cursor c1,
open a new cursor c2 and then run the correct SQL there. But this
also fails which is why I tried to do what Harri Pasanen suggested -
unfortunately without success. Any ideas?

Ralph

---------------------------------------------------------
import Sybase

db = Sybase.connect('monkey', 'cenix_admin', 'blabli1', 'cenix_lab')
c1 = db.cursor()
try:
    # produce an error - THE TABLE 'DUMMY' DOES NOT EXIST
    c1.execute('select * from dummy')
except:
    print 'select failed'

c1.close()
db.commit()

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 603, in 
commit
     self.execute('commit transaction')
   File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 633, in 
execute
     self._raise_error(Error, 'ct_send')
   File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 525, in 
_raise_error
     raise exc(text)
Sybase.Error: ct_send
Layer: 1, Origin: 1
ct_cmd_drop(): user api layer: external error: This routine can be 
called only if the command
structure is idle.
Layer: 1, Origin: 1
ct_send(): user api layer: external error: This routine cannot be called 
because another command structure has results pending.




Harri Pasanen wrote:
> On Tue, 09 Apr 2002 10:13:34 +0200 Ralph Heinkel <rh...@ce...> wrote:
> 
> 
>>Hello,
>>
>>every once in a while (especially after having sybase server problems)
>>I get the following message:
>>
>>['ct_send', {'status': 0, 'sqlstate': 'ZZZZZ', 'osnumber': 0, 
>>'osstring': '', 'msgstring': 'ct_send(): user api layer: external error: 
>>This routine cannot be called because another command structure has 
>>results pending.', 'msgnumber': 16843057, 'severity': 1}]
>>
>>
>>What would be the adequate reaction on this? (How do I detect this -
>>the the msgnumber 16843057 unique to this error?)
>>
>>Thanks,
>>
>>Ralph
>>
> 
> 
> I presume you are seeing the message in the exception handler for
> Sybase.Error ?
> 
> If you can, you could try  closing the open cursors, call db.commit() and
> then restart the operations.
> 
> Calling db.commit() in general seems to be a good idea for the Sybase
> module (v0.34).  I rearranged my code to call db.commit() before calling
> stored procedures, otherwise those calls sometimes silently failed
> producing wrong results, without throwing any exceptions.
> 
> 
> -Harri
> 
> 



-- 
------------------------------------------------------------------
Ralph Heinkel                  Cenix Bioscience GmbH
IT-Unit Director               Tel  : +49 351 210 2548
Pfotenhauerstr. 108            Fax  : +49 351 210 1309
01307 Dresden, Germany         eMail: he...@ce...

[python-sybase] How to handle stored procedure errors?

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

Me again,

I'm wondering how should I handle stored procedures returning error codes?  
Looks like the Sybase module 0.35pre1 raises an exception on those, and drops 
the connection.

The documentation on cursor.execute() and cursor.callproc() did not mention 
anything.

For example, calling sp_helpindex with a table having no indexes will throw an 
exception, after which a reconnect is required:

So my code looks something like:

import Sybase
db = Sybase.connect('SYBASE12', 'user', 'pwd', 'dbname',  auto_commit=1)

def IndexInfo(table):
   global db
    cmd = "sp_helpindex %s" % table
    try:
        print db.execute(cmd)
    except Sybase.DatabaseError:
        db = Sybase.connect('SYBASE12', 'user', 'pwd', 'dbname', 
auto_commit=1)
        pass

Which is not very clean.  



-Harri

Re: [python-sybase] NumericType not hashable?

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

On Monday 06 May 2002 09:23, Dave Cole wrote:
> > By the looks of it, NumericType is not python hash table friendly.
>
> It should be...  Can you tell us how you built the module and which
> platform you are using?
>

This was on Linux, Python 2.2, Sybase module 0.34, built from source and 
installed with "python setup.py install".

But looking at my own testcase, I can see I was in a rush, the testcase is 
incomplete.   So I guess this was a false alarm, sorry for the noice.

-Harri

> This is what happens when I try using the hash functionality:
> >>> import Sybase
> >>> n = Sybase.numeric(2)
> >>> type(n)
>
> <type 'NumericType'>
>
> >>> d = {n: 'two' }
> >>> d[2]
>
> 'two'
>
> >>> m = Sybase.numeric(3L)
> >>> d[m] = 'three'
> >>> d[3]
>
> 'three'
>
> >>> o = Sybase.numeric('4')
> >>> d[o] = 'four'
> >>> d[4]
>
> 'four'
>
> With my new 0.35pre1 callback error handling I now have problems with
> longs...
>
> >>> m = Sybase.numeric(1231312313123133L)
> >>> m
>
> 1231312313123133
>
> >>> hash(m)
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "Sybase.py", line 133, in _cslib_cb
>     raise Error(_fmt_client(msg))
> Sybase.Error: Layer: 2, Origin: 4
> cs_convert: cslib user api layer: common library error: The
> conversion/operation resulted in overflow.
>
> The numeric hash calculation tries to convert to an integer first in
> order to work out an integer compatible hash.  So it looks like I am
> going to have to create a fully internal CS_CONTEXT for doing things
> which I know might fail - such as attempts to convert NumericType to
> integer before doing a conversion to string then to long in order to
> calculate the hash.
>
> > That means that something like:
> >
> > c.execute('select id, limit_id, name from Sublimit_cvt')
> > rows = c.fetchall()
> > for row in rows:
> >     id, limit_id, name = row
> >
> > c.execute('select id from MyTable')
> > rows = c.fetchall()
> > for row in rows:
> >   id = row[0]
> >   print map[id]
> >
> >
> > will fail if id is of type AutomaticID in Sybase.
> >
> > I'm not sure if this is required by DB API, but I think it violates
> > the principle of least surprise.
>
> can you try doing something like this:
>
> c.execute('select id, limit_id, name from Sublimit_cvt')
> rows = c.fetchall()
> for row in rows:
>     id, limit_id, name = row
>     print id, type(id), hash(id)
>
> > My workaround was to force a conversion to string, so my code now
> > reads map[str(id)]. But maybe NumericType should be modified to act
> > as any number when used as a hash key?  Any opinions?
>
> It Already Does (TM) so I suspect there is something else going on,
> maybe related to the compilation.
>
> - Dave

Re: [python-sybase] windows binaries

[Dave C. <dj...@ob...>]

>>>>> "Laurent" == Laurent VASSEUR <va...@ti...> writes:

Laurent> Hello, I saw on
Laurent> https://vole.object-craft.com.au/projects/sybase/ that the
Laurent> Sybase module for python is working with a WIN2000
Laurent> client. Unfortunately, I don't have a C compiler available
Laurent> right now. If someone could provide me some binaries, that
Laurent> would be very helpfull.

I do not have access to Sybase on Windows.  Maybe someone else can
help here.

- Dave

-- 
http://www.object-craft.com.au

[python-sybase] windows binaries

[Laurent V. <va...@ti...>]

Hello,

I saw on https://vole.object-craft.com.au/projects/sybase/ that the Sybase 
module for python is working with a WIN2000 client. Unfortunately, I don't 
have a C compiler available right now. If someone could provide me some 
binaries, that would be very helpfull.

Thanks a lot.


Laurent VASSEUR