Karen, Interesting thought but I refuse to futz with the EQNULL option. It is not standard SQL and can have unwanted side effects. Especially if this is a multi-user implementation. There were several very interesting discussions of this subject several years ago. I won't be using my original coding any time in the near future. I am in the process of retrofitting the alternative method into my other two databases with similar requirements.
--- [EMAIL PROTECTED] wrote: > You can also keep your original syntax simpler by just > putting SET EQNULL ON before your checks. That way > nulls will not match, so you can just check where one > variable <> other variable. > > > I thought I would share with you a method I found for > comparing > > field differences. > > > > Problem: decide if I need to insert a record into a previous > > address history file via action in a stored procedure. I > was > > working an this complex IF statement to determine it the > SYS_NEW > > record was different that SYS_OLD record. Say for a field > such > > as HMainAddressLn. If you have SELECT HMainAddressLn INTO > > NHMainAddressLn INDICATOR NIvMainAddress FROM ... WHERE > CURRENT > > OF SYS_NEW; SELECT HMainAddressLn INTO PHMainAddressLn > INDICATOR > > PIvMainAddress FROM ... WHERE CURRENT OF SYS_OLD. I was > writing > > the following: > > IF ((NHMainAddressLn <>.PHMainAddressLn) OR + > > (NHMainAddressLn IS NOT NULL AND PHMainAddressLn IS NULL) OR > + > > (NHMainAddressLn IS NULL AND PHMainAddressLn IS NOT NULL)) > OR + > > ... SAME TEST REPEATED FOR ADDITIONAL FIELDS ... THEN > > SET VAR VFieldsAreDif = 'YES' > > ENDIF > > > > Jim Bentley American Celiac Society [EMAIL PROTECTED] tel: 1-504-737-3293 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
