Great, thanks Diez! Should I just use str(n) to convert it to a format I can write out to a flat file? I'm also struggling with the strange date object format that the ODBC module returns when I fetch rows. I need to convert that to a text string in a format that a mainframe flatfile database requires. Any advice there?
Diez B. Roggisch wrote: > [EMAIL PROTECTED] wrote: > > > I was messing around with the native ODBC module (I am using Python in > > a Win32 environment), e.g: > > > > import dbi, odbc > > > > ...and it seems to meet my needs. I'd rather use a module that comes > > natively with Python if it works (don't care about performance in this > > particular use case; just that it works). > > > > The only issue I've had so far is retrieving data from Oracle when an > > integer has been defined like: > > > > number(p) [same thing as number(p,0) evidently] > > > > This is from a database I didn't design and can't change. Evidently > > there are new ways to declare integer data types in Oracle. > > > > The problem is that the ODBC module suffixes an "L" to any integer > > returned that > > was defined as data type number(p). For example, an integer stored as: > > 56 will be returned as 56L. Actually, it now seems to be doing the > > same thing, at least in some cases, for number data types declared as > > number(p,s). What gives? Anyone know why this would happen? > > Well, it is a legal python umber literal. Fire up your python interpreter > and do > > >>> long(1) > 1L > > It simply says that it is a long, not an int (which means 64 rather than 32 > bits of precision I think) > > So - no need to worry. > > Diez -- http://mail.python.org/mailman/listinfo/python-list
