OK, so I have an identity column many of my tables. For osme of what I do, I need to select some stuff, and then provide links to search further, based upon this unique id field (identity is a numeric). Normally not a problem...however, the number is returned as: "1L" or "2L", as opposed to "1" or "2". FWICS, this is somehow being reported as a 'long' int, hence the 'L'. Unfortunately, the breaks things, since you cannot get a list of rows, and then serach on the database using the identity section form the result (The actual entry doesn't contain any alpha characters). I have encountered this on HPUX and Linux, and on multiple servers. Anyone have a workaround or fix? Preferable one that does not involve using DTML to strip out the 'L'? TIA, Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
On 1/2/00 12:52 AM, Bill Anderson at bill.anderson@libc.org wrote:
OK, so I have an identity column many of my tables. For osme of what I do, I need to select some stuff, and then provide links to search further, based upon this unique id field (identity is a numeric). Normally not a problem...however, the number is returned as: "1L" or "2L", as opposed to "1" or "2". FWICS, this is somehow being reported as a 'long' int, hence the 'L'. Unfortunately, the breaks things, since you cannot get a list of rows, and then serach on the database using the identity section form the result (The actual entry doesn't contain any alpha characters).
I have encountered this on HPUX and Linux, and on multiple servers.
Anyone have a workaround or fix? Preferable one that does not involve using DTML to strip out the 'L'?
Well, not a real work-around, but at least an explanation of what happens, and why you get the 1L. The reason is that when Sybase returns a field, it also returns it's "type", and when that type is numeric, we have three choices: Python integer Python long integer (the L) Python float We make this decision based on the precision and scale of the column, NOT fo the returned value. Anything that has a scale of >0 is a float. If it's scale is 0, then if the precision is greater than 9, we move to long integers to store it. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Christopher Petrilli wrote:
On 1/2/00 12:52 AM, Bill Anderson at bill.anderson@libc.org wrote:
OK, so I have an identity column many of my tables. For osme of what I do, I need to select some stuff, and then provide links to search further, based upon this unique id field (identity is a numeric). Normally not a problem...however, the number is returned as: "1L" or "2L", as opposed to "1" or "2". FWICS, this is somehow being reported as a 'long' int, hence the 'L'. Unfortunately, the breaks things, since you cannot get a list of rows, and then serach on the database using the identity section form the result (The actual entry doesn't contain any alpha characters).
I have encountered this on HPUX and Linux, and on multiple servers.
Anyone have a workaround or fix? Preferable one that does not involve using DTML to strip out the 'L'?
Well, not a real work-around, but at least an explanation of what happens, and why you get the 1L. The reason is that when Sybase returns a field, it also returns it's "type", and when that type is numeric, we have three choices:
Python integer Python long integer (the L) Python float
We make this decision based on the precision and scale of the column, NOT fo the returned value. Anything that has a scale of >0 is a float. If it's scale is 0, then if the precision is greater than 9, we move to long integers to store it.
Because we can use regular integers if the precision is less than 10. If you need a string without the trailing 'L', then use the %d string format, as in '%d' % v. Jim P.S. Python 1.6 will not add the trailing 'L' character when converting longs to strings, except when the repr built-in function or operator is used. That will make this issue go away. -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote:
Christopher Petrilli wrote:
...
We make this decision based on the precision and scale of the column, NOT fo the returned value. Anything that has a scale of >0 is a float. If it's scale is 0, then if the precision is greater than 9, we move to long integers to store it.
Because we can use regular integers if the precision is less than 10.
If you need a string without the trailing 'L', then use the %d string format, as in '%d' % v.
Jim
P.S. Python 1.6 will not add the trailing 'L' character when converting longs to strings, except when the repr built-in function or operator is used. That will make this issue go away.
Thanks for the info. Makes things a bit easier. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
participants (3)
-
Bill Anderson -
Christopher Petrilli -
Jim Fulton