On Feb 11, 2008, at 2:51 PM, Mike wrote:
> DatabaseError: internal error: SQL Server message 8106, severity 16, > state 1, line 1: > Table 'tbl_TimeEntries' does not have the identity property. Cannot > perform SET operation. > DB-Lib error message 10007, severity 5: > General SQL Server error: Check messages from the SQL Server. > > > Upon digging in Google and Microsoft's pages, it seems that SQLAlchemy > is trying to use the SET IDENTITY_INSERT setting for a column that > doesn't have this setting. Why is it doing that in the first place and > how to I stop that behavior? im not the MS-SQL guy but it appears that normally, when inserting a column which is an autoincrementing integer value, MS-SQL requires that you call SET IDENTITY_INSERT for the table overall (i.e. not any particular column) in order to allow the insert to proceed. The SQLA driver does this when it sees that an integer value is being sent in, and turns it off after the insert completes. In this case, if the empid column does not have autoincrmenting behavior on the MS-SQL side, configure the Column object with "autoincrement=False". Normally autoincrement is assumed to be True on a primary key integer-holding column. Looking at the source it appears this should prevent the identity insert step from happening. > > > Also, as you may notice, I have two columns set as the primary key. Is > that the correct way to create a composite primary key? yes this is fine. The other option would be to use the PrimaryKeyConstraint construct explicitly but the twin "primary_key" flags have the same effect. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
