MSSQL ID generation is limited to integer PKs of the IDENTITY type, and they work fine in 0.4 series. That wiki page should be updated.
It's most likely a case of the Table not knowing that the PK should be an auto-increment type. Are you defining the table via an SA Table() definition, or trying to autoload the definition via table reflection? On Jan 11, 2008 5:23 PM, Dean Halford <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
