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-in
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
> synchron
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
'so
That's unfortunate because our database is built around MS GUIDs and
not integer PKs, but good to know.
I am just using pythoncom.CreateGuid() to generate the object ids
before insert and that is working great.
thanks for all the help
On Jan 11, 2:45 pm, "Rick Morrison" <[EMAIL PROTECTED]> wro
its updated. Dean, try to get on 0.4 !
On Jan 11, 2008, at 5:45 PM, Rick Morrison wrote:
> 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
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
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
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 o
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 th
On Jan 10, 2008, at 9:15 PM, deanH wrote:
>
> Hello,
>
> I am having a problem inserting an object into a MS SQL table that
> contains a timestamp field (now) that is generated automatically -
> sqlalchemy is defaulting this column to None and when it is generating
> the SQL insert. Is there a
I'm not sure I understand what you're looking for...you want the column to
remain NULL after an insert?
Then take off the default from the column definition and make it a datetime
field instead of a timestamp.
On Jan 10, 2008 9:15 PM, deanH <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I am having
11 matches
Mail list logo
