Re: FormBuilder / DO, mssql & identity columns

Joern Barthel wrote:

Hi Markus, Monday, September 15, 2003, 10:26:28 PM, you wrote: MW> Hmm... I fear I don't get your point here... why would anything want MW> to change a primary key at runtime? I use FormBuilder with MSSQL all MW> the time, and everything's fine. It's not about changing the primary key - say 'foo' is my primary key and identity column, 'bar' is of an arbitrary type. Tablename is fooTable. UPDATE: UPDATE fooTable SET foo = 1, bar = 99 WHERE fooTable.foo = 1 should be UPDATE fooTable SET bar = 99 WHERE fooTable.foo = 1 Same goes for INSERTs, naturally. When I choose to ignore the sequences the whole field is missing from the statement: UPDATE fooTable SET bar = 99

Ah, okay. Got your point. Never tried working w/o sequences.

MW> If you want to disable sequences, you should wait for the next CVS MW> version of DataObject which will allow to use auto values with MSSQL, MW> just like the auto_increment fields with MySQL. Then it's waiting for the CVS release I suppose.

Thanks to Alan it's there now, have a go.

Does this involve also an update to PEAR:DB? Hence there is no mssql_field_flags there is no support for 'auto_increment' yet (at least not in the most recent non-CVS release). Maybe the whole tableInfo method should be rewrote using 'sp_pkeys' and 'sp_columns' - this should cover the range of information gathered by the function. If desired I'd be happy to provide the coding.

An update of PEAR::DB is not neccessary, unless you want to recreate your classes / DB definition file by using the createTables script provided with DB_DataObject. If you specify the keys in that file by hand, or run the script against another database with a similar schema like MySQL, and then copy the resulting file over to your MSSQL installation (which is what I do) DataObject will work just fine. But in general I agree, the tableInfo() method should be improved. On the other hand, MDB might solve this and other problems in the future. CU Markus