johnf wrote:
> On Tuesday 09 January 2007 06:36, johnf wrote:
>> On Tuesday 09 January 2007 06:26, Ed Leafe wrote:
>>> On Jan 9, 2007, at 9:19 AM, johnf wrote:
>>>> Also I'm not to sure normal users have access to the
>>>> "information_schema". I
>>>> only know that access is assumed OK on public "sysobjects tables".
The spec says all users should have access to information_schema. I don't see
why they would be restricted to one but not the other.
>>> Even if they have complete unfettered access to information_schema,
>>> what good would it do for this query?
>>>
>>> select sum(orderitems.amount) as totalsales, ...
>>>
>>> Where will information_schema have anything about the 'totalsales'
>>> column in your cursor?
Ed, we are not talking about cursor.describe.
We are talking about
def getFields(self, tableName):
""" Returns the list of fields of the passed table
Notice the tableName parameter - it only applies to tables, not queries.
Also look at the current (stable or trunk) version in dbMySql - it uses
DESCRIBE, which will have no idea of your query either.
>> Did a little research on the web. I'm GUESSSSSSING. Carl are you using
>> information_schema table to comply with SQL 92???? There is a good article
>> at http://www.dbazine.com/db2/db2-disarticles/pelzer4. So Carl may be
>> doing the right thing. I'm using sysobjects tables and not the
>> information_schema table. However, many of the database engine do NOT
>> provide a "
>> information_schema table" (Oracle is one)
Basically, yes.
But I didn't write it just to comply, I wrote it because the code was simpler
than the version that used DESCRIBE. the fact that it is portable between
MySql
and MsSql was a nice side effect.
>>
>> As far as the code - I'll have to see what he is doing and why. But if the
>> " information_schema table" provides what we need then I think it make
>> sense to use it. Of course I'm not to sure I would have committed without
>> discussion.
>
> Damm, I spoke to soon. "information_schema table" is only available on V7
> and above. We had a similar problem with Postgres where I provided code for
> both an old version and the new versions.
>
> My "sysobjects tables" code works with all the versions. What do you guys
> want to do?????
I have no interest in ever working with a mssql V6.5. I did it once a few
years
ago, that system has been upgraded to 2000.
If anyone has any interest in supporting pre v7, make a class
MSSQLlegacy(MSSQL): that is nothing but the getFields() that uses sysobjects.
> OK. But all Carl is doing is passing the database name into the connection
> string - right?
close. to be precise: I am assuming the database name got passed when the
connection was created, and storing that so that I can use it in the queries.
> When I said his code change will not hurt - I mean the
> providing the database name. I still see no reason to do this.
Here is the reason: information_schema is a db that covers all the db's on the
server. sysobjects is a table in each db, so what ever the current db is will
define which sysobjects table gets used. So your code wouldn't have errored.
(I was thinking there was one central sysobjects table.)
Carl K
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
