I wanted to share an odd puzzle I ran into recently with the Comments2 element in CommonSpot’s Blog2 application, on the off chance it might help someone else.
I was writing a custom script to help identify duplicated blog comments, but couldn’t get the ADF’s getCEData function to successfully retrieve the data.
It kept telling me:
Error in custom script module.
The column name (formID) that you specified already exists in this query.
Column names must be unique.
I won’t waste your time or patience by sharing everything I tried that did NOT work.
It wasn’t until I compared the Comments2 Custom Element against the one inside of CommonSpot’s ADFDemo that I finally realized someone had added an extra field named “formID” to the existing element– breaking the getCEData function (and others) in the process.
How exasperating.
But wait! If getCEData is complaining formID already exists, why don’t we see it inside of the Comments2’s Field Definitions?
Here’s the thing– all CommonSpot custom elements have a formID property. It’s just kept in a separate part of the element’s structure than the Field Definitions. (CommonSpot Custom Elements also store pageID and FORMNAME properties, too. The same admonition applies for them as well– do not add field definitions with those names either, unless you are trying to break CEData functions.)
Don’t take my word for it. Let’s take a peek at the Alerts Element to confirm if what I have said is true.
Accessing the formID for any given custom element isn’t much different than accessing its values.
So, seriously– don’t add formID as a field to your CommonSpot Custom Element. Or if you must add it, at least give it a different name, like myFormID.