Hi Gerry,

>>I don't understand from which perspective he does reccoment this. From the perspective of MS SQL's shortcommings or problems that come with database design?
>
>I think he comes in from the perspective of "team development". I will grant that you would probably not have a problem with these issues. From my POV, I wish to avoid as much "extra coding" as possible ...
>
>
>If possible, avoid allowing NULL on columns ...Pragmatically, dealing
>with NULL brings issues and added complexity. As I mentioned on page
>201, a column allowing NULL is internally variable-length and can
>potentially degrade update performance. But more significantly,
>allowing NULL adds complexity and often leads to bugs in application
>code. Specific logic must always be added to account for the case of
>NULL. You, as the database designer, might understand the nuances of
>NULL and three-valued logic when used in aggregate functions, when
>doing joins, and when searching by values, but does your development
>staff understand as well ? I recommend, if possible, that you use all
>NOT NULL columns and define default values ... for missing or unknown
>entries ...


I can see this point to some extend. I and I do see merit in if you don't really need them, don't do use them, but IMO this is a bit different than: Avoid them at all cost.

>Yes, my only real concern in moving to SQL Server is "empty dates". If I don't use NULL, what should I use as a default value, and / or what is the easiest way to pump back "empty" dates into my VFP cursors if I choose to use NULLS in SQL Server.

Reading the comments below I see that you're not directly binding the data to the UI so that makes it a bit easier to solve the problem. You can use about every date value in there which you'll never use for real data. And replace it when sending it either to the backend or UI in a middle layer object (I don't like the term 'tier', because it often is missused). However I find that .NULL. is the best value to use (appart from empty dates which unfortunately are not supported).

>Fortunately, in my app, I don't have to distinguish between "missing" or "not missing"; blank, 0, or false is sufficient ... and therefore I want to stay with that domain as much as possible. But agreed, if "missing" is significant, then "maybe" NULL must be considered.

>Perhaps this is too "artificial" an example, but it was exactly the problem I encountered when I started doing "what if's" in playing with NULLS. It may not be that unrealistic if one considers that it is possible to create "uninitialized" properties that are only initialized at run time. All I saw was to potential of having to pepper my code with ISNULL()'s and NVL()'s ...

Well, I surely recognize this problem. Handling NULL dates in your VFP code certainly could omplicate things are be the source of BUGs.

Walter,