Lotus NoteBook

1 - It's always been there? Wow! I never bumped into it before.

I wasn't really converting existing computed fields... I created a bunch of new fields on a form and initially didn't set them all to CFD. Then as I was testing, the values got saved in my test document and the rest was history.

I can't believe this isn't a bigger issue... I would just think there could be some security issues what with the availability of the all purpose smart icon's that can change fields on the backend document... I'd think that the savvy user being able to "override" computed for display fields could have some fun... Who would even think to "validate" CFD fields in query save...

Oh well...

I've seen the Ytria stuff. Looks cool. I really want to get the ActionBar one to help me mass change the look over various form and view action bars.... I'm going to Lotusphere this year (first time) and hope they have a booth there to see all that they offer.

Thanks for the information!

2 - @2 - Ytria will indeed have a booth at Lotusphere and I'll actually be hanging out there a fair bit seeing as how they are (surprise!) sponsoring me for the conference

3 - Yep, this has been around forever and usually results from a situation that goes something like this:

"Gee, these fields here are listed as computed but we really don't need to store these values in the backend and take up all the extra disk space. I'll just flip them to CFD and pat myself on the back."

Of course, this only gets noticed when the resulting value is something that's likely to change over time on a document that predated this stroke of genius.

So, for the record, if anyone reading this ever gets it in their head to try a stunt like this after an application has been used to create real production data, please finish the job by cleaning up the existing documents. A little cleanup agent like:

FIELD xyz := @Deletefield;
FIELD abc := @Deletefield;

will work, but I would highly recommend Ytria's ScanEZ tool { Link } because:

1) It will quickly highlight fields that exist on only some documents (use the "Diff" function), which is a red flag for fields that might have flipped to CFD at some point (especially helpful for cleaning up the "previous developer's" mistakes where no one remembers what fields were involved).

2) You can delete a given field out of an entire collection of documents quickly and without writing yet another throwaway agent.

3) et. al. [too tired to think of more reasons right now, but I'm sure there are more]

And since this already sounds like a commercial, I might as well mention that you can get a 10% discount (and yes earn me a small commission) on all Ytria tools using my coupon code: YTRIACOUPON_KEVINPETTITT

You will thank me...really.

4 - CFD's are right next to default values when it comes to creating confusion. When you look at the doc, you see the default value even if the field doesn't exist.

By the way (Sales pitch warning) - Teamstudio Validator will find this and other issues in your database like broken doc links, orphan documents, rep/save conflicts, etc. end of sales pitch.