Multiple list item deletion SharePoint rest api "Exception from HRESULT: 0x80131904"

1

To delete all the list items in the SharePoint I have tried the following code but i am getting 500 Internal server error most of the time for REST calls. If list items are less then than 5 then the code is working fine.

$.ajax({
 url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/lists/getByTitle('TestList')/items",
type: "GET",
headers: {
    "accept": "application/json;odata=verbose",
},
success: function (data) {
    var items = data.d.results;
    for(var item in items){
        var itemUrl = _spPageContextInfo.webAbsoluteUrl + "/_api/Web/Lists/getByTitle('TestList')/getItemById(" + item.ID + ")";
        deleteItem(itemUrl, item.__metadata);
    }
},
error: function (error) {
    console.log(JSON.stringify(error));
 }
});

function deleteItem(itemUrl, metadata) {
$.ajax({
    url: itemUrl,
    type: "DELETE",
    headers: {
        "accept": "application/json;odata=verbose",
        "X-RequestDigest": $("#__REQUESTDIGEST").val(),
        "If-Match": metadata.etag
    },
    success: function (data) {
        console.log("deleted item")
    },
    error: function (error) {
        console.log(JSON.stringify(error));
    }
 });
}

I have tried with "If-Match":* and etag but no success. Am i doing anything wrong here?

sharepoint
sharepoint-2013
office365api
asked on Stack Overflow Apr 12, 2018 by Ranjan • edited Apr 12, 2018 by Ranjan

2 Answers

0

This usually caused by one the following:
The tempdb or your content database running out of space.
OR
The auto-growth setting on your database is too small.

Out of space is easy enough to understand but the auto-growth setting causing this is less obvious. If the database (data OR log) runs out of room it tries to "claim" extra storage space as defined by the auto-growth setting. If this value is too small the newly claimed space might not be enough causing it to either error or try to claim more space. Claiming space on the storage system is usually fast but it relies on the OS answering the request and if the storage subsystem is extremely busy it might take longer than SQL Server is willing to wait, causing it to throw an exception. I stay away from the "percentage" growth settings and use at least 100MB as the "grow by" value. If you are severely limited on your storage space, I suggest that you claim as much as you can for the data while still leaving enough space for the logs. There is no "set" answer for that. It depends on how much space you have and how active your database/site is.

answered on Stack Overflow Jul 26, 2018 by Andrew Steitz
0

This is an old post, but I would like to share the solution anyway.

What you are doing here wrong is that you are using in when you are looping through your array of items. You should use of instead. Then you get the correct Id. otherwise you will get the index of the item in the array.

Change this:

for (var item in items) 

into this:

for (var item of items) 

Full code:

$.ajax({
    url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/lists/getByTitle('MyList')/items",
    type: "GET",
    headers: {
        "accept": "application/json;odata=verbose",
    },
    success: function (data) {
        var items = data.d.results;

        for (var item of items) {
            var itemUrl = _spPageContextInfo.webAbsoluteUrl + "/_api/Web/Lists/getByTitle('MyList')/getItemById(" + item.ID + ")";
            deleteItem(itemUrl, item.__metadata);
        }
    },
    error: function (error) {
        console.log(JSON.stringify(error));
    }
});

function deleteItem(itemUrl, metadata) {
    $.ajax({
        url: itemUrl,
        type: "DELETE",
        headers: {
            "accept": "application/json;odata=verbose",
            "X-RequestDigest": $("#__REQUESTDIGEST").val(),
            "If-Match": metadata.etag
        },
        success: function (data) {
            console.log("deleted item")
        },
        error: function (error) {
            console.log(JSON.stringify(error));
        }
    });
}
answered on Stack Overflow Oct 27, 2020 by Imir Hoxha

User contributions licensed under CC BY-SA 3.0