Problem with dbi, odbc module and Oracle 9.2 - suffixed "L" with number data type

[dananrg at yahoo.com]

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:
> dananrg at yahoo.com 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