Primary Key Changes on Update

[Steve Workings]

Puzzled.
I have a UX that is re-assigning the primary key in Update actions.

Consider this code in the AfterDialogValidate:

save_to_file("Primary Key: " + e.dataSubmitted.ID + crlf(), "c:\AppLog.txt", .t.)
ExecuteServerSideAction("Save Data::Submit")
nPK = convert_type(e.rtc.primaryTablePrimaryKey,"N")
save_to_file("Primary Key: " + nPK + crlf(), "c:\AppLog.txt", .t.)

The resulting log looks like this:

Primary Key: 81581
Primary Key: 82498

This happens "mostly" on Update actions. There's no problem here on record inserts. Data binding correctly has the ID as the primary key. I'm using MS SQL but I don't think that matters much.

I have an idea I need to do something else on my "Finder". Before an update, a record is located with a popup grid and a Select button that does this:

var vfinderid = {grid.Object}.getValue('G','ID',{Grid.RowNumber});
var po = {grid.Object}.getParentObject();
po.stateInfo['primary_key'] = vfinderid;
po.populateControlsFromTable(vfinderid,false,'','<Default>','<Default>',{"showWaitMessage": false});
{grid.Object}.closeContainerWindow(this);

The finder works well, but I'm wondering if I need to add something else to the parent object when I do this.

Anyone ever seen this, know what to do about it? It's consumed the best part of my last 4 days trying to figure this out.

[lvasic]

Re: Primary Key Changes on Update

e.dataSubmitted.ID, e.rtc.primaryTablePrimaryKey it seems like you are expecting these two variables to have the same value. Is the second key a valid primary key that belongs to another row?

[Steve Workings]

Re: Primary Key Changes on Update

Yes, the e.rtc.PrimaryTablePrimaryKey belongs to another row. Not sure how it's getting that value. But, if the e.dataSubmitted.ID is the primary key for the table, and I'm Updating a record, shouldn't they be the same before and after the Submit? I'm getting complete rows swapped between primary keys and don't know why.

For instance, record with Smith might start out as PK 1, Jones as PK 5.
Submit an Update to Smith, and Smith may be PK 5, and Jones PK 1.

I *think* I'm not supplying something to the e object so that the Submit/Update knows what key to use. But after 4 days I'm outta ideas.

[coleresources]

Re: Primary Key Changes on Update

I've been writing ajax callbacks because of the unexpected behavior of the server side action scripting.

[Steve Workings]

Re: Primary Key Changes on Update

Not a bad idea Josh, and I usually do this, but this has about 100 fields on it. But going into the 5th day of this, I may bite the bullet.

[coleresources]

Re: Primary Key Changes on Update

Sorry,

I know that is not the most helpful suggestion. I was experiencing similar issues and was very frustrated when I couldn't get it to work. I had over 100 controls that I needed to bind in my ux and it was maddening to write it all out but it's working perfectly and I have complete control over it all. Worth it in the long run.

[Steve Workings]

Re: Primary Key Changes on Update

Here's a snippet of my log that shows an update sometimes does do what I expect:

Primary Key: 82603 ' (this is e.dataSubmitted.ID)
App Num: 082629
Dialog Save Data Executed
Dialog Action was: Update
Saved 09/09/2014 07:24:34 37 pm
Primary Key: 82603 ' (this is e.rtc.primaryTablePrimaryKey)
Application Num: 082629

What I don't understand is why it doesn't always do this correctly, and instead I have a different primary key after the save action.

[Garry Flanigan]

Re: Primary Key Changes on Update

Steve, I had a similar issue with a UX that had a list control that was set to refresh in

ExecuteServerSideAction("Save Data::Save_Submitted_Data_to_Table_s_")

in afterValidate event.

I think the PK was getting its value from the list control (which should have been the same but was it really?) rather than the record being saved. I ended up re-building the UX and the problem went away but I remain uneasy about why. Maybe this gives a hint as to the source of the problem. I have had issues where the selected record changes in the list control when saving resulting on then sitting on a different record to the record just inserted.