Hello,

If the value you see in an editor is different than the one in the cell, this most likely means Updating was unable to find the correct record corresponding to the row being edited. If I read your example correctly, setting the primaryKey to "Gain" is very likely the culprit as the values in the Gain column are not unique. When that's the case your editors will get populated with the values of the first record that has the same PK as the one you are trying to edit.

My previous suggestion for updating without PK is only possible if you only update through separate UI, using the grid's API. Using Updating's UI does require an unique PK to avoid such conflicts. What I suggest is to traverse your data before initializing the grid and add a property to use as PK which you populate with a simple index. Then you can hide the column through the column settings:

columns: [

    { key: "Index", dataType: "number", hidden: true }

    ...

]

I realize you had some issues with this approach previously but I believe these can be worked around more easily than implementing a separate updating UI to circumvent Updating's dependency on a PK. Please, let me know about any issue you have with defining a dummy PK so I can help you with them promptly.

Best regards,

Stamen Stoychev

I think the main issue here is that my testing and workarounds are scattered all over the place. You seem to understand my issue the best so far. The biggest problem here is that too many hands are in the mix in helping this issue. I think its best for both my teams and your team to track this PK issue until fully resolved. Unfortunately I have no way to predict these failures. Please suggest an approach in your reporting system I can trust will find a resolution.

We can not use hidden columns for a 2 main reasons.

1) Your code is inconsistent. I have the link to that info somewhere.

2) We need to count columns on the fly, if your code was consistent I could reply on the counts but its not, so that does not work.

If your not the right person to help our team see this thru please have someone contact me.

Hello,

If I remember correctly the main issues you experienced by hiding a column were some discrepancies in the grid's API coming from the fact some features work with visual and some with real column indexes. I can't argue that this can be problematic and we are already planning on addressing it for the 14.2 volume release.

In the mean time a general rule with the event arguments and the functions accepting column index parameters is that features that work exclusively with the DOM and not the data source (i.e. Selection) will use visual indexes, while features that modify the data source or data view in some way should work with real indexes. With this said, to switch between the two or get an index by a column key you'll need to process the columns collection and apply some logic to it.

$("#grid1").igGrid("option", "columns"); -> gets the columns collection

$.grep($("#grid1").igGrid("option", "columns"), function (col) { return !col.hidden; }); -> gets only the visible columns

If you can provide me with some examples of where the column indexes are inconsistent between event arguments and function calls I can help you with specific solutions.

As for using the reporting system - we log development issues to our internal system from information on the forums and such will be logged in your case if suspicious behavior is found. For feature requests (such as the ability to use Updating without a PK) you can use the "Submit Product Idea" button to the right.

I am looking forward to hearing from you!

Best regards,

Stamen Stoychev

For example if I have a 2 by 2 grid with a hidden field "pri"

col1 col2 ( "pri" hidden )

1_____1

2_____2

I get these results

alert(this.gridIDMap.option( "columns" ).length); 3... no, its hidden so there should only be 2.

alert( this.gridIDMap.cellAt( 2, 0 ).innerHTML ); error this is good because 2 is hidden and that is what I would expect.

now if I unhide and do the same I get this.

alert( this.gridIDMap.option( "columns" ).length); 3... in this case 3 is correct.

alert( this.gridIDMap.cellAt( 2, 0 ).innerHTML ); alerts an empty cell as it should because its empty

So if cellAt takes in to consideration that the cell is not shown then why does columns not?

There was another example I ran in to but it escapes me at the moment.

Now here is what confuses me more then anything. In 1st quarter 2013 the system worked with no PK. Our code executed perfectly and all updates were fine, be it double click or programmatic. Some fix was made enforcing the PK in mid 2013, not sure when. Then all of our updates break. Now I started asking about this mid 2013 and we are now in to feb 2014 and its like I'm going back to the suggestions in mid 2013. It took me 8 months to get to a semi-working point and now I find its no good. My proposal form the very beginning ,humbly, was "would you please consider allowing a null value for PK". Its already proven to work that way as it did for us in the beginning of 2013.

If that is in some way unacceptable, you know our issue. We simple want to load data in to a chart and then make edits. No match data base is used ( WYSIWYG ). If the internal update function will not work because of a missing PK ( even though at one time it did ) could you offer a new way to go about this. I think the only issue left is this double click. I dont really need it to work I just need the events. Maybe its best to disable the grid dblck and over right it with jquery? The only thing we need the event to do is start edit on a cell, and enter to save the new value. No need to use the internal grid dblck at all. I have not considered this yet.

Adding this hidden key was a disaster last time but more importantly we would like a solution that wont come back to haunt us. If you do prescribe a method here, I'd like to know I'm not going to run in to more PK issues down the road.

Hi seang,

What seems to be the issue here is that the cellAt method is really working off thes that are rendered whereas columns are a completely separate entity that is not reflective of whatis generated. It is possible to have more columns because we need to the extra column objects whereas with s...we only render what is needed.

I agree that there is something here that we need to address and I am starting a conversation internally to see how best to resolve this.

Thank you Sean. I will return to you here on this forum thread once I have further details.