After an inline edit, the edited row dissapears
After an inline edit, the edited row dissapears
On one of my pages I have two tables, when a user selects an entry from the first table it loads information into a second using a query string which is sent back to the controller. When I inline edit a basic select box on the second table the data is submitted correctly and updated. However, the updated row is removed from the view until the ajax call is made again. Further to this I do a similar thing on a different page within my application and it works perfectly without removing the row after an update. Any help would be appreciated.
Below is the javascript related to this
//USER PERMISSIONS EDITOR
/*
* Populates the Editor with fields (create, edit) for the User Permissions List
*/
var editorThree = new $.fn.dataTable.Editor({
ajax: "/NewUser/UserAssignedPermissionsTable",
table: "#UserCampaignPermissions",
fields: [
{
"label": "Permission",
"name": "CampaignPermissions.Permission_id",
"type": "select"
},
{
"label": "Campaign",
"name": "CampaignPermissions.Campaign_id",
"type": "select"
}
]
});
//USER LIST TABLE
/*
* Populates the user list table
*/
var table = $("#UserList").DataTable({
ajax: "/NewUser/UserListTable",
select: {
style: "single"
},
scrollY: "550px",
pageLength: 25,
processing: true,
//stateSave: true,
columns: [
{
"data": "ClientUserLink.Id",
"visible": false
},
{
"data": "U.Username",
"className": "Inline"
}
]
});
//ASSIGNED CAMPAIGNS/PERMISSIONS TABLE
/*
* Populates the Permissions table
*/
tableThree = $("#UserCampaignPermissions").DataTable({
ajax: "",
select: {
style: "single"
},
processing: true,
//scrollY: "200px",
paging: false,
searching: false,
columns: [
{
"data": "CampaignPermissions.User_id",
//"visible": false
},
{
"data": "CampaignPermissions.Id",
"visible": false
},
{
"data": "Campaign.Name",
"editField": "CampaignPermissions.Campaign_id"
},
{
"data": "Permissions.Permission",
"editField": "CampaignPermissions.Permission_id"
}
]
});
$("#UserCampaignPermissions").on("click", "tbody td:not(:first-child)", function (e) {
editorThree.inline(this, {
onBlur: "submit"
});
});
//RELATED FUNCTIONS
/*
* Loads data in the second table (Assigned Role) and third table (PERMISSIONS) when a team is selected within
* the user list
*/
$("#UserList tbody").on("click", "tr", function() {
var selectedRows = table.rows({ selected: true }).count();
if (selectedRows === 1) {
currentUserId = table.row(this).data().ClientUserLink.User_Id;
tableTwo.ajax.url("/NewUser/UserAssignedRolesTable/?userId=" + currentUserId).load();
tableThree.ajax.url("NewUser/UserAssignedPermissionsTable/?userId=" + currentUserId).load();
} else if (selectedRows === 0) {
tableTwo.clear().draw();
tableThree.clear().draw();
}
});
This question has an accepted answers - jump to answer
Answers
Is there a way of forcing the table to redraw after submit?
If the row is disappearing it means the server isn't responding with the expected JSON.
What is it currently responding with?
Allan
The response contained no data. Which is understandable as the editor Ajax URL is not modifiable by a query string. I have now modified the controller to store the current query string as a static variable so that whenever editor makes a call (sending the query string "NONE") it returns json relevant to the whatever DataTables is displaying.
Controller is now as follows:
This has meant the response comes back as follows when performing an inline edit:
The above information matches up correctly, however; now the change is not applied to the record in the database at all...
I realise this can be cut down to shorter code. Felt easier to explain this way though.
I am having a similar issue.. Were you able to solve this problem..?
No still no luck with it unfortunately. Having another go now.
Just to check my understanding - the only change you made was to have JSON data in the response for the inline edit, but now the write to the database is not happening (presumably it was before)?
What exactly what the change that was made?
Allan
I just edited the controller so that the ajax URL used by Editor returned data. Prior to this it was trying to execute the Where statement...
...without a valid Guid due to it not making use of the query string in the actionresult method
I have since then also turned on the editor form, for creating a record (using "editorTwo.create..."), on my JS file and received a "object is not set to an instance of an object" error as well. Although I can't for the life of me work out why.
We should perhaps address the need to send the user id - I would suggest using both the DataTables
ajax.data
and the Editorajax.data
options as functions to add the data needed:I'm not convinced that will solve the problem of the database not updating - but if the only change was the removal of the
Where
condition, then perhaps it will.Allan
Awesome; I will try this as soon as possible and get back to you. About to head out for a work Christmas meal so may not be until a bit later. Thank you as always!
So you were right, that did not solve the database updating. I created some buttons (create,edit) for the purposes of testing. When I hit the create button on the form I receive the following:
"Object reference not set to an instance of an object."
From the server, or in the Javascript? What is the code that is failing? If its in the server you might need to add
TryCatch( false )
to the Editor initialisation so it will show exactly where the exception is occurring.Allan
Appears to be the server, response preview is:
Did you try adding the
TryCatch( false )
to allow it to break where the error actually is? It should be the first item in the chain.Allan
After setting TryCatch to false it seems the above has been revealed as whats causing the error.
Aha! So I'm wondering if its to do with im handling schemas? Is there anyway of me changing the schema that is searched for?
It points to that line rather than something inside the Editor class?
It might well be a schema issue - that isn't currently a feature that is supported by the Editor classes I'm afraid.It is something I have actively been looking at adding explicit support for though.
Allan
Yeah, I checked it as well by recreating the table as a "dbo." table and the problem disappeared.