This project has moved and is read-only. For the latest updates, please go here.

Trouble with the $().SPServices.SPCascadeDropDowns

Jan 2, 2015 at 3:40 PM
Good evening/morning,

Bottom line up front: Does the SPCasecadeDropDowns function use the default generated list forms and turn them into the appropriate simple/complex selects, or do I need to make a custom form in able to achieve this result? The prerequisites in the documentation suggest something about a dropdown that references list data...

Writing from Kuwait. I contacted Marc and he recommended that I come here for a little help.

I'm entirely new to SharePoint. I've clocked just about 24 hours of reading and tinkering so far. And... not very far. There are, of course, many ways to accomplish what I'd like to, but I'm a little hamstrung and am limited, at least now, to doing everything through the browser or SharePoint Designer -- no access to the database or any other development tools. I've done some light webdev in the past with javascript and python, but this SharePoint... it's a challenge.

Right now, I'm trying to implement some cascade dropdowns, and I'm having a heck of a time. I read the docs and it seems straight forward, but I feel like I'm missing a step with the dropdowns themselves and how they become populated. Does the function take the default form and automagically populate with the required items based on the parameters, or do they have to be populated, and the function does some filtering based on selections?

I riffed on the example and made it close enough to where I could follow along, but not so close that I wouldn't learn anything...

I have the following lists: Countries, States, and Cities.
Title (containing country name)

Title (state name)
Country (static name is State, looks up Countries.Title)

Title (city name)
State (looks up state name)
<script type="text/javascript">
$(document).ready(function() {
    console.log("Hello World!");
    relationshipList: "States",
    //Made a mistake on initial implementation and renamed
   //State is the static name below.
    relationshipListParentColumn: "State",
    relationshipListChildColumn: "Title",
    parentColumn: "Country",
    childColumn: "State",
    debug: true
    relationshipList: "Cities",
    relationshipListParentColumn: "State",
    relationshipListChildColumn: "Title",
    parentColumn: "State",
    childColumn: "City"

Jan 2, 2015 at 3:47 PM
Edited Jan 2, 2015 at 3:49 PM
So what's happening in the page? It looks on the surface as though you have everything set up correctly. I'm assuming you've added a Content Editor Web Part (CEWP) to copies of each of the forms (NewForm or EditForm or both)?

You have to use lookups in the list where you want this to work, of course. So in the list you'd have columns for:
  • Country - Lookup to Countries.Title
  • State - Lookup to States.Title
  • City - Lookup to Cities.Title
Basically, the page loads as it would normally. Then when you call the function, it does the appropriate filtering, wiring up, etc. based on the parameters you have provided. It doesn't change the default way the form works; it just overlays the new behavior on it.

Jan 2, 2015 at 5:46 PM
Check your compatibility view settings as well. If you're running IE11 (and maybe even IE10), you may experience problems with JavaScript enabled select controls in SharePoint forms. I know I have seen problems on my end. In order to get things to function properly for me, I had to turn Compatibilty View on for all of SharePoint.

Jan 2, 2015 at 6:04 PM
This is going to sound silly, but maybe the question about a select was telling. All of the columns in the final list are supposed to be lookup fields... right?
Jan 2, 2015 at 6:05 PM
That's probably a red herring, Geoff. But yes, SharePoint gets cranky if you don't let the browser run in the mode it expects.

BTW, Micheal, the SharePoint version shouldn't matter with this, but what version are you running?

Jan 2, 2015 at 6:06 PM
Correct, Michael. As I've outlined above. They have to be lookups to the same lists you are using to maintain the relationships.

Jan 2, 2015 at 6:22 PM
We're running 2010.

Ah, so you have outlined it above. And here I was feeling like I figured it out on my own. In my defense, I read your reply on my email, and that bullet list doesn't show up, at least not in gmail.

I must be getting closer, but this SharePoint thing is new and seemingly finicky to me. I had add some new columns and call them something different. Now it's just a matter of me figuring out the mapping. Of course, SharePoint won't let me simply delete the columns, add new ones, and use the old column names. By the way, is this a bug, or by design?

I'm still plugging away at this. I'll figure it out.
Jan 2, 2015 at 6:34 PM
Got it. Now to build something great.

Thanks so much.
Jan 2, 2015 at 6:53 PM
You can absolutely delete the old columns and add new ones with the same names.

Glad you're getting over the hump. Feel free to ask more if you need to...

Jan 2, 2015 at 7:14 PM
Getting off topic, but... maybe there's something wrong with our sharepoint permissions? The column names seem to persist if you name them, and try naming new columns with old names. We even get errors when trying to create new views after we've deleted columns with SharePoint complaining that the columns may have been deleted by another user, preventing me from creating new views.

Jan 2, 2015 at 7:17 PM
Hard to say without knowing the actual sequence of things. If two people are involved, it can get a little hinky. If it's just you, deleting and re-adding in one browser session should work.

Jan 2, 2015 at 10:44 PM
Just to be clear...

The relationships that can be maintained for the cascade to work is for every list that I reference, I must have just one relationship inside?
The below concept won't work then, I take it?
$(document).ready(function() {
    relationshipList: "Missions",
    relationshipListParentColumn: "Mission_x0020_Date",
    relationshipListChildColumn: "Mission_x0020_Number",
    parentColumn: "MissionDate",
    childColumn: "MissionNumber",
    debug: true
    relationshipList: "Missions",
    relationshipListParentColumn: "Mission_x0020_Number",
    relationshipListChildColumn: "ID",
    parentColumn: "MissionNumber",
    childColumn: "MissionID"
Jan 3, 2015 at 3:21 AM
Correct. It's one relationship per list. That makes for good relational lists. It also means you have nice, flat lists that can contain more information about the Title (key) column. For instance, the address of the command post in Qatar.

If you did what you show above, you'd end up with duplicate relationships one way or another.