Whether the key column can be updated in place or the row has to be deleted and reinserted. This value determines the syntax PowerBuilder generates when a user modifies a key field: Yes – Use the UPDATE statement when the key is changed so that the key is updated in place.

The SQL generated by the DataWindow is controlled by the Update Properties (menu item Rows / Update Properties.). From there, you can select a single table and set the properties that it will use to generate the SQL. Where Clause.

Determines which columns and their original values are used in the WHERE clause for UPDATEs and DELETEs. Key modification only comes into play when you change (or allow the user to change) columns that you've defined as key. Updatable Columns is the list of what will generate SQL (this doesn't affect what the UI allows one way or the other).

Key columns can be the Primary key (which can be auto-populated with the Primary Key button, if you're DBMS supports the calls to query that from the database), but it doesn't have to be. (There are fairly unique cases where you might want to do something different.) If you've got an identity column as your key, you can identify that to your DataWindow and it will retrieve the generated value after an INSERT. After that, populating the data in the DataWindow with InsertRow(), DeleteRow(), SetItem() and, of course, letting the user at the UI, will be changing data and status flags that will determine the SQL generated when Update() is called. All these can be changed at run time with the Modify() function, so you can do things like update multiple tables with one DataWindow. This is implemented in PowerBuilder Foundation Class's multi-table update service, so if you ever want to change these values at run time, that's some good sample code. Good luck, Terry. If test_id is an identity/auto-increment column, you just need to declare that in the Update Properties.

If it's a value you populate yourself, you'll have to programmatically do a SetItem() on the new row for column 'test_id'. The rules for generating the value may determine whether you can set the value at the same time as InsertRow(), or on the UpdateStart event. If you want to use ModifiedCount() to determine if a save is necessary, you might want to postpone the SetItem() until after that function call. (For bonus marks, Modify() the DW column's Initial attribute. No spc2xpln.) – Jun 15 '10 at 14:38.

The behaviour of 'key and modified' seems incoherent. Example: on a DW with 'key and modified' option. I modify a column selected in the 'update' list: update() is sending the correct update to the db. CORRECT I modify a column NOT selected in the 'update' list: update() is NOT sending any update to the db.

CORRECT If I modify both columns, the update send to the dw contains 'where col1 = 'xxx' and col2 = 'yyy' ': INCORRECT Why does PB make a difference between thoses cases? I found an old post by Stephen Dupre / Simon Caldwell; dated 1998 where a similar problem is shown.

Intel q45/q43 express chipset. Is this fixed? Or will it be? Extract of the old post From: 'Simon Caldwell' Subject: Re: Key and Modified Columns Bug Date: 1998/08/27 Why can't the functionality be changed then? Surely it shouldn't be too hard to add a 'key and modified updateable columns' option?

Simon Stephen Dupre[Sybase] wrote in message >This is a bad GUI problem but not a bug. For Rows/Update specifications >we left this as a feature (the ability to generate something in the >where clause for ANY column that's modified - even a named computed >column). The problem is the UI (selected columns in the listbox) >doesn't reflect the where clause than can be generated. > >I tried to get development to change the UI for 5.0 - basically when the >user clicks 'key and modified' to 'grey out' the listbox so it's clear >that nothing the developer selected there matters now - only that >whatever columns are left open and editable will end up in the where >clause if modified.