Sending an array via AJAX to MVC Controller

[+FloatingFatMan Subscriber¹]

First, let me start by saying that, though I'm a seasoned developer with 30 years behind the keyboard, I've only been working with web development for about a year, so there are things I don't know.  However, this one really has me confused!

 

All I want to do is send an array of integers to an MVC controller using an AJAX call.  The code below works absolutely perfectly for me every single time I run it in my development environment (Windows 10, VS2017), BUT, when I roll it out to the production server (running IIS 7.5), I get an error 500, internal server error.  To make matters worse, this code WORKED on the production environment 1 week ago, and yesterday it decided "screw you!" and started to fail.

 

Note, when it errors, it jumps into the error part of the Ajax call; it never gets into the controller method, I guess because it doesn't like the int[] parameter anymore...

 

Here is my AJAX call:

	var selectedItems = new Array();
	$("input:checkbox[name=selectPrice]:checked").each(function () {
		selectedItems.push(this.id);
	});

	if (selectedItems.length > 0) {
		$.ajax({
			url: "/ProductPrice/CanApprove",
			type: "post",
			dataType: "json",
			contextType: "application/json",
			data: { selectedIds: selectedItems },
			traditional: true,
			success: function (result) {
				if (result.success) {
					//Do something useful
				} else {
					//It all went wrong
				}
			},
			error: function (_err) {
				//It all went REALLY wrong
			}
		});
	}

 

And here is my controller method:

[Authorize]
[HttpPost]
public JsonResult CanApprove(int[] selectedIds)
{
	bool canApprove = service.CanApprove(selectedIds, out string reason, out int[] approvableIDs);
	return Json(new { success = canApprove, ex = reason, approvableIDList = approvableIDs }, JsonRequestBehavior.AllowGet);
}

 

I've had to change over to just passing a delimited string for now, and converting it back into an array inside my controller method (which is just urgh!), but I'm REALLY struggling to understand why this just stopped working?!  Is there anyone here with more javascript experience than me that can explain what could have caused this?

 

 

[Seahorsepip Veteran]

Your ajax code is not sending an int[] array but an object with an int[] array:

 

What you expect it to send:

[1,2,3,4]

 

What it actually sends:

{"selectedIds": [1,2,3,4]}

 

Change data property in your ajax call to:

data: selectedItems,

 

That should probably work if my assumptions were correct

 

It's been a while since I worked with MVC controllers but as far I remember you don't need to send the controller parameter key in the object data if there is a single parameter in the controller method.

[+FloatingFatMan Subscriber¹]

Yeah, I tried that, and other variants. Without the name of the parameter, all the controller receives is NULL.

 

Anyway... I forgot to post, I actually found a solution to the problem late yesterday afternoon, after much pulling out of hair, and commenced to kicking myself repeatedly once I'd found it!

 

I was on the verge of just giving up completely when I decided that, even though the controller code was simple, I'd stick it inside a try/catch (which I should have done from the start anyway, because y'know, DUH!).  And when I did that, I was finally able to get a sensible error message in the AJAX call.  It seems that for some reason, my call was having trouble opening a database connection as the error complained that the connection as in use!

 

Ah ha! says I. I've seen that before and immediately went to look at the webconfig file, followed immediately by going over to our DBA and punching him in the side of the head.  It seems that when he last updated the webconfig when they changed the password a few days ago, he REMOVED the command "MultipleActiveResultSets=True" from the connection string.

 

IDIOT! IDIOT! IDIOT!

 

I'm amazed the app was functioning at ALL with that missing!

 

Moral of this story folks... IT'S THE DBA'S FAULT!

 

 

[+Sledge Subscriber²]

I think moral of the story is poor error handling.

 

Should always be the first thing to code so when things do go wrong (which they always do) you can check a log and point a finger.

 

 

[Seahorsepip Veteran]

  On 28/09/2017 at 17:17, Sledge said:

I think moral of the story is poor error handling.

 

Expand  

 

  On 23/09/2017 at 10:38, FloatingFatMan said:

 

Moral of this story folks... IT'S THE DBA'S FAULT!

 

Expand  

Seems the DBA is here and throwing the blame back at you 

 

But I have to agree with the DBA on this one, too many times I programmed a try catch without outputting the error in the catch resulting in missing the error and wondering what i did wrong 

[+Sledge Subscriber²]

  On 28/09/2017 at 19:25, Seahorsepip said:

 

Seems the DBA is here and throwing the blame back at you 

 

But I have to agree with the DBA on this one, too many times I programmed a try catch without outputting the error in the catch resulting in missing the error and wondering what i did wrong 

Expand  

Hehe - nah just too many years covering my ass

[+FloatingFatMan Subscriber¹]

  On 28/09/2017 at 17:17, Sledge said:

I think moral of the story is poor error handling.

 

Should always be the first thing to code so when things do go wrong (which they always do) you can check a log and point a finger.

 

 

Expand  

Yeah, yeah, I know.. Like I said.  Idiot!!  

 

I'm still blaming the DBA though, as he did the connection string for the production server!