Snitz Forums 2000
Snitz Forums 2000
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Help Groups for Snitz Forums 2000 Users
 Help: General / Current Version (Old)
 Ansi-nulls?
 New Topic  Topic Locked
 Printer Friendly
Author Previous Topic Topic Next Topic  

Etymon
Advanced Member

United States
2385 Posts

Posted - 12 May 2007 :  18:27:12  Show Profile  Visit Etymon's Homepage
I'm trying to update a field definition with Visual Studio 2005.

The error I am getting has to do with ANSI-NULLS. The error is a warning, and it states something to the effect that the table was created with ANSI-NULLS off and in order to continue the table will be recreated with ANSI-NULLS on. I want to change a nvarchar(20) to nvarchar(14).

My questions are these:

1) If I continue with the desired change by using Visual Studio 2005, how will this effect the existing data, future data, as well as record sets pulled from the table using the Snitz Forum 2000 forum code. I read something about the way comparisons are done concerning null values may be effected.

2) Can I avoid this warning by using a query to change the field's definition?

Thanks guys/gals!


Cheers,

Etymon

pdrg
Support Moderator

United Kingdom
2897 Posts

Posted - 13 May 2007 :  09:39:25  Show Profile  Send pdrg a Yahoo! Message
a) not worth changing an nvarchar(20) to (14) - varchar (and the unicode equivelent nvarchar) has a byte to indicate length as a part of the datatype, so an nvarchar(20) takes no more disk space than an nvarchar(14) unless you're truncating your data.

b) Nulls - if there are no nulls in the source data, just turn it on again after the impoirt, and all should be well. If it's an identity field (like an autonumber), you may run into problems, but it sounds like it's a varchar, so should be no problem. If there ARE nulls in that field already, you need to do a manual data scrub toi make sure it's all good

hth
Go to Top of Page

Etymon
Advanced Member

United States
2385 Posts

Posted - 13 May 2007 :  12:43:25  Show Profile  Visit Etymon's Homepage
quote:
Originally posted by pdrg

a) not worth changing an nvarchar(20) to (14) - varchar (and the unicode equivelent nvarchar) has a byte to indicate length as a part of the datatype, so an nvarchar(20) takes no more disk space than an nvarchar(14) unless you're truncating your data.

b) Nulls - if there are no nulls in the source data, just turn it on again after the impoirt, and all should be well. If it's an identity field (like an autonumber), you may run into problems, but it sounds like it's a varchar, so should be no problem. If there ARE nulls in that field already, you need to do a manual data scrub toi make sure it's all good

hth



Thanks! That does help. Hmmmm.

On point a) what I wanted to do it standardize the field definition to match what Snitz currently has in place for fields like R_DATE, T_DATE, T_LAST_EDIT, etc. I suppose I can just control the length of what is inserted and updated in those fields through the forum code.

On point b) I understand what you are saying to do. Thanks!

It appears that ANSI-NULLS were turned off when the table was created.

I'm using Visual Studio 2005 to work on a MS SQL 2000 database. What I am concerned about is changing a setting that works in the Snitz Forum code for MS SQL 2000 but may not work for future versions of MS SQL.

What I don't understand is how much of the forum code tests null values as either true or false. The reason I question this is because of something I read in the help files for Visual Studio 2005 about the way that MS Server 2005 interprets the value of NULL.

Another thing I am unsure of is if the table was created with ANSI-NULLS off will the entire table be effected by turning ANSI-NULLS on, or just the field with which I am working.

Below is the help file that I am reading that is bringing up these questions.

quote:
Source: ms-help://MS.VSCC.v80/MS.VSIPCC.v80/MS.SQLSVR.v9.en/udb9/html/f308784b-564e-4aa3-924f-4e3bc2fcee6b.htm

The value NULL means the data value for the column is unknown or not available. NULL is not synonymous with zero (numeric or binary value), a zero-length string, or blank (character value). Rather, null values allow you to distinguish between an entry of zero (numeric columns) or blank (character columns) and a nonentry (NULL for both numeric and character columns).

NULL can be entered in a column for which null values are permitted (as specified in the CREATE TABLE statement) in two ways:

Microsoft SQL Server 2005 automatically enters the value NULL if no data is entered and there is no default or DEFAULT constraint on the column or data type.


The user can explicitly enter the value NULL by typing NULL without quotation marks. If the word NULL is typed into a character column with quotation marks, it is treated as the letters N, U, L, and L, not as a null value.


When null values are retrieved, an application typically displays a string such as NULL, or (NULL), or (null) in the appropriate position. For example, the Color column of the Product table allows null values:

Example:

SELECT ProductID, Name, Color
FROM AdventureWorks.Production.Product
WHERE Color IS NULL


Comparing Null Values

Care must be taken when comparing null values. The behavior of the comparison depends on the setting of the SET ANSI_NULLS option.

When SET ANSI_NULLS is ON, a comparison in which one or more of the expressions is NULL does not yield either TRUE or FALSE; it yields UNKNOWN. This is because a value that is unknown cannot be compared logically against any other value. This occurs if either an expression is compared to the literal NULL, or if two expressions are compared and one of them evaluates to NULL. For example, the following comparison always yields UNKNOWN when ANSI_NULLS is ON:

Example:

ytd_sales > NULL


The following comparison also yields UNKNOWN any time the variable contains the value NULL:

Example:

ytd_sales > @MyVariable


Use the IS NULL or IS NOT NULL clauses to test for a NULL value. This can add complexity to the WHERE clause. For example, the TerritoryID column in the AdventureWorks Customer table allows null values. If a SELECT statement is to test for null values in addition to others, it must include an IS NULL clause:

Example:

SELECT CustomerID, AccountNumber, TerritoryID
FROM AdventureWorks.Sales.Customer
WHERE TerritoryID IN (1, 2, 3)
OR TerritoryID IS NULL


Transact-SQL supports an extension that allows for the comparison operators to return TRUE or FALSE when comparing against null values. This option is activated by setting ANSI_NULLS OFF. When ANSI_NULLS is OFF, comparisons such as ColumnA = NULL return TRUE when ColumnA contains a null value and FALSE when ColumnA contains some value besides NULL. Also, a comparison of two expressions that have both evaluated to null values yields TRUE. With ANSI_NULLS set OFF, the following SELECT statement returns all the rows in the Customer table for which Region is a null value:

Example:

SELECT CustomerID, AccountNumber, TerritoryID
FROM AdventureWorks.Sales.Customer
WHERE TerritoryID = NULL


Regardless of the ANSI_NULLS setting, Null values are always considered equal for the purposes of the ORDER BY, GROUP BY, and DISTINCT keywords. Also, a unique index or UNIQUE constraint that allows NULL can contain only one row with a NULL key value. A subsequent row with NULL is rejected. A primary key cannot have NULL in any column that is part of the key.

Computations involving NULL evaluate to NULL because the result must be UNKNOWN if any of the factors is unknown. For example, column1 + 1 evaluates to NULL if column1 is NULL.

When the columns being searched include those defined as allowing null values, you can find null or nonnull values in the database with the following pattern:

Example:

WHERE column_name IS [NOT] NULL



Go to Top of Page

pdrg
Support Moderator

United Kingdom
2897 Posts

Posted - 13 May 2007 :  13:52:58  Show Profile  Send pdrg a Yahoo! Message
a) Don't lose sleep over it, but do check your fields don't already contain over 14 chars if you ever try to key on them, it'll be troublesome (just because it's different data, you can compare a varchar(14) and a varchar(20) no problem)

b) The setting of ANSI NULLS will not make any difference to the returning of results nor the treatment of them, it is exclusively a constraint to prevent nulls being inserted into a field in the first place.

hth :)
Go to Top of Page

Etymon
Advanced Member

United States
2385 Posts

Posted - 14 May 2007 :  11:11:23  Show Profile  Visit Etymon's Homepage
Ah! Awesome!

Thank you!

Etymon
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Topic Locked
 Printer Friendly
Jump To:
Snitz Forums 2000 © 2000-2021 Snitz™ Communications Go To Top Of Page
This page was generated in 0.21 seconds. Powered By: Snitz Forums 2000 Version 3.4.07