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

Strange behavior with some methods and getting 'childColumnStatic'

Feb 22, 2013 at 2:47 PM
Edited Feb 22, 2013 at 2:48 PM
This morning I'm trying to use at the first time, the following utility:


But I'm receiving this response:

'childColumnStatic' is undefined

Trying to debug the code I'm using the following utility, that doesn't return anything:


So I found the reason: I'm not accessing the full domain name.
Instead -->
I was trying --> http://site/path/subsite/
Now the question: what's the expected behavior??

So if my users don't type the full URL, the cascade dropdown will not work...

I'm using jQuery 1.8.3 and SPService 0.7.2
Feb 22, 2013 at 5:01 PM
Can you show the code you are using? I'm not sure why your users would ever need to type the URL at all. It's more of a "configure and leave it alone" thing.

Feb 22, 2013 at 6:21 PM
Edited Feb 22, 2013 at 6:21 PM
Hi Marc,

Thanks for your quickly answer!
I'm using the following code:
    relationshipList: "Product",
    relationshipListParentColumn: "Group",
    // listName: listName: $().SPServices.SPListNameFromUrl(),
    relationshipListChildColumn: "Title",
    parentColumn: "Group",
    childColumn: "Product",
    // debug: true
The custom page are in the current list context.
It's strange that if I just go to my browser, Developer Tools and Console, the following utility has different behaviors when using FQDN and the site name:


Thanks again!
Feb 22, 2013 at 6:41 PM
What you show above will throw an error because you have the comma at the end of this line:
    childColumn: "Product",
The last option shouldn't have a trailing comma.

listName is only useful in this function if you're calling it from outside the list context, e.g., not in /List/SomeList where the forms usually live.

Feb 22, 2013 at 7:28 PM
I was using Google Chrome, and it doesn't reproduce any error.
Using Internet Explorer the error appear, but of course you are right about the sintax.

In any situation, (with or without the 'plus' comma), the behavior still changing by using FQDN and just the first portion of site url.

Feb 22, 2013 at 8:02 PM
Again, if your form is in the list context, don't even use the listName option.

Feb 22, 2013 at 9:51 PM
Edited Feb 22, 2013 at 9:51 PM
I know, but i tried to make it explicit to check.
By the same reason this portion is also commented.
The point is the different behaviors according to URL.
I would like to know if it's by design, bug or my mistake.
In case of expected result, I think that's safer to build my own cascade dropdown menu, because accessing web services manually I didn't found any problem. I will check as soon as I can :)

Feb 22, 2013 at 10:03 PM
My point is that you don't have to specify any URLs at all based on what you've told me so far. Or is the Product list in a different Web? If so, you should use the webURL option, not listName.

Feb 23, 2013 at 4:17 PM
Ok Marc, I will try to explain a bit more. At the same web I have the following lists:
-- Title (text)
-- Title (text)
-- Group (lookup)
-- Title (text)
-- Product (lookup)
-- Group (lookup)
I'm not specifying any URL. Basically I'm using the following code:
    relationshipList: "Product",
    relationshipListParentColumn: "Group",
    relationshipListChildColumn: "Title",
    parentColumn: "Group",
    childColumn: "Product",
Well, it works fine when a try to use the following URL:

But when I try this one:


The error appears on my Internet Explorer: 'childColumnStatic' is undefined and the cascade dropdown fails and all option of all combo box are enabled.

I really don't expect this for my users, because some of them type the full url, some not. At the same time a lot of sites that also uses SPServices doesn't have any problem, using both URLs.

Now I would like to know if different behaviors are expected or not using $().SPServices.SPCascadeDropdowns according to URL, because it's the result I'm having.
I never had this kind of problem when I did my own cascade drop down.

Appreciate for your time! Thanks again!
Feb 25, 2013 at 5:00 PM
Trying to debug a bit more, I have the following result when using Google Chrome Browser:


By this message, it's trying to make a cross-site access (remembering that URL address points to the same site at the same domain).

Now I'm thinking a way to 'force' the use of FQDN or to append that the 'SITE-NAME' belongs to 'DOMAIN-NAME'.

Maybr it's also related with the alternate access mappings and host headers configuration.
Feb 25, 2013 at 7:44 PM
I think it's a setup thing on your end.

SPServices looks at the URL to figure out what the current site is. With either URL, it ought to decide what the site is just fine and be able to make its calls.

Feb 26, 2013 at 2:29 PM
Thanks Marc!
As soon as I solve, I'll post here :)
Feb 26, 2013 at 5:18 PM
Edited Feb 26, 2013 at 5:19 PM
Finally solved!

I changed the alternate access mapping configuration before to support forward to full domain URL, as you can see the following image:


Using this configuration, when user types "http://site/subsite/", automatically it will be forwarded to "". But there's a problem...

If the user types the entire URL (that's include the path to file.aspx page) WITHOUT DOMAIN SUFFIX, it will not be forwarded and where's the problem lies; because it will finish with a ugly cross-domain access error.

But after applying some changes to Alternate Access Mapping like the following image:


And accessing just by the site name (without domain suffix), is enough to SharePoint know that it's not cross-domain access!
Of course it will not forwarded to full domain URL (as I would like), but will not consider differents URL to the same path as a cross-site access, that's safer when thinking about code compatibility.

Thanks for all help!
Apr 17, 2013 at 1:20 PM
Edited Apr 17, 2013 at 1:51 PM

I am having a similar issue with CascadeDropDown. Already tried 2 or 3 solution proposed on this and others posts with to no success.

My case is even weird the cascade dropdown Works in 50% of the times (alternated);
  • Access 1 = Works
  • Access 2 = Doesn't work
  • Access 3 = Works
  • Access 4 = Doesn't work
weird huh ?

I already tried to configure AAM without success.

I am usina CustomListForm (so 100% sure it is in List Context.

I have another List with exactly same configuration (listform with javascript cascade dropdown) and it is working perfect.

This is the code:
    relationshipList: "Cadastro de Estados",
    relationshipListParentColumn: "Pais",
    relationshipListChildColumn: "EstadoNome",
    parentColumn: "País",
    childColumn: "Estado",
    noneText: "(Nenhum)"

    relationshipList: "Cadastro de Cidades",
    relationshipListParentColumn: "Estado",
    relationshipListChildColumn: "CidadeNome",
    parentColumn: "Estado",
    childColumn: "Cidade",
    noneText: "(Nenhum)"
Lost my mind trying to solve this...

Im using Sharepoint 2013 / jquery-1.8.3-min / SPServices-0.7.2-min

The difference I can see on SP2013 is the URL when you click on "New Item" Link

It appends the '_layouts/15/#/start.aspx#' and then the List path (as in 2010)


Can anybody help me to investigate this ?


Just an update: I have updated SPServices to the current ALPHA version (2013.01.ALPHA6) and its working now.

Hoping to see 2013.01 stable release soon ! :)

Nice work MARC

Apr 18, 2013 at 5:24 PM
Great to hear that the current alpha fixed the problem!

I think what's making it work is that I'm taking more advantage of existing JavaScript variables in this release. In SharePoint 2010 and above, we have a variable called _spPageContextInfo.webServerRelativeUrl that I can use the value of rather than trying to parse out the URL. This makes things work much better in 2013 because the URLs no longer follow the same predictable structure.