× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Bear with me if this question really belongs on the pyodbc issue tracker.

I am using pyodbc to connect to our i from my PC, and overall it works
very well. My issue is that when I try to retrieve source members from
various files, it seems to assume SRCDTA is the same length in all the
files, rather than sometimes 100 (for our RPGLE members) and sometimes
80 (for other types). For example:

### begin

from getpass import getuser, getpass

import pyodbc

members = [
'DEVSRC.QDDSSRC(FOO)',
'DEVSRC.QRPGLESRC(BAR)']

connection = pyodbc.connect(
driver='{iSeries Access ODBC Driver}',
system='10.nn.nn.nn',
uid=getuser(),
pwd=getpass())

for member in members:
print(repr(member))
cursor = connection.cursor()
cursor.execute("create alias qtemp.mbr for {}".format(member))
cursor.execute('select * from qtemp.mbr')
for t in cursor.description:
print(t)
cursor.execute('drop alias qtemp.mbr')
cursor.close()

### end

When I run the above, I see that SRCDTA is 80 characters for both
members, when really it should be 100 for the RPGLE member. If I try
to fetch data, I only get 80 characters for both members. It's worse
in the other direction: If I swap the order and try to fetch BAR
first, then pyodbc is convinced that both members are 100 characters,
so the first row pulled from FOO contains not only the 80 characters
that really are in SRCDTA, but also the 6 bytes in the next SRCSEQ,
the 6 bytes in the next SRCDAT, and the first 8 bytes of the next
SRCDTA (to fill out the 100 bytes). It gets progressively worse from
there.

Any idea how to remedy this? I purposely closed and recreated the
cursor after each member hoping to remove any caching; I believe the
typical practice is to just create the cursor once outside the loop
and reuse it.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.