Hi Ayyappa, I work with large volumes of custom data (1500+ behind a single object) with huge calculations and over the years like to think I've made every mistake and hit every error possible. Hope springs eternal. One gotcha that could cause an error similar to the message you are seeing is that when adding a new field, be sure to click save (in order to commit its relationship to the form in the database) before attempting to then use it in a calculation. Another situation I see from time to time is at the database level, where bad data is preventing a recalc on a certain record, but doesn't crop up until the form us edited and (thereby) a recalc across all records occurs. I such cases, though, the error message usually refers to "SQL" as well. I have also run into cases where the form will save the first time through the editor, but the next time it is edited and saved, it fails: usually due to the editor's interpretation of unwisely chosen custom data field names (eg "Program") or those with special characters (eg "Price - Cost" vs {DE:Price - Cost}" or even better "Price minus Cost") on my part. My impression (in fact, I've confirmed this using the API, now that I think about it) is that during the second trip to the custom editor would "reinterpret" such items in a way that then invalidated the formulas and in turn prevented the form from being saved. So! A few years ago, we created our Update Category solution, which allows you t o quickly manipulate and realign Custom Forms to better match the business, including adding, removing, and reordering Parameters and Parameter Groups, as well as adjusting Calculated Parameter formulas: "http://store.atappstore.com/product/populate-category/">
http://store.atappstore.com/product/populate-category/ . When it runs, there is also an option to Report EVERY parameter formula error, if any (WARNING: might be VERY slow). Perhaps that feature will give you the insight you seek.
