Good points - although restructuring the database around integer PKs is out of the question at the moment and we also need to support operations where 'road shoot' databases are merged into our master database... so we do have one legitimate use for GUIDs :)
If I run across a way to fetch auto-inserted GUIDs from MSSQL, I'll bring it forward.. but for now generating the id before insertion seems to be the way to go. cheers On Jan 12, 4:42 am, Ants Aasma <[EMAIL PROTECTED]> wrote: > On Jan 12, 4:43 am, "Rick Morrison" <[EMAIL PROTECTED]> wrote: > > > My experience with GUID PKs is that they almost always cause more troubles > > than they purport to solve, and 99% of the time a plain Integer PK will work > > just fine instead. The two rare exceptions are with multi-database > > synchronization (and even there integer PKs can work fine with an additional > > 'source' discriminator column) and humungo databases where overflowing a > > bigint col is a real fear. > > A bit offtopic, but I can't imagine a situation where overflowing a > bigint col would > be feasible. Even if you generate 1 billion rows per second, you still > have about > 300 years worth of keys available. > > Ants Aasma --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
