thanks micheal - the only reason we went with 3.11 was the following
statement on the wiki:
"Currently (Aug 2007) the 0.4 branch has a number of problems with MS-
SQL."
http://www.sqlalchemy.org/trac/wiki/DatabaseNotes#MS-SQL
I checked the logs and it does have to do with the MS-SQL ID
generation, so I'll readup on that.
--------------------------------------------------------
2008-01-11 14:19:31,292 INFO sqlalchemy.engine.base.Engine.0x..30
SELECT shot.[skuId], shot.number, shot.name, shot.description, shot.
[teamCategory], shot.comments, shot.props, shot.time, shot.talent,
shot.source, shot.id, shot.now, shot.[rowNumber]
FROM shot
WHERE shot.id IS NULL
---------------------------------------------------------
cheers
On Jan 11, 1:46 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008, at 4:37 PM, Dean Halford wrote:
>
>
>
>
>
> > Thanks for the responses guys. The PassiveDefault("") parameter did
> > exactly what I wanted it to do - which was to exclude that column from
> > the generated insert query so that MS SQL could handle those on it's
> > own.
>
> > ... now to figure out why I am getting an unsubscriptable object type
> > error from the operation:
> > -----------------------------------
> > ...
> > File "c:\python24\lib\site-packages\sqlalchemy-0.3.11-py2.4.egg
> > \sqlalchemy\orm\mapper.py", line 1255, in _postfetch
> > self.set_attr_by_column(obj, c, row[c])
> > TypeError: unsubscriptable object
> > -----------------------------------
>
> > the comments for the _postfetch method indicate that it is checking to
> > see if 'PassiveDefaults' were fired off on the insert. It looks the
> > row[c] operation is breaking as the row object doesn't support []
> > subscripting... could be a bug?
>
> rows are subscriptable so that means its getting None back. so its a
> bug that its not handling that more gracefully...but also, should be
> getting a row back. you should see in your SQL logs that a SELECT
> is being issued right after a series of INSERT/UPDATE statements for
> that table - if the SELECT queries for a primary key of NULL that may
> mean that the default-id-generation scheme in use is not working
> (either not genning an ID or not telling the result about it
> correctly)....i know on MS-SQL the default ID generation schemes are
> quite complex. we'll see what Rick says but its possible things would
> work a whole lot better if you were using sqlalchemy 0.4.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
