Hi Kevin

>When designing tables, is there any reason to allow
>NULLs?

I seem to recall that you use Codemine? Codemine has a property setting called "lNullForEmpty". If you set this property True on character based Codemine controls (or globally in te binding manager) particularly where you are using varchar based columns, if the value in the control is "emptied" in the user interface, Codemine will automatically assign a NULL to the control source. So, say your column width is char(30) and you clear the value, 30 space characters will be written back to SQL server. With lNullForEmpty set True, a NULL will automatically be written back to the source column *if* the source column allows NULLs. The advantage of this is that any subsequent marshalling of data between the client side and the SQL server is optimised. How so? The NULL assigned back to SQL table row only takes up a single (one) character representation in the result set whereas without it, you would be effectively marshalling 30 space characters (in the example referred to here). This waste bandwith and potentially slows down the application.

So, I personally always allow NULLs on SQL server for dates (as Sergey mentioned), and in char and varchar columns that are unlikely to be the subject of calculations that involve SQL server functions that may give differing results with/without NULLs. Therefore, things like names, addresses, typical edit box content etc., are generally good candidates for NULLed columns.

Even if you are not using Codemine, its worth remembering that marshalling a NULL from server to client (and back) takes only a single character to represent the NULL whereas an "empty" (value depending on how the client side handles empty values) can result in many space characters being passed back and forth between client and server.

HTH