python-sybase-misc

[Python-sybase-misc] CentOS 5 Install and Usage

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

Hi All:

I've built and installed python-sybase v0.38 on a freshly installed 
CentOs5 machine and I have a couple of issues I;d appreciate some 
feedback on:

1. Due to CentOS installing the FreeTDS header files in a slightly odd 
location, I had to modify the setup.py script in order for the build_ext 
process to work. It would probably be helpful to submit the changes to 
the developers, so should I post my modifications here or direct to the 
dev team?

2. I have a very simple-minded test script which reads a single row of 
data out of our customer database:

db = Sybase.connect(DBNAME, DBUSER, DBPASS)
con = db.cursor()
con.execute("qGetDomain @Domain='linux2000.com'")
result = con.fetchall()
for line in result: print str(line)

This code throws an exception on the call to fetchall(). The error text 
doesn't seem to give any useful information:

   File "./crmtest.py", line 27, in ?
     result = con.fetchall()
   File "/usr/lib/python2.4/site-packages/Sybase.py", line 831, in fetchall
     return self._fetcher.fetchall()
   File "/usr/lib/python2.4/site-packages/Sybase.py", line 605, in fetchall
     row = self.fetchone()
   File "/usr/lib/python2.4/site-packages/Sybase.py", line 555, in fetchone
     self._fetch_rowcount()
   File "/usr/lib/python2.4/site-packages/Sybase.py", line 682, in 
_fetch_rowcount
     self._raise_error(Error, 'ct_results')
   File "/usr/lib/python2.4/site-packages/Sybase.py", line 519, in 
_raise_error
     raise exc(text)
Sybase.Error: ct_results

Oddly, a call to fetchone() works as expected. Is there any reason why 
calling fetchall() with only a single row in the result set should fail 
like this?

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Python-sybase-misc] CentOS 5 Install and Usage

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

Phil Edwards wrote:
> 
> I've built and installed python-sybase v0.38 on a freshly installed 
> CentOs5 machine and I have a couple of issues I;d appreciate some 
> feedback on:
> 

I forgot to mention that the FreeTDS version which is installed is 0.64, 
this from the standard CentOS5 RPMs:

# rpm -qa|grep -i tds
freetds-0.64-1.el5.rf
freetds-devel-0.64-1.el5.rf

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Python-sybase-misc] CentOS 5 Install and Usage

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

Phil Edwards wrote:
> Phil Edwards wrote:
>> I've built and installed python-sybase v0.38 on a freshly installed 
>> CentOs5 machine and I have a couple of issues I;d appreciate some 
>> feedback on:
>>

I've now found that v0.37 works on my CentOS server, so the problem is 
definitely being caused by something in v0.38

> 
> I forgot to mention that the FreeTDS version which is installed is 0.64, 
> this from the standard CentOS5 RPMs:
> 
> # rpm -qa|grep -i tds
> freetds-0.64-1.el5.rf
> freetds-devel-0.64-1.el5.rf
> 


-- 

Regards

Phil Edwards
Brighton, UK

Re: [Python-sybase-misc] CentOS 5 Install and Usage

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

Sébastien Sablé wrote:
> Hi Phil,
> 
> You can post your patch here.
> 

Probably not the prettiest code, but it seems to work. The issue being 
worked around is that on CentOS5 the FreeTDS header files get installed 
in /usr/include/freetds rather than /usr/include.

-----begin diff output-----
--- setup.py.org        2007-11-08 16:59:42.000000000 +0000
+++ setup.py    2007-11-08 17:23:23.000000000 +0000
@@ -85,9 +85,16 @@
          'mail to dj...@ob... so you can help other people.\n')
      sys.exit(1)

-syb_incdir = os.path.join(sybase, 'include')
+# fixes to make compilation work on CentOS5
+_incdirs = []
+_incdirs.append(os.path.join(sybase, 'include'))
+_incdirs.append(os.path.join(_incdirs[0], 'freetds'))
+
+syb_incdir = _incdirs
  syb_libdir = os.path.join(sybase, 'lib')
-for dir in (syb_incdir, syb_libdir):
+_dirs = syb_incdir
+_dirs.append(syb_libdir)
+for dir in _dirs:
      if not os.access(dir, os.F_OK):
          sys.stderr.write('Directory %s does not exist - cannot 
build.\n' % dir)
          sys.exit(1)
@@ -146,15 +153,20 @@

  for api in ('blk_alloc', 'blk_describe', 'blk_drop', 'blk_rowxfer_mult',
              'blk_textxfer',):
-    if api_exists(api, os.path.join(syb_incdir, 'bkpublic.h')):
-        syb_macros.append(('HAVE_' + string.upper(api), None))
+    for dir in syb_incdir:
+       if api_exists(api, os.path.join(dir, 'bkpublic.h')):
+            syb_macros.append(('HAVE_' + string.upper(api), None))
+
  for api in ('ct_cursor', 'ct_data_info', 'ct_dynamic', 'ct_send_data',
              'ct_setparam',):
-    if api_exists(api, os.path.join(syb_incdir, 'ctpublic.h')):
-        syb_macros.append(('HAVE_' + string.upper(api), None))
+    for dir in syb_incdir:
+        if api_exists(api, os.path.join(dir, 'ctpublic.h')):
+            syb_macros.append(('HAVE_' + string.upper(api), None))
+
  for api in ('cs_calc', 'cs_cmp',):
-    if api_exists(api, os.path.join(syb_incdir, 'cspublic.h')):
-        syb_macros.append(('HAVE_' + string.upper(api), None))
+    for dir in syb_incdir:
+        if api_exists(api, os.path.join(dir, 'cspublic.h')):
+            syb_macros.append(('HAVE_' + string.upper(api), None))

  class PreReleaseCheck:
      def __init__(self, distribution):
@@ -207,7 +219,7 @@
        description="Sybase Extension to Python",
        url="http://python-sybase.sourceforge.net/",
        py_modules=['Sybase'],
-      include_dirs=[syb_incdir],
+      include_dirs=syb_incdir,
        ext_modules=[
            Extension('sybasect',
                      ['blk.c', 'databuf.c', 'cmd.c', 'conn.c', 'ctx.c',
------end diff output------

> Concerning your problem, I think it is a known bug when calling a stored 
> procedure with execute.
> Could you try con.callproc("qGetDomain @Domain='linux2000.com'") instead 
> of con.execute?
> 

Cool, I'll give that a try and see how I get on. Thanks.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Python-sybase-misc] CentOS 5 Install and Usage

[<sa...@us...>]

Hi Phil,

You can post your patch here.

Concerning your problem, I think it is a known bug when calling a stored
procedure with execute.
Could you try con.callproc("qGetDomain @Domain='linux2000.com'") instead
of con.execute?

If it works, then the problem is probably corrected in trunk. I have an
alpha version of python-sybase 0.39 on its way with many changes, but I
still need to finish a few things before to release it.

regards

--
Sébastien Sablé

Phil Edwards a écrit :
> Hi All:
> 
> I've built and installed python-sybase v0.38 on a freshly installed 
> CentOs5 machine and I have a couple of issues I;d appreciate some 
> feedback on:
> 
> 1. Due to CentOS installing the FreeTDS header files in a slightly odd 
> location, I had to modify the setup.py script in order for the build_ext 
> process to work. It would probably be helpful to submit the changes to 
> the developers, so should I post my modifications here or direct to the 
> dev team?
> 
> 2. I have a very simple-minded test script which reads a single row of 
> data out of our customer database:
> 
> db = Sybase.connect(DBNAME, DBUSER, DBPASS)
> con = db.cursor()
> con.execute("qGetDomain @Domain='linux2000.com'")
> result = con.fetchall()
> for line in result: print str(line)
> 
> This code throws an exception on the call to fetchall(). The error text 
> doesn't seem to give any useful information:
> 
>    File "./crmtest.py", line 27, in ?
>      result = con.fetchall()
>    File "/usr/lib/python2.4/site-packages/Sybase.py", line 831, in fetchall
>      return self._fetcher.fetchall()
>    File "/usr/lib/python2.4/site-packages/Sybase.py", line 605, in fetchall
>      row = self.fetchone()
>    File "/usr/lib/python2.4/site-packages/Sybase.py", line 555, in fetchone
>      self._fetch_rowcount()
>    File "/usr/lib/python2.4/site-packages/Sybase.py", line 682, in 
> _fetch_rowcount
>      self._raise_error(Error, 'ct_results')
>    File "/usr/lib/python2.4/site-packages/Sybase.py", line 519, in 
> _raise_error
>      raise exc(text)
> Sybase.Error: ct_results
> 
> Oddly, a call to fetchone() works as expected. Is there any reason why 
> calling fetchall() with only a single row in the result set should fail 
> like this?
>