Re: [Zope] - ANNOUNCE: DCOracle release
Anthony Baxter wrote I'd guess that one of the results is larger than can fit in an integer, maybe?
Actually, it looks like it was in dealing with the input parameters, rather than the output ones - I found in ociCurs.py, around line 124, a piece of code that turns a number into an integer if it has no 'scale'. On commenting that out, it appears to work. If someone with a touch more knowledge than I can comment on the ramifications of that, it'd be appreciated ;)
also, if timestamp's a number, you don't need the ' 's around it.
Yeah, I know - I _did_ mention the example given was one of many attempts, right? ;) (quotes/noquotes * fmt/sqlvar * :float/:integer/nothing on input variables = many different possible combinations to assure myself it wasn't a dumb mistake in syntax ;) Oh, one other thing I wanted to double-check: In db.py (back in ZOracleDA), in the 'columns' method, there's the following code: def columns(self, table_name): c=self.cursor try: r=c.execute('select * from %s' % table_name) except: return () desc=c.description That looks like tempting fate to me... Is the 'select * from ' really not going to do bad things? (I'm presuming it doesn't actually trigger the db into _doing_ a 'select * from' unless it calls fetchone()) Is there a less, um, dangerous-looking way of getting the same result? I only ask because select * from most of the tables here would go away for a _very_ long time... KevinL --------------- qnevhf@obsu.arg.nh --------------- Kevin Littlejohn, Technical Architect, Connect.com.au Don't anthropomorphise computers - they hate that.
Kevin Littlejohn wrote:
Anthony Baxter wrote I'd guess that one of the results is larger than can fit in an integer, maybe?
Actually, it looks like it was in dealing with the input parameters, rather than the output ones - I found in ociCurs.py, around line 124, a piece of code that turns a number into an integer if it has no 'scale'. On commenting that out, it appears to work. If someone with a touch more knowledge than I can comment on the ramifications of that, it'd be appreciated ;)
The ramification is that all numbers are treated as floats. I think that oracledb treats all numbers as floats. IMO, if I have: create table spam (val integer); insert into spam values (1); select * from spam; I should get integers back in Python. Unfortunately, Oracle says that val is a number with precision 38 and scale 0. For most applications it should be OK to use integers, but sometimes it's not and it's hard (impossible) to determine when integers should be used without fetching the data first. :( I'll have to look at this. I should probably use Oracles NUMBER or VARNUM data types to fetch data and then convert to Python integers or longs, based on the values. If anyone wants to help out with this, I'd be happy to exchange information. (snip)
Oh, one other thing I wanted to double-check: In db.py (back in ZOracleDA), in the 'columns' method, there's the following code:
def columns(self, table_name): c=self.cursor try: r=c.execute('select * from %s' % table_name) except: return () desc=c.description
That looks like tempting fate to me... Is the 'select * from ' really not going to do bad things? (I'm presuming it doesn't actually trigger the db into _doing_ a 'select * from' unless it calls fetchone())
This is my understanding also.
Is there a less, um, dangerous-looking way of getting the same result?
It doesn't matter if it's dangerous looking if it's not actually dangerous. :) I use this approach based on a recommendation made for ODBC. The people who wrote Intersolve wrote a document on optimizing ODBC calls and recommended doing selects rather than using ODBC cataloging functions. This approach also has the bonus that it fails if you don't have access to the table, which is a good thing in some cases. :) Alternatively, an Oracle data dictionary table could be queried. I assume that this is six one half-a-dozen the other.
I only ask because select * from most of the tables here would go away for a _very_ long time...
Have you tried this? Have you tries calling columns for one of these tables? Jim -- 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.
participants (2)
-
Jim Fulton -
Kevin Littlejohn