python-sybase-misc

[Python-sybase-misc] "ImportError: .../sybasect.so: undefined symbol: cs_config"

[Terry B. <te...@te...>]

Hi,

I'm happily running the Python-Sybase module on Python 2.5.2, FreeTDS
0.82, Debian Lenny/686. Everything work with no problems.

However, when I build the module on an equivalent 64-bit system Python
2.5.2, FreeTDS 0.82, Debian Lenny/AMD64, I encounter the following
runtime error when running import Sybase:

Traceback (most recent call last):
  File "/srv/ipdb/bin/ndor_latest", line 3, in <module>
    import Sybase
  File "/usr/lib/python2.5/site-packages/Sybase.py", line 11, in <module>
    from sybasect import *
ImportError: /usr/lib/python2.5/site-packages/sybasect.so: undefined
symbol: cs_config

Any clues as to what might be happening would be gratefully received.


All the best,

Terry


----

Build output...

$ export SYBASE=/usr
$ python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
running build_ext
building 'sybasect' extension
creating build
creating build/temp.linux-x86_64-2.5
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c blk.c -o
build/temp.linux-x86_64-2.5/blk.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c databuf.c
-o build/temp.linux-x86_64-2.5/databuf.o
databuf.c:498: warning: initialization from incompatible pointer type
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c cmd.c -o
build/temp.linux-x86_64-2.5/cmd.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c conn.c -o
build/temp.linux-x86_64-2.5/conn.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c ctx.c -o
build/temp.linux-x86_64-2.5/ctx.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c datafmt.c
-o build/temp.linux-x86_64-2.5/datafmt.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c iodesc.c -o
build/temp.linux-x86_64-2.5/iodesc.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c locale.c -o
build/temp.linux-x86_64-2.5/locale.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c msgs.c -o
build/temp.linux-x86_64-2.5/msgs.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c numeric.c
-o build/temp.linux-x86_64-2.5/numeric.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c money.c -o
build/temp.linux-x86_64-2.5/money.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c datetime.c
-o build/temp.linux-x86_64-2.5/datetime.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c date.c -o
build/temp.linux-x86_64-2.5/date.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DWANT_BULKCOPY -DSYB_LP64 -DHAVE_DATETIME
-DHAVE_DECIMAL -DHAVE_BLK_ALLOC -DHAVE_BLK_DESCRIBE -DHAVE_BLK_DROP
-DHAVE_BLK_ROWXFER_MULT -DHAVE_BLK_TEXTXFER -DHAVE_CT_CURSOR
-DHAVE_CT_DATA_INFO -DHAVE_CT_DYNAMIC -DHAVE_CT_SEND_DATA
-DHAVE_CT_SETPARAM -DHAVE_CS_CALC -DHAVE_CS_CMP -DHAVE_FREETDS=1
-UWANT_BULKCOPY -I/usr/include -I/usr/include/python2.5 -c sybasect.c
-o build/temp.linux-x86_64-2.5/sybasect.o
creating build/lib.linux-x86_64-2.5
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.5/blk.o
build/temp.linux-x86_64-2.5/databuf.o
build/temp.linux-x86_64-2.5/cmd.o build/temp.linux-x86_64-2.5/conn.o
build/temp.linux-x86_64-2.5/ctx.o
build/temp.linux-x86_64-2.5/datafmt.o
build/temp.linux-x86_64-2.5/iodesc.o
build/temp.linux-x86_64-2.5/locale.o
build/temp.linux-x86_64-2.5/msgs.o
build/temp.linux-x86_64-2.5/numeric.o
build/temp.linux-x86_64-2.5/money.o
build/temp.linux-x86_64-2.5/datetime.o
build/temp.linux-x86_64-2.5/date.o
build/temp.linux-x86_64-2.5/sybasect.o -o
build/lib.linux-x86_64-2.5/sybasect.so

Re: [Python-sybase-misc] [Fwd: Compiling sybase module staticly]

[David B. <Dav...@as...>]

have you looked at freetds.org ? It may free from ocs dependencies.

On Mon, Feb 16, 2009 at 4:09 PM, Greg Rudd <G....@is...> wrote:

> Hi all
>
> At present we are middle of a sybase database upgrade where we have the
> sybase python module compiled against the existing OCS libraries. What
> we want to do is have the module run indepently of the version of the
> OCS libraries as we will have both versions of sybase running at the
> same time, but having a look at the build_ext options of the setup.py
> script it doesn't appear to give any option for you to compile the
> module staticly.
>
> Does anyone have any ideas?
>
> Build envronment: RHEL 5.2 x86 64 bit
>
> Sybase OCS 12.5.x and 15.x
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Python-sybase-misc mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc
>



-- 
David Bear
College of Public Programs at ASU
602-464-0424

[Python-sybase-misc] [Fwd: Compiling sybase module staticly]

[Greg R. <G....@is...>]

Hi all

At present we are middle of a sybase database upgrade where we have the
sybase python module compiled against the existing OCS libraries. What
we want to do is have the module run indepently of the version of the
OCS libraries as we will have both versions of sybase running at the
same time, but having a look at the build_ext options of the setup.py
script it doesn't appear to give any option for you to compile the
module staticly. 

Does anyone have any ideas?

Build envronment: RHEL 5.2 x86 64 bit

Sybase OCS 12.5.x and 15.x
    

[Python-sybase-misc] problem to Install

[Raninho F. <ra...@ra...>]

Hi,

I installed ase1502_linux86_dev but don't have /opt/sybase/include

[root@Clementine sybase]# ls -la
total 216
drwxr-xr-x 22 root root  4096 Dez 18 12:30 .
drwxr-xr-x  6 root root  4096 Dez 17 16:31 ..
drwxr-xr-x  6 root root  4096 Dez 18 12:26 AMCP
drwxr-xr-x 16 root root  4096 Dez 18 12:30 ASE-15_0
-rw-r--r--  1 root root  1678 Dez 18 12:26 ASE150.csh
-rw-r--r--  1 root root   901 Dez 18 12:26 ASE150.env
-rw-r--r--  1 root root  1222 Dez 18 12:26 ASE150.sh
drwxr-xr-x  5 root root  4096 Dez 18 12:26 ASEP
drwxr-xr-x  5 root root  4096 Dez 18 12:26 DBISQL
drwxr-xr-x  3 root root  4096 Dez 18 12:26 DataAccess
drwxr-xr-x 12 root root  4096 Dez 18 12:25 OCS-15_0
drwxrwxr-x  5 root root  4096 Dez 18 12:26 RPL-15_0
-rw-r--r--  1 root root  1678 Dez 18 12:26 SYBASE.csh
-rw-r--r--  1 root root   901 Dez 18 12:26 SYBASE.env
-rw-r--r--  1 root root  1222 Dez 18 12:26 SYBASE.sh
drwxr-xr-x  6 root root  4096 Dez 18 12:26 SYSAM-2_0
drwxrwxr-x 14 root root  4096 Dez 18 12:26 UAF-2_0
drwxr-xr-x  8 root root  4096 Dez 18 12:30 WS-15_0
drwxrwxrwx  7 root root  4096 Dez 18 12:25 _jvm
drwxr-xr-x 58 root root  4096 Dez 18 12:26 charsets
drwxr-xr-x  3 root root  4096 Dez 18 12:26 collate
drwxr-xr-x  2 root root  4096 Dez 18 12:26 config
drwxr-xr-x  2 root root  4096 Dez 18 12:30 data
-rw-r--r--  1 root root   240 Dez 18 12:30 interf.old
-rw-r--r--  1 root root   376 Dez 18 12:30 interfaces
drwxr-xr-x  9 root root  4096 Dez 18 12:26 jConnect-6_0
drwxr-xr-x  4 root root  4096 Dez 18 12:26 jutils-2_0
drwxr-xr-x 14 root root  4096 Dez 18 12:26 locales
-rw-r--r--  1 root root 50185 Dez 18 12:30 log.txt
drwxr-xr-x  7 root root  4096 Dez 18 12:26 shared
drwxr-xr-x  3 root root  4096 Dez 18 12:26 uninstall
-rw-r--r--  1 root root 40793 Dez 18 12:26 vpd.properties

[root@Clementine python-sybase-0.39]# python setup.py install
Directory /opt/sybase/include does not exist - cannot build.
[root@Clementine python-sybase-0.39]#

help-me?

-- 
Positividade,

Raninho.
http://raninho.com.br
--
"Abstenha-se do Mal, faço o Bem e embeleze a sua mente" Buda

Re: [Python-sybase-misc] connect remote

[Phil E. <ph...@li...>]

Raninho Fernandes wrote:
> friends,
> 
> Sybase is my server on Windows and would like to connect remote, using 
> Linux (ArchLinux). I installed the pytho_sybase using the commands
> 
> python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
> python setup.py install
> 
> but tell the ip of the server to perform the remote connection?
> 

Take a look at either /etc/freetds.conf or /usr/local/etc/freetds.conf, 
depending upon how you compiled it.

-- 

Regards

Phil Edwards   |  PGP/GnuPG Key Id
Brighton, UK   |  0x68393AEE

[Python-sybase-misc] connect remote

[Raninho F. <ra...@ra...>]

friends,

Sybase is my server on Windows and would like to connect remote, using Linux
(ArchLinux). I installed the pytho_sybase using the commands

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

but tell the ip of the server to perform the remote connection?

-- 
Positividade,

Raninho.
http://raninho.com.br
--
"Abstenha-se do Mal, faço o Bem e embeleze a sua mente" Buda

Re: [Python-sybase-misc] connect remote

[Raninho F. <ra...@ra...>]

friends,

Sybase is my server on Windows and would like to connect remote, using Linux
(ArchLinux). I installed the pytho_sybase using the commands

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

but tell the ip of the server to perform the remote connection?


-- 
Positividade,

Raninho.
http://raninho.com.br
--
"Abstenha-se do Mal, faço o Bem e embeleze a sua mente" Buda

Re: [Python-sybase-misc] build on ubuntu8.04

[Iwan V. <iw...@re...>]

Hi Sébastien,

I am also trying to use python-sybase with freetds.

I have applied your patch (at
https://sourceforge.net/mailarchive/message.php?msg_name=48FDC4BF.5020802%40users.sourceforge.net )
(This was done by hand, not using patch.)

And successfully did a python setup.py install.

However, when I import Sybase in a python interpreter, I get the
following error:

>>> import Sybase
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-x86_64/egg/Sybase.py", line 11, in <module>
  File "build/bdist.linux-x86_64/egg/sybasect.py", line 7, in <module>
  File "build/bdist.linux-x86_64/egg/sybasect.py", line 6, in
__bootstrap__
ImportError: /home/iwan/.python-eggs/python_sybase-0.39-py2.5-linux-x86_64.egg-tmp/sybasect.so: undefined symbol: blk_alloc
>>

Any ideas?
(I'm on Ubuntu Hardy 64 bit, using freetds-dev 0.63-3.2ubuntu1)

I compiled it using these commands:
sudo apt-get install gcc python2.5-dev freetds-dev
Then, as root:
export SYBASE=/usr
export LD_LIBRARY_PATH=/usr:${LD_LIBRARY_PATH}
export CFLAGS="-DHAVE_FREETDS"
python setup.py install

Thanks
-i

Re: [Python-sybase-misc] Trying to connect to MSSQL on wrong port?

[Lloyd K. <py...@ve...>]

Did you migrate your /etc/freetds.conf file?


On Fri, 2008-10-24 at 08:32 -0500, Jonathan Hayward,
http://JonathansCorner.com wrote:
> Any hints? I searched for combinations of the last three lines of the
> error message, and couldn't find anything.

-- 
Lloyd Kvam
Venix Corp
DLSLUG/GNHLUG library
http://dlslug.org/library.html
http://www.librarything.com/catalog/dlslug
http://www.librarything.com/rsshtml/recent/dlslug
http://www.librarything.com/rss/recent/dlslug

Re: [Python-sybase-misc] Trying to connect to MSSQL on wrong port?

[Jonathan H. http://JonathansCorner.c. <chr...@gm...>]

P.S. It also bombs out if I try to specify port 1433:

>>> database = Sybase.connect("[deleted]:1433", "[deleted]", "[deleted]")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-i686/egg/Sybase.py", line 1194, in connect
  File "build/bdist.linux-i686/egg/Sybase.py", line 850, in __init__
  File "build/bdist.linux-i686/egg/Sybase.py", line 894, in connect
  File "build/bdist.linux-i686/egg/Sybase.py", line 250, in _clientmsg_cb
Sybase.DatabaseError: Layer: 0, Origin: 0
Unexpected EOF from the serverLayer: 0, Origin: 0
Adaptive Server connection failed
>>>

Any hints? I searched for combinations of the last three lines of the error
message, and couldn't find anything.

On Thu, Oct 23, 2008 at 1:58 PM, Jonathan Hayward,
http://JonathansCorner.com <chr...@gm...> wrote:

> I'm migrating a machine from Gentoo to Ubuntu (Intrepid), and am trying to
> get Sybase to talk to the database that the machine talked with before the
> upgrade.
>
> I'm running Ubuntu 8.0.4 with Python 2.5.2, Sybase 0.39, and Freetds 0.82.
> Sanitized output follows:
>
> >>> import Sybase
> >>> database = Sybase.connect("[deleted]", "[deleted]", "[deleted]")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "build/bdist.linux-i686/egg/Sybase.py", line 1194, in connect
>   File "build/bdist.linux-i686/egg/Sybase.py", line 850, in __init__
>   File "build/bdist.linux-i686/egg/Sybase.py", line 894, in connect
>   File "build/bdist.linux-i686/egg/Sybase.py", line 250, in _clientmsg_cb
> Sybase.DatabaseError: Layer: 0, Origin: 0
> Unable to connect: Adaptive Server is unavailable or does not exist
> >>>
>
> Prior to the migration, those two would execute without errors and I would
> be able to move on.
>
> My sysadmin looked at it with netstat and said that it's trying to talk on
> port 4000, not 1433 as it should be.
>
> How can I make sure that my installation is trying to talk to the MSSQL
> server on the standard port? (Or are there other likely suspects?)
>
> --
> -- Jonathan Hayward, chr...@gm...
>
> ** To see an award-winning website with stories, essays, artwork,
> ** games, and a four-dimensional maze, why not visit my home page?
> ** All of this is waiting for you at http://JonathansCorner.com
>
> ++ Would you like to curl up with one of my hardcover books?
> ++ You can now get my books from http://CJSHayward.com
>



-- 
-- Jonathan Hayward, chr...@gm...

** To see an award-winning website with stories, essays, artwork,
** games, and a four-dimensional maze, why not visit my home page?
** All of this is waiting for you at http://JonathansCorner.com

++ Would you like to curl up with one of my hardcover books?
++ You can now get my books from http://CJSHayward.com

[Python-sybase-misc] Trying to connect to MSSQL on wrong port?

[Jonathan H. http://JonathansCorner.c. <chr...@gm...>]

I'm migrating a machine from Gentoo to Ubuntu (Intrepid), and am trying to
get Sybase to talk to the database that the machine talked with before the
upgrade.

I'm running Ubuntu 8.0.4 with Python 2.5.2, Sybase 0.39, and Freetds 0.82.
Sanitized output follows:

>>> import Sybase
>>> database = Sybase.connect("[deleted]", "[deleted]", "[deleted]")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-i686/egg/Sybase.py", line 1194, in connect
  File "build/bdist.linux-i686/egg/Sybase.py", line 850, in __init__
  File "build/bdist.linux-i686/egg/Sybase.py", line 894, in connect
  File "build/bdist.linux-i686/egg/Sybase.py", line 250, in _clientmsg_cb
Sybase.DatabaseError: Layer: 0, Origin: 0
Unable to connect: Adaptive Server is unavailable or does not exist
>>>

Prior to the migration, those two would execute without errors and I would
be able to move on.

My sysadmin looked at it with netstat and said that it's trying to talk on
port 4000, not 1433 as it should be.

How can I make sure that my installation is trying to talk to the MSSQL
server on the standard port? (Or are there other likely suspects?)

-- 
-- Jonathan Hayward, chr...@gm...

** To see an award-winning website with stories, essays, artwork,
** games, and a four-dimensional maze, why not visit my home page?
** All of this is waiting for you at http://JonathansCorner.com

++ Would you like to curl up with one of my hardcover books?
++ You can now get my books from http://CJSHayward.com

Re: [Python-sybase-misc] build on ubuntu8.04

[Sébastien S. <sa...@us...>]

Hi Dave,

CS_DESCRIBE_OUTPUT is not really necessary if you only use the DBAPI 
interface of python-sybase. So I suppose you could try the following patch.

I plan to try Freetds in coming days to see how python-sybase behaves 
with it and if that could be improve. That being said, I think the 
priority is to have something working fine with the original sybase 
version of libraries, so if FreeTDS is not compatible in some way, it 
should be changed to behave like the reference.

regards

--
Sébastien Sablé

Index: cmd.c
===================================================================
--- cmd.c	(révision 443)
+++ cmd.c	(copie de travail)
@@ -612,10 +612,12 @@
  	/* ct_dynamic(CS_DESCRIBE_INPUT, dyn_id) -> status */
  	if (cmd_str == NULL)
  	    cmd_str = "CS_DESCRIBE_INPUT";
+#if 0
      case CS_DESCRIBE_OUTPUT:
  	/* ct_dynamic(CS_DESCRIBE_OUTPUT, dyn_id) -> status */
  	if (cmd_str == NULL)
  	    cmd_str = "CS_DESCRIBE_OUTPUT";
+#endif
      case CS_EXECUTE:
  	/* ct_dynamic(CS_EXECUTE, dyn_id) -> status */
  	if (cmd_str == NULL)
Index: sybasect.c
===================================================================
--- sybasect.c	(révision 443)
+++ sybasect.c	(copie de travail)
@@ -650,9 +650,11 @@
  #ifdef CS_DESCRIBE_INPUT
      SYVAL(VAL_DYNAMIC, CS_DESCRIBE_INPUT),
  #endif
+#if 0
  #ifdef CS_DESCRIBE_OUTPUT
      SYVAL(VAL_DYNAMIC, CS_DESCRIBE_OUTPUT),
  #endif
+#endif
  #ifdef CS_DYN_CURSOR_DECLARE
      SYVAL(VAL_DYNAMIC, CS_DYN_CURSOR_DECLARE),
  #endif



Dave Thiede a écrit :
> I'm trying to build the package on a 64bit install of ubuntu 8.04 against 
> freetds-dev 0.63 installed from the default repos. I am running into a 
> problem that i've seen reported before. There are symbols missing from 
> the freetds install that are in a sybase library which are referenced in 
> the pythong-sybase code base.
> 
> CS_DESCRIBE_OUTPUT
> 
> is one of them. there are others. In digging through the archives of 
> various places, I also saw this kind of thing reported back in 2001 
> against a freetds release. When looking through the includes for both 
> libraries I see that the macros have different values so it probably is 
> not possible to just add them from the sybase version.
> 
> Is there a workaround from the python-sybase side of things or do I need 
> to pursue this via the freetds lists? I do notice that the reported linux 
> builds are all against the sybase version of the libraries. It would be 
> nice to have a viable freetds implementation.
> 
> Dave
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-sybase-misc mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc

Re: [Python-sybase-misc] Regression in 0.39 Connection().execute()

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

>You should note however that Connection.execute is deprecated so that 
>you should probably plan to migrate to a cursor at some stage.

When I was working on my PostgreSQL adapter (ocpgdb), I initially added
a Connection.execute before I had implemented the Cursor logic, intending
to remove it when done. However, there are SQL statements that PostgreSQL
will not execute within a cursor which necessitates some mechanism for
sending commands not within a cursor. A Connection.execute method seems
like the most natural answer to me, so I've left it in. It's also quite
a bit faster for some operations, as it requires considerably less round
trips to the server.

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

Re: [Python-sybase-misc] Regression in 0.39 Connection().execute()

[Sébastien S. <sa...@us...>]

[Replying to all]

Hi Gregory,

sorry for the late reply, I have been very busy at work.

I will correct this bug for python-sybase 0.40 which should be released 
before the end of the year. I should be working nearly full time on 
python-sybase for the coming month.

You should note however that Connection.execute is deprecated so that 
you should probably plan to migrate to a cursor at some stage.

regards

-- 
Sébastien Sablé


Bond, Gregory a écrit :
> I’ve just added a bug for this: 
>  https://sourceforge.net/tracker/index.php?func=detail&aid=2165436&group_id=184050&atid=907701 
> <https://sourceforge.net/tracker/index.php?func=detail&aid=2165436&group_id=184050&atid=907701>
> 
> In previous versions (0.38 all the way back to 0.13!) we could do:
>     print db.execute('select 1,2,3')
>     [[(1, 2, 3)]]
> 
>     print db.execute('select 1,2,3 select 4,5')
>     [[(1, 2, 3)], [(4, 5)]]
> 
> In 0.39, execute() now uses a cursor under the hood and returns None. 
>  The use of a cursor means no multiple select statements :
>     print db.execute('select 1,2,3')
>     None
> 
>     print db.execute('select 1,2,3 select 4,5')
>     Traceback (most recent call last):
>         .....
>     Sybase.DatabaseError: Msg 3804, Level 16, State 1, Line 1
>     More than one SELECT statement is used to define the cursor 
> 'ctmp823fd0c'.
> 
> We depend fairly heavily on both behaviours (returning resultsets, 
> taking multiple select statements).
> 
> I’ve worked out a way to support /most/ of the old behaviour, with some 
> ugly hackery that looks inside Cursor objects (see the bug above), but 
> it’s not perfect.   The last remaining problem is multiple selects – it 
> mashes all the resultsets into one:
> 
>     print db.execute('select 1,2,3 select 4,5')
>     [[(1, 2, 3), (4, 5)]]
> 
> Any clues how to handle this?  Is this behaviour something that was 
> deliberately removed or would “we” be willing to patch this, if we can 
> come up with a method?
> 
> -- 
> *Gregory Bond
> Vice President
> Product Manager, Middle & Back Office Systems
> ITG Australia Limited
> Investment Technology Group, Inc.
> *--------------------------
> Level 3, Rialto North Tower
> 525 Collins Street
> Melbourne VIC 3000
> AUSTRALIA
> *
> *Ph. +61 3 9211 2518
> Fax: +61 3 9211 2599
> 
> www.itg.com
> 
> 
> ------------------------------------------------------------------------
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++
> The information contained in this communication is strictly confidential and intended solely for the use of the intended recipient(s). The copyright in this communication belongs to ITG Australia Ltd, ITG Hong Kong Limited, ITG Japan Limited, ITG Singapore Pte Ltd and/or their related entities, including Investment Technology Group, Inc., (collectively referred to as “ITG") and may contain information that is private, confidential or subject to legal professional or other privilege.  No confidentiality or privilege is waived or lost by any mis-transmission of this email.
> 
> Access to this email by anyone other than the intended recipient is unauthorized and further distribution of this email is strictly prohibited without the permission of ITG.  If you are not the intended recipient of this email, any review, disclosure, copying, distribution, retention or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient of this email, you should not disseminate, distribute or copy this e-mail and you should delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  ITG and/or its affiliates reserve the right to monitor and archive all electronic communications through its/their network.
> 
> The information contained in this email is believed to be accurate at the time of publication.  However, ITG disclaims all responsibility for any loss or damage howsoever arising as a result of any person or entity acting upon the information contained in this email and no liability will be accepted by ITG for any such loss or damage.  Any views expressed in this email are those of the individual sender, except where the email states otherwise and the sender is authorized to state them to be the views of ITG.
> ++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Python-sybase-misc mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc

[Python-sybase-misc] Regression in 0.39 Connection().execute()

[Bond, G. <Gre...@it...>]

++++++++++++++++++++++++++++++++++++++++++++++++
The information contained in this communication is strictly confidential and intended solely for the use of the intended recipient(s). The copyright in this communication belongs to ITG Australia Ltd, ITG Hong Kong Limited, ITG Japan Limited, ITG Singapore Pte Ltd and/or their related entities, including Investment Technology Group, Inc., (collectively referred to as “ITG") and may contain information that is private, confidential or subject to legal professional or other privilege.  No confidentiality or privilege is waived or lost by any mis-transmission of this email.

Access to this email by anyone other than the intended recipient is unauthorized and further distribution of this email is strictly prohibited without the permission of ITG.  If you are not the intended recipient of this email, any review, disclosure, copying, distribution, retention or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient of this email, you should not disseminate, distribute or copy this e-mail and you should delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  ITG and/or its affiliates reserve the right to monitor and archive all electronic communications through its/their network.

The information contained in this email is believed to be accurate at the time of publication.  However, ITG disclaims all responsibility for any loss or damage howsoever arising as a result of any person or entity acting upon the information contained in this email and no liability will be accepted by ITG for any such loss or damage.  Any views expressed in this email are those of the individual sender, except where the email states otherwise and the sender is authorized to state them to be the views of ITG.
++++++++++++++++++++++++++++++++++++++++++++++++

[Python-sybase-misc] build on ubuntu8.04

[Dave T. <Dav...@pn...>]

I'm trying to build the package on a 64bit install of ubuntu 8.04 against 
freetds-dev 0.63 installed from the default repos. I am running into a 
problem that i've seen reported before. There are symbols missing from 
the freetds install that are in a sybase library which are referenced in 
the pythong-sybase code base.

CS_DESCRIBE_OUTPUT

is one of them. there are others. In digging through the archives of 
various places, I also saw this kind of thing reported back in 2001 
against a freetds release. When looking through the includes for both 
libraries I see that the macros have different values so it probably is 
not possible to just add them from the sybase version.

Is there a workaround from the python-sybase side of things or do I need 
to pursue this via the freetds lists? I do notice that the reported linux 
builds are all against the sybase version of the libraries. It would be 
nice to have a viable freetds implementation.

Dave

Re: [Python-sybase-misc] Can't drop table without first closing cursor and connection

[Sébastien S. <sa...@us...>]

Hi Skip,

you need to either connect in auto_commit mode by using:

db = Sybase.connect('TEST', 'skip', 'xxxxxx', auto_commit=True)

or to manually commit after each execute or fetchall, using:

db.commit()

Your test should then work.

regards

--
Sébastien Sablé

sk...@po... a écrit :
> I have a simple test script which creates a table, inserts a row, selects
> the contents then deletes the table:
> 
>     import Sybase
> 
>     print Sybase.__version__
> 
>     db = Sybase.connect('TEST', 'skip', 'xxxxxx')
>     curs = db.cursor()
>     curs.execute("CREATE TABLE tempdb..skip (symbol CHAR(5))")
> 
>     dbvalues = (["A%d" % i] for i in range(10)) # this could be a recarray
>     curs.executemany("INSERT into tempdb..skip VALUES (@1)" , dbvalues)
>     curs.execute("SELECT * from tempdb..skip")
>     print curs.fetchall()
> 
>     # I'm not sure why I have to open a new cursor to drop the table. A bug?
>     #curs.execute("DROP TABLE tempdb..skip")
> 
>     curs.close()
>     db.close()
>     db = Sybase.connect('TEST', 'skip', 'xxxxxx')
>     curs = db.cursor()
>     curs.execute("DROP TABLE tempdb..skip")
>     curs.close()
>     db.close()
> 
> I've tried several variants of this code which would allow me to drop the
> table with the original cursor and database connection.  All fail in one way
> or another.  For example, if I comment out the db.close() and "db = ..."
> statements near the end I get this error executing the DROP TABLE statement:
> 
>     Sybase.DatabaseError: Msg 2762, Level 16, State 4, Line 1
>     The 'DROP TABLE' command is not allowed within a multi-statement
>     transaction in the 'tempdb' database.
> 
> (I'd display the traceback, but apparently because I've installed 0.39x
> using eggs it can't find the correct line/file information.  What I see
> references our antiquated 0.36 install (done pre-egg).)
> 
> Is this a feature of Sybase, and bug in the adapter or something else?
> 
> Thanks,
> 
> Skip
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Python-sybase-misc mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc

[Python-sybase-misc] Can't drop table without first closing cursor and connection

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

I have a simple test script which creates a table, inserts a row, selects
the contents then deletes the table:

    import Sybase

    print Sybase.__version__

    db = Sybase.connect('TEST', 'skip', 'xxxxxx')
    curs = db.cursor()
    curs.execute("CREATE TABLE tempdb..skip (symbol CHAR(5))")

    dbvalues = (["A%d" % i] for i in range(10)) # this could be a recarray
    curs.executemany("INSERT into tempdb..skip VALUES (@1)" , dbvalues)
    curs.execute("SELECT * from tempdb..skip")
    print curs.fetchall()

    # I'm not sure why I have to open a new cursor to drop the table. A bug?
    #curs.execute("DROP TABLE tempdb..skip")

    curs.close()
    db.close()
    db = Sybase.connect('TEST', 'skip', 'xxxxxx')
    curs = db.cursor()
    curs.execute("DROP TABLE tempdb..skip")
    curs.close()
    db.close()

I've tried several variants of this code which would allow me to drop the
table with the original cursor and database connection.  All fail in one way
or another.  For example, if I comment out the db.close() and "db = ..."
statements near the end I get this error executing the DROP TABLE statement:

    Sybase.DatabaseError: Msg 2762, Level 16, State 4, Line 1
    The 'DROP TABLE' command is not allowed within a multi-statement
    transaction in the 'tempdb' database.

(I'd display the traceback, but apparently because I've installed 0.39x
using eggs it can't find the correct line/file information.  What I see
references our antiquated 0.36 install (done pre-egg).)

Is this a feature of Sybase, and bug in the adapter or something else?

Thanks,

Skip

Re: [Python-sybase-misc] select into and v.039

[Stephen M. <mo...@gm...>]

Ah, yes, that seems to have worked as one would expect with the raw
sql.  Should this check be enriched for the next version perhaps?


On Thu, Jun 19, 2008 at 10:20 AM, Sébastien Sablé
<sa...@us...> wrote:
> Great, now can you try the following code (adding select=False at the end of
> execute):
>
> import apresdb
> c2 = apresdb.instance.cursor()
> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos,
> sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into
> tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId =
> iv0.ProdId", select=False)
>
>
> In python-sybase 0.39, the execute will activate the use of sybase cursors
> (ct_cursors) instead of commands when the request starts with "select".
>
> This is done because ct_cursor is the only way I know in Sybase to overlap
> requests, for example doing an update while retrieving the results of a
> select.
>
> The test which decide if we use a ct_cursor or not should probably be
> enriched.
>
> --
> Sébastien Sablé
>
>
> Stephen Mock a écrit :
>>
>> Ok, i did that and reinstalled version 3.9.  I'm still getting the
>> same error, but the traceback is definitely different.  Here's the
>> newest version of the error:
>>
>>>>> import apresdb
>>>>> c2 = apresdb.instance.cursor()
>>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos,
>>>>> sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into
>>>>> tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId =
>>>>> iv0.ProdId")
>>
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in ?
>>  File "build/bdist.linux-x86_64/egg/Sybase.py", line 546, in execute
>>  File "build/bdist.linux-x86_64/egg/Sybase.py", line 695, in _start
>>  File "build/bdist.linux-x86_64/egg/Sybase.py", line 709, in _mainloop
>>  File "build/bdist.linux-x86_64/egg/Sybase.py", line 753, in _raise_error
>> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
>> The statement used to define the cursor 'ctmp2a98a1e560' is neither a
>> SELECT nor an EXECUTE.
>>
>>
>>
>> On Thu, Jun 19, 2008 at 4:02 AM, Sébastien Sablé
>> <sa...@us...> wrote:
>>>
>>> Hi Stephen,
>>>
>>> are you sure that you are using python-sybase 0.39?
>>>
>>> sable@incubus:~/sybase/python-sybase-0.39$ grep -r _LAZY_END_RESULT *
>>> sable@incubus:~/sybase/python-sybase-0.39$
>>>
>>> I think your backtrace corresponds to a prior version of python-sybase.
>>>
>>> This may be linked to the use of setuptools in python-sybase 0.39.
>>> Setuptools will install a python_sybase-0.39-py2.4-linux-i686.egg file in
>>> your site-package, but not remove the old python-sybase files.
>>>
>>> I think this could be solved by removing in
>>> /apps/python/lib/python2.4/site-packages/
>>> the following files:
>>> Sybase.pyc
>>> Sybase.py
>>> sybasect*
>>>
>>> and then reinstalling version 0.39.
>>>
>>> Then we can see if there is still a problem.
>>>
>>> regards
>>>
>>> --
>>> Sébastien Sablé
>>>
>>> Stephen Mock a écrit :
>>>>
>>>> I recently upgraded to version .039 from .037 and am having a problem
>>>> with some basic sql.  It should create a temp table on the fly for me
>>>> to select from, but i get an error caused by the "select ... into"
>>>> statement.  It works perfectly fine with the older version.  Here's
>>>> the code:
>>>>
>>>>>>> import apresdb
>>>>>>> c2 = apresdb.instance.cursor()
>>>>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos,
>>>>>>> iv0.CurrPos,
>>>>>>> sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into
>>>>>>> tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where
>>>>>>> iv1.ProdId =
>>>>>>> iv0.ProdId")
>>>>
>>>> Traceback (most recent call last):
>>>>  File "<stdin>", line 1, in ?
>>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 546,
>>>> in execute
>>>>  self._set_state(_LAZY_END_RESULT)
>>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 695, in
>>>> _start
>>>>  if self._closed:
>>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 709,
>>>> in _mainloop
>>>>  # Send parameters.
>>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 753,
>>>> in _raise_error
>>>>  raise ProgrammingError('cursor is closed')
>>>> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
>>>> The statement used to define the cursor 'ctmp2a956073b0' is neither a
>>>> SELECT nor an EXECUTE.
>>>>
>>>>
>>>>
>>>> Any help would be greatly appreciated.
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Python-sybase-misc mailing list
>>>> Pyt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc
>>>
>
>

Re: [Python-sybase-misc] select into and v.039

[Sébastien S. <sa...@us...>]

Great, now can you try the following code (adding select=False at the 
end of execute):

import apresdb
c2 = apresdb.instance.cursor()
c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos, 
sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into 
tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId 
= iv0.ProdId", select=False)


In python-sybase 0.39, the execute will activate the use of sybase 
cursors (ct_cursors) instead of commands when the request starts with 
"select".

This is done because ct_cursor is the only way I know in Sybase to 
overlap requests, for example doing an update while retrieving the 
results of a select.

The test which decide if we use a ct_cursor or not should probably be 
enriched.

--
Sébastien Sablé


Stephen Mock a écrit :
> Ok, i did that and reinstalled version 3.9.  I'm still getting the
> same error, but the traceback is definitely different.  Here's the
> newest version of the error:
> 
>>>> import apresdb
>>>> c2 = apresdb.instance.cursor()
>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos, sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId = iv0.ProdId")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "build/bdist.linux-x86_64/egg/Sybase.py", line 546, in execute
>   File "build/bdist.linux-x86_64/egg/Sybase.py", line 695, in _start
>   File "build/bdist.linux-x86_64/egg/Sybase.py", line 709, in _mainloop
>   File "build/bdist.linux-x86_64/egg/Sybase.py", line 753, in _raise_error
> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
> The statement used to define the cursor 'ctmp2a98a1e560' is neither a
> SELECT nor an EXECUTE.
> 
> 
> 
> On Thu, Jun 19, 2008 at 4:02 AM, Sébastien Sablé
> <sa...@us...> wrote:
>> Hi Stephen,
>>
>> are you sure that you are using python-sybase 0.39?
>>
>> sable@incubus:~/sybase/python-sybase-0.39$ grep -r _LAZY_END_RESULT *
>> sable@incubus:~/sybase/python-sybase-0.39$
>>
>> I think your backtrace corresponds to a prior version of python-sybase.
>>
>> This may be linked to the use of setuptools in python-sybase 0.39.
>> Setuptools will install a python_sybase-0.39-py2.4-linux-i686.egg file in
>> your site-package, but not remove the old python-sybase files.
>>
>> I think this could be solved by removing in
>> /apps/python/lib/python2.4/site-packages/
>> the following files:
>> Sybase.pyc
>> Sybase.py
>> sybasect*
>>
>> and then reinstalling version 0.39.
>>
>> Then we can see if there is still a problem.
>>
>> regards
>>
>> --
>> Sébastien Sablé
>>
>> Stephen Mock a écrit :
>>> I recently upgraded to version .039 from .037 and am having a problem
>>> with some basic sql.  It should create a temp table on the fly for me
>>> to select from, but i get an error caused by the "select ... into"
>>> statement.  It works perfectly fine with the older version.  Here's
>>> the code:
>>>
>>>>>> import apresdb
>>>>>> c2 = apresdb.instance.cursor()
>>>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos,
>>>>>> sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into
>>>>>> tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId =
>>>>>> iv0.ProdId")
>>> Traceback (most recent call last):
>>>  File "<stdin>", line 1, in ?
>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 546,
>>> in execute
>>>   self._set_state(_LAZY_END_RESULT)
>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 695, in
>>> _start
>>>   if self._closed:
>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 709,
>>> in _mainloop
>>>   # Send parameters.
>>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 753,
>>> in _raise_error
>>>   raise ProgrammingError('cursor is closed')
>>> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
>>> The statement used to define the cursor 'ctmp2a956073b0' is neither a
>>> SELECT nor an EXECUTE.
>>>
>>>
>>>
>>> Any help would be greatly appreciated.
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Python-sybase-misc mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc
>>

Re: [Python-sybase-misc] select into and v.039

[Stephen M. <mo...@gm...>]

Ok, i did that and reinstalled version 3.9.  I'm still getting the
same error, but the traceback is definitely different.  Here's the
newest version of the error:

>>> import apresdb
>>> c2 = apresdb.instance.cursor()
>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos, sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId = iv0.ProdId")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "build/bdist.linux-x86_64/egg/Sybase.py", line 546, in execute
  File "build/bdist.linux-x86_64/egg/Sybase.py", line 695, in _start
  File "build/bdist.linux-x86_64/egg/Sybase.py", line 709, in _mainloop
  File "build/bdist.linux-x86_64/egg/Sybase.py", line 753, in _raise_error
Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
The statement used to define the cursor 'ctmp2a98a1e560' is neither a
SELECT nor an EXECUTE.



On Thu, Jun 19, 2008 at 4:02 AM, Sébastien Sablé
<sa...@us...> wrote:
> Hi Stephen,
>
> are you sure that you are using python-sybase 0.39?
>
> sable@incubus:~/sybase/python-sybase-0.39$ grep -r _LAZY_END_RESULT *
> sable@incubus:~/sybase/python-sybase-0.39$
>
> I think your backtrace corresponds to a prior version of python-sybase.
>
> This may be linked to the use of setuptools in python-sybase 0.39.
> Setuptools will install a python_sybase-0.39-py2.4-linux-i686.egg file in
> your site-package, but not remove the old python-sybase files.
>
> I think this could be solved by removing in
> /apps/python/lib/python2.4/site-packages/
> the following files:
> Sybase.pyc
> Sybase.py
> sybasect*
>
> and then reinstalling version 0.39.
>
> Then we can see if there is still a problem.
>
> regards
>
> --
> Sébastien Sablé
>
> Stephen Mock a écrit :
>>
>> I recently upgraded to version .039 from .037 and am having a problem
>> with some basic sql.  It should create a temp table on the fly for me
>> to select from, but i get an error caused by the "select ... into"
>> statement.  It works perfectly fine with the older version.  Here's
>> the code:
>>
>>>>> import apresdb
>>>>> c2 = apresdb.instance.cursor()
>>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos,
>>>>> sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into
>>>>> tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId =
>>>>> iv0.ProdId")
>>
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in ?
>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 546,
>> in execute
>>   self._set_state(_LAZY_END_RESULT)
>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 695, in
>> _start
>>   if self._closed:
>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 709,
>> in _mainloop
>>   # Send parameters.
>>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 753,
>> in _raise_error
>>   raise ProgrammingError('cursor is closed')
>> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
>> The statement used to define the cursor 'ctmp2a956073b0' is neither a
>> SELECT nor an EXECUTE.
>>
>>
>>
>> Any help would be greatly appreciated.
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Python-sybase-misc mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc
>
>

Re: [Python-sybase-misc] select into and v.039

[Sébastien S. <sa...@us...>]

Hi Stephen,

are you sure that you are using python-sybase 0.39?

sable@incubus:~/sybase/python-sybase-0.39$ grep -r _LAZY_END_RESULT *
sable@incubus:~/sybase/python-sybase-0.39$

I think your backtrace corresponds to a prior version of python-sybase.

This may be linked to the use of setuptools in python-sybase 0.39. 
Setuptools will install a python_sybase-0.39-py2.4-linux-i686.egg file 
in your site-package, but not remove the old python-sybase files.

I think this could be solved by removing in 
/apps/python/lib/python2.4/site-packages/
the following files:
Sybase.pyc
Sybase.py
sybasect*

and then reinstalling version 0.39.

Then we can see if there is still a problem.

regards

--
Sébastien Sablé

Stephen Mock a écrit :
> I recently upgraded to version .039 from .037 and am having a problem
> with some basic sql.  It should create a temp table on the fly for me
> to select from, but i get an error caused by the "select ... into"
> statement.  It works perfectly fine with the older version.  Here's
> the code:
> 
>>>> import apresdb
>>>> c2 = apresdb.instance.cursor()
>>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos, sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId = iv0.ProdId")
> Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 546,
> in execute
>    self._set_state(_LAZY_END_RESULT)
>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 695, in _start
>    if self._closed:
>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 709,
> in _mainloop
>    # Send parameters.
>  File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 753,
> in _raise_error
>    raise ProgrammingError('cursor is closed')
> Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
> The statement used to define the cursor 'ctmp2a956073b0' is neither a
> SELECT nor an EXECUTE.
> 
> 
> 
> Any help would be greatly appreciated.
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Python-sybase-misc mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-sybase-misc

[Python-sybase-misc] select into and v.039

[Stephen M. <mo...@gm...>]

I recently upgraded to version .039 from .037 and am having a problem
with some basic sql.  It should create a temp table on the fly for me
to select from, but i get an error caused by the "select ... into"
statement.  It works perfectly fine with the older version.  Here's
the code:

>>> import apresdb
>>> c2 = apresdb.instance.cursor()
>>> c2.execute("select iv0.ProdId, iv0.Account, iv0.StartPos, iv0.CurrPos, sum(iv1.StartPos) 'SumStartPos', sum(iv1.CurrPos) 'SumCurrPos' into tempdb..a_sum from  PortfolioInv iv0, PortfolioInv iv1 where iv1.ProdId = iv0.ProdId")
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 546,
in execute
   self._set_state(_LAZY_END_RESULT)
 File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 695, in _start
   if self._closed:
 File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 709,
in _mainloop
   # Send parameters.
 File "/apps/python/lib/python2.4/site-packages/Sybase.py", line 753,
in _raise_error
   raise ProgrammingError('cursor is closed')
Sybase.DatabaseError: Msg 3803, Level 16, State 1, Line 1
The statement used to define the cursor 'ctmp2a956073b0' is neither a
SELECT nor an EXECUTE.

>>>


Any help would be greatly appreciated.

Re: [Python-sybase-misc] release plans?

[Sébastien S. <sa...@us...>]

Hi Skip,

I am currently working on optimizing python-sybase and I should work 
quite a lot on it in coming weeks. I suppose I should have a new release 
a least by the end of August, probably before that.

Though the trunk is stable at the moment as far as I know and it 
actually solves a few bugs so you may try it.

regards

--
Sébastien Sablé



sk...@po... a écrit :
> Sébastien,
> 
> One of my colleagues at work is interested in the numeric paramstyle change
> which was committed hours after the 0.39 release.  I have painted myself
> into a corner in the past running with a patched version of 0.36, so I'm not
> inclined to simply patch 0.39 (or even to run from svn head).  Any ideas
> when you expect an 0.40 release?
> 
> Thanks,
> 

[Python-sybase-misc] release plans?

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

Sébastien,

One of my colleagues at work is interested in the numeric paramstyle change
which was committed hours after the 0.39 release.  I have painted myself
into a corner in the past running with a patched version of 0.36, so I'm not
inclined to simply patch 0.39 (or even to run from svn head).  Any ideas
when you expect an 0.40 release?

Thanks,

-- 
Skip Montanaro - sk...@po... - http://www.webfast.com/~skip/
"Be different, express yourself like everyone else."