mx.ODBC minor problem

Steve Holden steve at holdenweb.com
Fri Apr 13 09:23:25 EDT 2007


Greg Corradini wrote:
> Hello all,
> In a script i just wrote, my code calls a function createTables(), which
> checks for an existing table and then creates it, and then immediately calls
> selectSQL(), which selects from a different table and inserts on the table I
> just created (see below). 
> 
> However, I continue to get an Interface Error (see below) when i run it. And
> yet, if I allow the code to call createTables() and then manually call
> selectSQL() after a couple seconds, the thing works fine. In short, there's
> no mismatch in the number of parameters. Why would this be? I've never
> experienced this before. How can i restructure my code to resolve this
> problem? 
> ---
> CODE
> ---
> def createTables():
>     # Drop AddScript Table
>     try:
>         curse.execute('Drop table ' +countyname+'ADD_SCRIPT_TABLE')
>         conn.commit

It may not make any difference, but you should *call* commit() in the 
statement above rather than just referencing it.

>     except:
>         pass
>     # Create AddScript Table
>     curse.execute('Create table ' +countyname+'ADD_SCRIPT_TABLE'+ ' (TISCODE
> TEXT(12), STATUS TEXT(4))')
>     conn.commit()
> 
> def selectSQL():
>     sql = "Select TISCODE,STATUS from " +countyname+"0"+ " where STATUS =
> 'AS'"
>     curse.execute(sql)
>     a = curse.fetchall()
>     curse.executemany('Insert into ' +countyname+'ADD_SCRIPT_TABLE'+ '
> (TISCODE,STATUS) values (?,?)',x)

Shouldn't the second argument to executemany() be a, not x?

>     conn.commit()
> ---
> ERROR
> ---
> InterfaceError: mismatch in number of parameters; expected 2, found none

I find this whole thing a little disturbing. I keep asking myself why 
you are apparently maintaining entirely separate data structures for 
each county instead of having the county as a data item that can be used 
to select appropriate rows in the normal SQL way.

I suspect the correct way to proceed otherwise is to rectify the 
database design before going too much further. If there is any intention 
to be able to compare data across different counties, for example, you 
will be dead in the water doing it this way.

If this is someone else's crappy database design that you are obliged to 
deal with then please accept my apologies. If it's your crappy design 
then fix it ;-)

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Recent Ramblings       http://holdenweb.blogspot.com




More information about the Python-list mailing list