Work Life: False vs Not True in programming and db logic

Oftentimes, I think that false is when logic fails by which I mean a logical contradiction like "true = false". But in reality (like in MS SQL), false is that it is not true. And a lot of logic is also built in this fashion even though most of us do this unconsciously.

In a less technical view, the difference is like saying that someone "unhappy" is sad. Although we typically understand it to be sad (given certain context) but someone could be in other states that are neither happy nor sad, thus being unhappy and not sad. The person could just be indifferent, content, angry, etc.

The minor difference is important particularly with passwords where it either passes or it does not. When it "fails", there is no reason to why it fails except that it is not true. This is important because we do not want to provide a reason to what may be wrong because it may provide a clue.

To further explain the technical logic and design, the minor difference also includes when something cannot be computed like when variables are unknown or conditions that were not met. The most common is with nulls or anything that results in an unknown like dividing by zero. A simple null example is (null = null) which returns false. An 'unknown' example is (1/0 = 1/0) which also returns false.

It is somewhat fascinating to me that classic philosophy does not quite consider the concept of null or unknown... but then, my knowledge on classic philosophy is extremely limited to what I had to read in college as an engineer.

Review: SharePoint 2010 - Check DateTime Field is Blank (solution)

My preference in setting up flags is to use a datetime field. If there is a date, then the flag is set. If it is null, the the flag is not set. My problem is using SharePoint Designer to check if the datetime field is empty.

Solution

After some searching, I found the second solution in Reference-1 to work for me. The solution is to create a text field variable, then set the datetime field to the variable. The text variable will have the options to check if it is null, and will be null if the datetime field is null. For me the important step was making sure that the variable is of a type that triggers the conditional statement to include null checks.

Analysis

For whatever reason, the conditional statement does not include null for datetime fields. My guess is that there is something about checking datetime field as null because I did try the first checked solution in Reference-1 by setting a variable as null then comparing it to my datetime field.

As I write this, I think I may have created the variable as a datetime variable. There is a possibility that this may work if compared to a text variable set to null. I would check if I was not already frustrated with working with SharePoint and if I still had that example. Perhaps, I'll try this at a later time.

There was another alternate solution which I did not get around to doing. It requires another column. .

Reference

1- http://social.msdn.microsoft.com/Forums/en-US/6dc36021-5c7d-4d70-8ead-afa36c45dfd5/how-to-check-for-the-date-is-null-in-sharepoint-designer-condition-?forum=sharepointcustomizationlegacy
2 - http://howardmcd.wordpress.com/2013/05/20/how-to-check-if-a-date-field-is-blank-in-a-sharepoint-designer-workflow/

Buggish: SharePoint 2010 - Unable to filter lookup through Designer

After what I think was an update (see recent problem with SP), I noticed different behavior with the lookup. For some reason, I am not longer able to filter the lookup by creating a calculated field. In the past (I am pretty sure that I tested this), I had created a calculated field which was used for the lookup. When the calculated field was empty, the lookup only had values that I wanted to be shown (by ignoring blanks).

Now that I am trying to implement this into our production site, this option is no longer there. Going back to my test site, this option is also not there either. It has been a couple months since I last touched this so my memory on this is a bit fuzzy. The columns that I thought was referencing the lookup, now only references the main column that the lookup was calculated on. The update should not have done this automatically because the calculated field could have potentially had multiple fields. It may be possible that the admin had subjectively updated the fields appropriately which may be why the site was down for a couple hours.

Overall, this is still all just speculation. I wish there was more update from the SharePoint admin team on what is being done. One would imagine that the SharePoint team would be at least one of the teams that maintains a site with the updates. Also at the end of the day, I can no longer use a lookup on a calculated field. I do not have access to the server, so I cannot use the other options... and still wishing that I could just build an app which I think I could still create faster.