python-sybase-misc

Re: [python-sybase] Sybase Install Problems

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

>I am trying to install sybase-0.36 on a RedHat9 box. I have ran the commands
>SYBASE=/usr/lib
>export SYBASE
>
>and attempted to install, but get the following error:
>
>python setup.py install
>Directory /usr/lib/include does not exist - cannot build.

Some part of the C development system is probably missing, or maybe the
python-dev package?

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

[python-sybase] Sybase Install Problems

[Scott A. <sc...@tp...>]

I am trying to install sybase-0.36 on a RedHat9 box. I have ran the commands
SYBASE=/usr/lib
export SYBASE

and attempted to install, but get the following error:

python setup.py install
Directory /usr/lib/include does not exist - cannot build.


Do you have any suggestion on what may be wrong?

Thanks


Scott

[python-sybase] sybase 0.36 and Redhat 9

[alan r. <ru...@ru...>]

when I attempt to 'import Sybase' I am getting,

ImportError: /usr/local/lib/python2.2/site-packages/sybasect.so: undefined 
symbol: cs_dt_info

I am using RPMs:

sybase-common-12.5-3
sybase-openclient-12.5-3
sybase-ase-12.5-3

any ideas?

alan runyan

Re: [python-sybase] Sybase python runtime error

[<msa...@gr...>]

Steve Bremer wrote:

>When I try to execute any python programs using the "Sybase" 
>python module, I receive the following error:
>
>
>===
>Traceback (most recent call last):
>  File "/export/home/sybase/python/test/sybase.py", line 3, in ?
>    import Sybase
>  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 20, in ?
>    from sybasect import *
>ImportError: ld.so.1: /usr/bin/python: fatal: relocation error: file 
>/usr/local/
>lib/python2.2/site-packages/sybasect.so: symbol ct_cmd_alloc: 
>referenced symbol
>not found
>====
>
>However, my LD_LIBRARY_PATH does include /sybase/OCS-
>12/lib.  If I execute:
>
>ldd /usr/local/lib/python2.2/site-packages/sybasect.so
>
>I receive the following output:
>
>        libsybdb.so =>   /sybase/OCS-12_0/lib/libsybdb.so
>        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
>        libc.so.1 =>     /usr/lib/libc.so.1
>        libdl.so.1 =>    /usr/lib/libdl.so.1
>        /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
>
>So, it looks to me like the linker can find the Sybase library just fine 
>because if I clear LD_LIBRARY_PATH before executing the 
>command, I get the following instead:
>
>        libsybdb.so =>   (file not found)
>        libgcc_s.so.1 =>         (file not found)
>
>
>Version information:
>
>Sybase 12.0
>Solaris 8
>Python 2.2.2
>
>There were no error messages during the compile/install.  I used the 
>following steps to compile/install:
>
>python setup.py build_ext -U WANT_BULKCOPY -D WANT_THREADS
>su -
>python setup.py install
>
>I found a similar post in the archives, but there was no resolution 
>offered.  Any help would be greatly appreciated.
>
>Please CC me as I'm not subscribed to the list.
>
>Thanks,
>Steve Bremer
>NEBCO, Inc.
>System & Security Administrator
>
>
>  
>
I once had to use the Solaris linker  instead of the one that comes with 
gcc to use DCOracle2. I recall it is called uc something.

[python-sybase] Sybase python runtime error

[Steve B. <st...@ne...>]

When I try to execute any python programs using the "Sybase" 
python module, I receive the following error:


===
Traceback (most recent call last):
  File "/export/home/sybase/python/test/sybase.py", line 3, in ?
    import Sybase
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 20, in ?
    from sybasect import *
ImportError: ld.so.1: /usr/bin/python: fatal: relocation error: file 
/usr/local/
lib/python2.2/site-packages/sybasect.so: symbol ct_cmd_alloc: 
referenced symbol
not found
====

However, my LD_LIBRARY_PATH does include /sybase/OCS-
12/lib.  If I execute:

ldd /usr/local/lib/python2.2/site-packages/sybasect.so

I receive the following output:

        libsybdb.so =>   /sybase/OCS-12_0/lib/libsybdb.so
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1

So, it looks to me like the linker can find the Sybase library just fine 
because if I clear LD_LIBRARY_PATH before executing the 
command, I get the following instead:

        libsybdb.so =>   (file not found)
        libgcc_s.so.1 =>         (file not found)


Version information:

Sybase 12.0
Solaris 8
Python 2.2.2

There were no error messages during the compile/install.  I used the 
following steps to compile/install:

python setup.py build_ext -U WANT_BULKCOPY -D WANT_THREADS
su -
python setup.py install

I found a similar post in the archives, but there was no resolution 
offered.  Any help would be greatly appreciated.

Please CC me as I'm not subscribed to the list.

Thanks,
Steve Bremer
NEBCO, Inc.
System & Security Administrator

RE: [python-sybase] Fix for rowcount

[<Sha...@su...>]

I have never seen Sybase -- or Oracle, for that matter -- give
indications of result-set size before fetching; I would be happy if you
could point me to such APIs.

Thanks,
	Shai.


-----Original Message-----
From: Peter Hopfgartner [mailto:hop...@ro...]=20
Sent: Wednesday, May 28, 2003 23:03
To: Berger, Shai
Cc: pyt...@ob...
Subject: Re: [python-sybase] Fix for rowcount


Sha...@su... wrote:

>I believe the current behavior is correct according to
>the DB API spec, because when a query is executed, but
>no fetch has been performed, the interface cannot determine
>the number of rows produced (second clause, not first).
> =20
>
Why? The database APIs that I have worked with give some information=20
about the size of the resultset exactly at this stage. There are of =20
minor use in a later state.

>    The attribute is -1 in case no executeXXX() has been performed on
>    the cursor or the rowcount of the last operation is not
determinable
>    by the interface.[7]
> =20
>

Well, I'm using the Sybase mudule since last summer. The behaviour=20
changed exactly with the new fetcher classes, which are new to version=20
0.36. So, until now, the interface WAS able to determine if there were=20
or were not rows.

>Peter's problems with his patch indicate that the Sybase
>module decides on its own when exactly to perform fetches
>(until the time they are actually needed, of course). In
>this case, the consistent behavior of returning -1 until
>the user actually tries to fetch something sounds preferable.
>
>To the best of my knowledge, Sybase libraries do not reliably
>report an empty query until you actually try to fetch something,
>so the problem is not with the Python module.
>
>Peter: If you absolutely need to know the number of rows before
>you try to fetch anything, you can select count(*) with the same
>tables and conditions, before your query. This will always return
>one row... In theory, it could be done in the same query (using
>the Sybase "compute" clause, returning a separate result set),=20
>but IIRC the compute results are returned only after the "regular"
>results, so you could only get to the rowcount this way by first
>discarding all the rows.
> =20
>
Well, this would blow and uglify the code in an inappropriate way. Being

forced to fire 2 queries, when only 1 is needed, means that there are=20
serious problems in the API. Then it would be preferable to catch the=20
appropriate exception.

In any case, I'm still convinced, that this is a minor bug and not a=20
fundamental issue, since it worked fine until version 0.36. But, if it=20
comes to the Sybase API, I must admit complete ingnorance.

>Hope this helps,
>	Shai.
>
> =20
>
Thank you very much for your interest,

Peter

Re: [python-sybase] Fix for rowcount

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

Sha...@su... wrote:

>I believe the current behavior is correct according to
>the DB API spec, because when a query is executed, but
>no fetch has been performed, the interface cannot determine
>the number of rows produced (second clause, not first).
>  
>
Why? The database APIs that I have worked with give some information 
about the size of the resultset exactly at this stage. There are of  
minor use in a later state.

>    The attribute is -1 in case no executeXXX() has been performed on
>    the cursor or the rowcount of the last operation is not determinable
>    by the interface.[7]
>  
>

Well, I'm using the Sybase mudule since last summer. The behaviour 
changed exactly with the new fetcher classes, which are new to version 
0.36. So, until now, the interface WAS able to determine if there were 
or were not rows.

>Peter's problems with his patch indicate that the Sybase
>module decides on its own when exactly to perform fetches
>(until the time they are actually needed, of course). In
>this case, the consistent behavior of returning -1 until
>the user actually tries to fetch something sounds preferable.
>
>To the best of my knowledge, Sybase libraries do not reliably
>report an empty query until you actually try to fetch something,
>so the problem is not with the Python module.
>
>Peter: If you absolutely need to know the number of rows before
>you try to fetch anything, you can select count(*) with the same
>tables and conditions, before your query. This will always return
>one row... In theory, it could be done in the same query (using
>the Sybase "compute" clause, returning a separate result set), 
>but IIRC the compute results are returned only after the "regular"
>results, so you could only get to the rowcount this way by first
>discarding all the rows.
>  
>
Well, this would blow and uglify the code in an inappropriate way. Being 
forced to fire 2 queries, when only 1 is needed, means that there are 
serious problems in the API. Then it would be preferable to catch the 
appropriate exception.

In any case, I'm still convinced, that this is a minor bug and not a 
fundamental issue, since it worked fine until version 0.36. But, if it 
comes to the Sybase API, I must admit complete ingnorance.

>Hope this helps,
>	Shai.
>
>  
>
Thank you very much for your interest,

Peter

RE: [python-sybase] Fix for rowcount

[<Sha...@su...>]

I believe the current behavior is correct according to
the DB API spec, because when a query is executed, but
no fetch has been performed, the interface cannot determine
the number of rows produced (second clause, not first).

    The attribute is -1 in case no executeXXX() has been performed on
    the cursor or the rowcount of the last operation is not determinable
    by the interface.[7]

Peter's problems with his patch indicate that the Sybase
module decides on its own when exactly to perform fetches
(until the time they are actually needed, of course). In
this case, the consistent behavior of returning -1 until
the user actually tries to fetch something sounds preferable.

To the best of my knowledge, Sybase libraries do not reliably
report an empty query until you actually try to fetch something,
so the problem is not with the Python module.

Peter: If you absolutely need to know the number of rows before
you try to fetch anything, you can select count(*) with the same
tables and conditions, before your query. This will always return
one row... In theory, it could be done in the same query (using
the Sybase "compute" clause, returning a separate result set),=20
but IIRC the compute results are returned only after the "regular"
results, so you could only get to the rowcount this way by first
discarding all the rows.

Hope this helps,
	Shai.

Re: [python-sybase] Fix for rowcount

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

On Tue, 27 May 2003 15:53:46 +0200
 "hopfgartner" <hop...@ro...> wrote:
> This should fix the problem I described in my previous
> posting.
> 
> Basically, it seems that the rowcount value is never
> passed
> from the fetcher to the Cursor object.
> 
> Hope this helps,
> 
> Peter

Well not everything seems fine. Some of my tests seem to
work and some not. Those failing give me

AttributeError: _FetchLazy instance has no attribute
'rowcount'

Can somebody have a look at this issue?

Best regards,

Peter

[python-sybase] Fix for rowcount

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

This should fix the problem I described in my previous
posting.

Basically, it seems that the rowcount value is never passed
from the fetcher to the Cursor object.

Hope this helps,

Peter

Re: [python-sybase] How to interpret the cursor.rowcount?

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

>In fact, I DO the execute before. in any case, i will extract a small
>test case and post it on the list. In the mean time I will continue with
>0.36pre6.

Reading your message again (more carefully this time), I agree with you -
I would have expected it to return 0 for a query returning no rows. Dave?

>On Mon, 2003-05-26 at 02:00, Andrew McNamara wrote:
>> >In particular, when a query does not return any matching
>> >row, the versions up to 0.36pre6 set the value of
>> >cursor.rowcount to 0 (what I really expected it to be).
>> >With 0.36, the value becomes -1.
>> 
>> I would guess it's been done to improve compliance with the Python
>> Database API Specification 2.0, which has the following to say about
>> rowcount:
>> 
>>     This read-only attribute specifies the number of rows that the last
>>     executeXXX() produced (for DQL statements like select) or affected
>>     (for DML statements like update or insert).
>> 
>>     The attribute is -1 in case no executeXXX() has been performed on
>>     the cursor or the rowcount of the last operation is not determinable
>>     by the interface.[7]
-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/

Re: [python-sybase] How to interpret the cursor.rowcount?

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

In fact, I DO the execute before. in any case, i will extract a small
test case and post it on the list. In the mean time I will continue with
0.36pre6.

Regards,

Peter


On Mon, 2003-05-26 at 02:00, Andrew McNamara wrote:
> >In particular, when a query does not return any matching
> >row, the versions up to 0.36pre6 set the value of
> >cursor.rowcount to 0 (what I really expected it to be).
> >With 0.36, the value becomes -1.
> 
> I would guess it's been done to improve compliance with the Python
> Database API Specification 2.0, which has the following to say about
> rowcount:
> 
>     This read-only attribute specifies the number of rows that the last
>     executeXXX() produced (for DQL statements like select) or affected
>     (for DML statements like update or insert).
> 
>     The attribute is -1 in case no executeXXX() has been performed on
>     the cursor or the rowcount of the last operation is not determinable
>     by the interface.[7]
-- 
Peter Hopfgartner <hop...@ro...>

Re: [python-sybase] How to interpret the cursor.rowcount?

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

>In particular, when a query does not return any matching
>row, the versions up to 0.36pre6 set the value of
>cursor.rowcount to 0 (what I really expected it to be).
>With 0.36, the value becomes -1.

I would guess it's been done to improve compliance with the Python
Database API Specification 2.0, which has the following to say about
rowcount:

    This read-only attribute specifies the number of rows that the last
    executeXXX() produced (for DQL statements like select) or affected
    (for DML statements like update or insert).

    The attribute is -1 in case no executeXXX() has been performed on
    the cursor or the rowcount of the last operation is not determinable
    by the interface.[7]

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

[python-sybase] How to interpret the cursor.rowcount?

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

Dear David Cole, dear list members,

I'm installing right now the world famous dbweaver (One of
the 0% activity projects on Sourceforge. Ok, I know, I'm
the project leader and only programmer of it) on a machine
here at work.

I installed sybase-0.36 and noted that the behaviour of
cursor.rowcount changed from earlier versions. 

In particular, when a query does not return any matching
row, the versions up to 0.36pre6 set the value of
cursor.rowcount to 0 (what I really expected it to be).
With 0.36, the value becomes -1.

Is this the desired behaviour or just a mino glitch?

Environment notes:
Client Platform 1: Trusted Debian 1.0 (based on Debian 3.0)
with python 2.1.2, freetds-0.61.
Client Platform 2: Debian testing as of today with python
2.2.2, freetds-0.61.
Database Server: SQL Server 2000, sp2, on Windows 2000
Server, sp3.

Best regards and enjoy the weekend,

Peter Hopfgartner

Re: [python-sybase] FreeBSD Port framework

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

>>>>> "Gregory" == Gregory Bond <gn...@it...> writes:

Gregory> I've created a ports framework for Sybase module 0.36.  It's
Gregory> in the FreeBSD GNATS database (pr ports/51543) or you can
Gregory> fetch it from http://www.itga.com.au/~gnb/py-sybase-port.shar

Gregory> [Dave: feel free to whack this on the official Sybase module
Gregory> web page.]

Done.

        http://www.object-craft.com.au/projects/sybase/
        http://www.object-craft.com.au/projects/sybase/install.html

- Dave

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

Re: [python-sybase] Some 0.36 problems

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

> I'm trying to compile 0.36 on FreeBSD with FreeTDS 0.60 with Python
> 2.2.2 (But I suspect this is not a FreeBSD-specific problem).  The
> command I am using is
> 	python setup.py build_ext -D WANT_THREADS,HAVE_FREETDS=60 -U WANT_BULKCOPY

I didn't know that you could coalesce macros like that.  What a
strange thing to do while not allowing values to be assigned.

> but this is breaking:
> 	error: invalid command 'WANT_BULKCOPY' (no module named 'distutils.command.WANT_BULKCOPY')
> 
> Putting the -U before the -D also fails in interesting ways:
> 	python setup.py build_ext -U WANT_BULKCOPY -D WANT_THREADS,HAVE_FREETDS=60
> 	error: option -D requires argument
> 
> It works fine without the "=60", so I suspect a problem with the funky handling
> of the -D<>= in setup.py.

Yup.  It would be really good if there was a way around that
abomination but the FreeTDS people do not put their version identifier
in any useful format that can be used by the C preprocessor.

> A workaround is to make sure the -D HAVE_FREETDS=60 is the LAST argument, and 
> not coalesce the -D arguments(i.e. "-D WANT_FOO -D HAVE_FREETDS=60" rather 
> than "-D WANT_FOO,HAVE_FREETDS=60").
> 
> Or the following patch seems to handle the various permutations of
> -D and -U a bit better:
> 
> (beware whitespace munching from cut-n-paste)
> 
> --- setup.py-dist       Tue Apr 29 11:03:17 2003
> +++ setup.py    Tue Apr 29 11:02:36 2003
> @@ -116,6 +116,11 @@
>          del sys.argv[i - 1]
>      # Now set the TDS level the other other way.
>      syb_macros.append(('HAVE_FREETDS', suffix[1:]))
> +    if prefix:
> +       # Handle -D WANT_X,HAVE_FREETDS=60 case
> +       if prefix[-1] == ',':
> +           prefix = prefix[:-1]
> +       sys.argv[i:i] = [prefix]
>      break
> 
>  for api in ('blk_alloc', 'blk_describe', 'blk_drop', 'blk_rowxfer_mult',

Applied.  Thanks for that.

- Dave

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

[python-sybase] FreeBSD Port framework

[Gregory B. <gn...@it...>]

I've created a ports framework for Sybase module 0.36.  It's in the FreeBSD 
GNATS database (pr ports/51543) or you can fetch it from 
	http://www.itga.com.au/~gnb/py-sybase-port.shar

[Dave: feel free to whack this on the official Sybase module web page.]

[python-sybase] Some 0.36 problems

[Gregory B. <gn...@it...>]

I'm trying to compile 0.36 on FreeBSD with FreeTDS 0.60 with Python 2.2.2 (But
I suspect this is not a FreeBSD-specific problem).  The command I am using is
	python setup.py build_ext -D WANT_THREADS,HAVE_FREETDS=60 -U WANT_BULKCOPY

but this is breaking:
	error: invalid command 'WANT_BULKCOPY' (no module named 'distutils.command.WANT_BULKCOPY')

Putting the -U before the -D also fails in interesting ways:
	python setup.py build_ext -U WANT_BULKCOPY -D WANT_THREADS,HAVE_FREETDS=60
	error: option -D requires argument

It works fine without the "=60", so I suspect a problem with the funky handling
of the -D<>= in setup.py.

A workaround is to make sure the -D HAVE_FREETDS=60 is the LAST argument, and 
not coalesce the -D arguments(i.e. "-D WANT_FOO -D HAVE_FREETDS=60" rather 
than "-D WANT_FOO,HAVE_FREETDS=60").

Or the following patch seems to handle the various permutations of -D and -U a 
bit better:

(beware whitespace munching from cut-n-paste)

--- setup.py-dist       Tue Apr 29 11:03:17 2003
+++ setup.py    Tue Apr 29 11:02:36 2003
@@ -116,6 +116,11 @@
         del sys.argv[i - 1]
     # Now set the TDS level the other other way.
     syb_macros.append(('HAVE_FREETDS', suffix[1:]))
+    if prefix:
+       # Handle -D WANT_X,HAVE_FREETDS=60 case
+       if prefix[-1] == ',':
+           prefix = prefix[:-1]
+       sys.argv[i:i] = [prefix]
     break

 for api in ('blk_alloc', 'blk_describe', 'blk_drop', 'blk_rowxfer_mult',

[python-sybase] Sybase module 0.36 released

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

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

NOTES:

This is another incremental improvement to FreeTDS support.

You can build for FreeTDS like this:

     python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
     python setup.py install

If you are using FreeTDS 0.60 or 0.61 change the compile command to:

     python setup.py build_ext -D HAVE_FREETDS=60 -U WANT_BULKCOPY

or
     python setup.py build_ext -D HAVE_FREETDS=61 -U WANT_BULKCOPY


The module is available here:

    http://www.object-craft.com.au/projects/sybase/download/sybase-0.36.tar.gz

The module home page is here:

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

CHANGES SINCE 0.36pre6:

* Output parameters from stored procedures are supported via the
  OUTPUT() function.  The parameter to OUTPUT() determines the type
  and size of the buffer which will be allocated to receive the output
  value.

    c.callproc('test_proc', {'@type': 'business',
                             '@tot_sales': 5,
                             '@num_books': Sybase.OUTPUT(1)})

* Added Time() and TimeFromTicks() DB API functions.

* Fixed fmx.maxlength typo.

* Reorganised result fetching to use "fetcher" classes; _FetchNow,
  _FetchNowParams, and _FetchLazy.  This was in response to testing
  against the Python DB API 2.0 Anal Compliance Unit Test.

CHANGES SINCE 0.35:

* Fixed bug in ctx.c:ct_con_drop() which caused SEGFAULT with
  FreeTDS.

* Export version of FreeTDS used in sybasect.__have_freetds__

* Set Sybase._ctx as the global context soon as in Sybase.py to
  avoid problems with undefined global ctx.

* Look for SYBASE_OCS on all platforms.

* Fixed spelling error in ctx.c:global_ctx().

* Fixed cursor locking bug with .nextset() method.

* Added .debug_msg() method to context type which writes to the debug
  log when debugging is enabled for the context object.

* Merged AIX build changes from Dietmar Rothkamp.

* Now compiles with FreeTDS 0.61.

* Limit size of TEXT fields to 65536.

* Removed references to CS_PENDING and CS_BUSY in Sybase.py.

* Bind CS_VARBINARY_TYPE as CS_BINARY_TYPE.

* Do not attempt to ct_cancel() when handling an exception if have not
  connected to the server.  Bug fix in Sybase.py.

* Seems like FreeTDS reports the wrong maxlength in ct_describe() for
  CS_NUMERIC_TYPE and CS_DECIMAL_TYPE.  Ignore FreeTDS and assume a
  maxlength of sizeof(CS_NUMERIC).  Bugfix in databuf.c.

* Use correct T_STRING_INPLACE type in structure member descriptions.
  The code does not use Python API for these members.

* Debug output for DataFmt now includes scale and precision.

* More definitions added to freetds.h; CS_SRC_VALUE, CS_CLEAR.

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

[python-sybase] runtime problem - dcl_result_drop unresolved

[<ja...@at...>]

I have looked through the mailing list archives but cannot find mention of this
problem.

I can successfully build sybase module 0.35 against Python 2.2.2 and Sybase 12.5
_or_ Sybase 11.9.2.

The installation is successful, but when I try to import Sybase I see the following:

[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import Sybase
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python-2.2.2/lib/python2.2/site-packages/Sybase.py", line 20, in ?
    from sybasect import *
ImportError: ld.so.1: python: fatal: relocation error: file
/opt/sybase/lib/libct.so: symbol dcl_result_drop: referenced symbol not found

I am using Solaris 8. When I trace the dependencies of sybasect.so and libct.so,
I see that dcl_result_drop is just the first of many unresolved symbols. Has
anyone seen and solved this? I can only find this sybmol in the Sybase
libraries; it doesn't even appear in the headers I have installed.

RE: [python-sybase] Problem binding params with FreeTDS

[<Sha...@in...>]

Ehmm...

(I don't currently have access to the software, so this advice is
somewhat of a shot in the dark:)

You seem to be reusing the cursor to execute a second query before
you're really through
with the results from the earlier query. Sybase has a strong dislike for
this. If I'm right,
you should see the printing of the first query result before the
exception. If so, to fix, you
need to either put the conn.cursor() and cursor.close() calls in the
loop, or otherwise make
sure to fetch until there are no more records.

Just to make things simpler, try something like=20

    cursor =3D conn.cursor()
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D =
@n",
{"@n":'a'} )
    (c,qtype) =3D cursor.fetchone()
    print comp, qtype

outside any loop.

Hope this helps,
	Shai.

-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Monday, April 21, 2003 21:26
To: pyt...@ob...
Subject: RE: [python-sybase] Problem binding params with FreeTDS


Ok, I tried the @n with single quotes, with double quotes escaped, with
no quotes=20
and I still get the same problem every time.

thoughts?

Nicholas

:CODE:
    cursor =3D conn.cursor()
    comps =3D ('a', 'b', 'c', 'd')

    for comp in comps:
        cursor.execute("SELECT id, queuetype FROM Components WHERE id =
=3D
@n", {"@n":comp} )

        (c,qtype) =3D cursor.fetchone()

        print comp, qtype

    cursor.close()

:ERROR:

Traceback (most recent call last):
  File "./DB.py", line 69, in ?
    _query3(conn)
  File "./DB.py", line 56, in _query3
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D =
@n",
{"@n":comp} )
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 380, in
execute
    self._raise_error(Error, 'ct_param')
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 310, in
_raise_error
    raise exc(text)
Sybase.Error: ct_param


-----Original Message-----
From: Sha...@in...
[mailto:Sha...@in...]
Sent: Sunday, April 20, 2003 3:54 AM
To: Nicholas Veeser; pyt...@ob...
Subject: RE: [python-sybase] Problem binding params with FreeTDS


Assuming your command is as reported in the traceback (...id =3D '@n') =
and
not as in the source, just remove the single quotes from around the
"@n". Your command specifies not a parameter named "@n", but a string
constant.

Hope this helps,
	Shai.


-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Saturday, April 19, 2003 02:02
To: pyt...@ob...
Subject: [python-sybase] Problem binding params with FreeTDS


I am using FreeTDS 0.61


I am doing a basic bind with parameters and I am getting an error.

    cursor =3D conn.cursor()
    comps =3D ('a', 'b', 'c')

    for comp in comps:
        cursor.execute("SELECT id, queuetype FROM Components WHERE id =
=3D
'@' ", {'@n' : comp} )

        (c,qtype) =3D cursor.fetchone()

        print comp, qtype

    cursor.close()

My results are thus...

Traceback (most recent call last):
  File "./DB.py", line 69, in ?
    _query3(conn)
  File "./DB.py", line 56, in _query3
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D
'@n'", { '@n' : comp} )
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 380, in
execute
    self._raise_error(Error, 'ct_param')
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 310, in
_raise_error
    raise exc(text)
Sybase.Error: ct_param


Any thoughts?

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

RE: [python-sybase] Problem binding params with FreeTDS

[Nicholas V. <nic...@pl...>]

Ok, I tried the @n with single quotes, with double quotes escaped, with =
no quotes=20
and I still get the same problem every time.

thoughts?

Nicholas

:CODE:
    cursor =3D conn.cursor()
    comps =3D ('a', 'b', 'c', 'd')

    for comp in comps:
        cursor.execute("SELECT id, queuetype FROM Components WHERE id =
=3D @n", {"@n":comp} )

        (c,qtype) =3D cursor.fetchone()

        print comp, qtype

    cursor.close()

:ERROR:

Traceback (most recent call last):
  File "./DB.py", line 69, in ?
    _query3(conn)
  File "./DB.py", line 56, in _query3
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D =
@n", {"@n":comp} )
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 380, in =
execute
    self._raise_error(Error, 'ct_param')
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 310, in =
_raise_error
    raise exc(text)
Sybase.Error: ct_param


-----Original Message-----
From: Sha...@in...
[mailto:Sha...@in...]
Sent: Sunday, April 20, 2003 3:54 AM
To: Nicholas Veeser; pyt...@ob...
Subject: RE: [python-sybase] Problem binding params with FreeTDS


Assuming your command is as reported in the traceback (...id =3D '@n') =
and
not as in the source, just remove the single quotes from around the
"@n". Your command specifies not a parameter named "@n", but a string
constant.

Hope this helps,
	Shai.


-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Saturday, April 19, 2003 02:02
To: pyt...@ob...
Subject: [python-sybase] Problem binding params with FreeTDS


I am using FreeTDS 0.61


I am doing a basic bind with parameters and I am getting an error.

    cursor =3D conn.cursor()
    comps =3D ('a', 'b', 'c')

    for comp in comps:
        cursor.execute("SELECT id, queuetype FROM Components WHERE id =
=3D
'@' ", {'@n' : comp} )

        (c,qtype) =3D cursor.fetchone()

        print comp, qtype

    cursor.close()

My results are thus...

Traceback (most recent call last):
  File "./DB.py", line 69, in ?
    _query3(conn)
  File "./DB.py", line 56, in _query3
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D
'@n'", { '@n' : comp} )
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 380, in
execute
    self._raise_error(Error, 'ct_param')
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 310, in
_raise_error
    raise exc(text)
Sybase.Error: ct_param


Any thoughts?

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

RE: [python-sybase] Having a problem with rowcount

[Nicholas V. <nic...@pl...>]

Ok, that mostly makes sense.
So why does the documentation not say that. Is that because=20
its pulled basically from the DB-API 2.0 docs?

So then what is the apropriate way to programatically=20
determine if I got any rows back at all from a query?
Basically I add the parameter which comes commandline from the=20
user and the only way I know if its valid is if there is a row
in the database.    If select gives no rowcount, what should
I check in its place.  Or do I just catch the exception from=20
Cursor.fetchone().

Thanx
nicholas

-----Original Message-----
From: Sha...@in...
[mailto:Sha...@in...]
Sent: Sunday, April 20, 2003 3:51 AM
To: Nicholas Veeser; pyt...@ob...
Subject: RE: [python-sybase] Having a problem with rowcount


The rowcount is not set for selections, only for update and delete. This
is a behavior of the underlying database (Sybase does it, Oracle does
it, I suppose Microsoft does it too, though I don't really know). The
rationale is that this way the DBMS doesn't really have to check all the
possible rows until you ask to fetch them.

Hope this helps,
	Shai.


-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Saturday, April 19, 2003 00:52
To: pyt...@ob...
Subject: [python-sybase] Having a problem with rowcount


So I am using FreeTDS with Python and Sybase.py.

I am do a connection, cursor, execute a query and can fetch the results
of the query.
All that works.

But when I go to change the code to check the rowcount for the status of
the query,=20
it is always -1.   Should it not be set to the number of rows in the
query, which for my
query is like 50.

Here is the code (basically):

conn =3D Sybase.connect( cfg['dsn'], cfg['user'], cfg['pass'] )
cursor =3D conn.cursor()
cursor.execute ("SELECT id, queuetype FROM Components")

print "XXX: rowcount:", cursor.rowcount

while (1):
        row =3D cursor.fetchone()
        if row =3D=3D None: break
        print row

connect.close()

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

RE: [python-sybase] Problem binding params with FreeTDS

[<Sha...@in...>]

Assuming your command is as reported in the traceback (...id =3D '@n') =
and
not as in the source, just remove the single quotes from around the
"@n". Your command specifies not a parameter named "@n", but a string
constant.

Hope this helps,
	Shai.


-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Saturday, April 19, 2003 02:02
To: pyt...@ob...
Subject: [python-sybase] Problem binding params with FreeTDS


I am using FreeTDS 0.61


I am doing a basic bind with parameters and I am getting an error.

    cursor =3D conn.cursor()
    comps =3D ('a', 'b', 'c')

    for comp in comps:
        cursor.execute("SELECT id, queuetype FROM Components WHERE id =
=3D
'@' ", {'@n' : comp} )

        (c,qtype) =3D cursor.fetchone()

        print comp, qtype

    cursor.close()

My results are thus...

Traceback (most recent call last):
  File "./DB.py", line 69, in ?
    _query3(conn)
  File "./DB.py", line 56, in _query3
    cursor.execute("SELECT id, queuetype FROM Components WHERE id =3D
'@n'", { '@n' : comp} )
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 380, in
execute
    self._raise_error(Error, 'ct_param')
  File "/usr/local/lib/python2.2/site-packages/Sybase.py", line 310, in
_raise_error
    raise exc(text)
Sybase.Error: ct_param


Any thoughts?

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

RE: [python-sybase] Having a problem with rowcount

[<Sha...@in...>]

The rowcount is not set for selections, only for update and delete. This
is a behavior of the underlying database (Sybase does it, Oracle does
it, I suppose Microsoft does it too, though I don't really know). The
rationale is that this way the DBMS doesn't really have to check all the
possible rows until you ask to fetch them.

Hope this helps,
	Shai.


-----Original Message-----
From: Nicholas Veeser [mailto:nic...@pl...]=20
Sent: Saturday, April 19, 2003 00:52
To: pyt...@ob...
Subject: [python-sybase] Having a problem with rowcount


So I am using FreeTDS with Python and Sybase.py.

I am do a connection, cursor, execute a query and can fetch the results
of the query.
All that works.

But when I go to change the code to check the rowcount for the status of
the query,=20
it is always -1.   Should it not be set to the number of rows in the
query, which for my
query is like 50.

Here is the code (basically):

conn =3D Sybase.connect( cfg['dsn'], cfg['user'], cfg['pass'] )
cursor =3D conn.cursor()
cursor.execute ("SELECT id, queuetype FROM Components")

print "XXX: rowcount:", cursor.rowcount

while (1):
        row =3D cursor.fetchone()
        if row =3D=3D None: break
        print row

connect.close()

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