Has anyone updated their local procedure for Geo Area? I updated mine in Test (see below) and the changes were committed. I also updated TR_GEO_AREA to match my new geo areas. When I try to pull a list using this new criteria, the new areas in the system table are there, but the results are very obviously reflecting the original sample code (what should be people in New Orleans are people in NYC). I don't see anything in the documentation about other steps that need to be done. I opened a help ticket, but I haven't heard anything back and I'm worried they will say it is a consulting issue since we're dealing with SQL so I thought I'd ask here. I'm pasting my updated procedure below.
Thanks!Anne
USE [impresario]GO
/****** Object: StoredProcedure [dbo].[LP_UPDATE_GEOAREA] Script Date: 9/12/2022 2:34:59 PM ******/SET ANSI_NULLS OFFGO
SET QUOTED_IDENTIFIER OFFGO
/****** Object: Stored Procedure dbo.LP_UPDATE_GEOAREA Script Date: 8/11/00 8:09:44 PM ******//****** Object: Stored Procedure dbo.LP_UPDATE_GEOAREA Script Date: 2/16/98 9:11:51 AM ******/CREATE PROCEDURE [dbo].[LP_UPDATE_GEOAREA] ( @address_no int, @postal_code varchar(10), @country int )ASSet NoCount On -- added auto CWR 8/9/2001
/* Authors: Gautami Chitta, Seenu Chundu Date: March 1, 1997 This procedure is called from (at least) t_address triggers. It computes the geo_area and updates the t_address record geo_area field for the given address_no. This does DML on t_address. This code can be localized for new installations. The code here is localized for New York City and uses the following geographic areas which can be found (and edited) in tr_geo_area For non-USA , geoarea is 4 For USA records, do the following... 0 for bad zips 1 for GNO 2 for LA (not GNO) 3 for Texas and Florida 4 for Foreign 5 for all other USA 6 for USA no zip If USA and postal_code first 5 char are nonnumeric, put 0 for geo_area --erroneous postal_code */ UPDATE t_address SET geo_area = CASE when country > 1 then 4 when country < 1 then 4 when postal_code is null then 6 when postal_code = '' then 6 when country = 1 and IsNumeric(substring(postal_code, 1, 5)) = 0 then 0 when country = 1 and charindex('.', substring(postal_code, 1, 5)) > 0 then 0 when country = 1 and charindex('-', substring(postal_code, 1, 5)) > 0 then 0 when country = 1 and charindex('e', substring(postal_code, 1, 5)) > 0 then 0 when country = 1 and charindex('d', substring(postal_code, 1, 5)) > 0 then 0 when country = 1 and (convert(int, substring(postal_code, 1, 5)) >= 70000 and convert(int, substring(postal_code, 1, 5)) <= 70499) then 1 when country = 1 and (convert(int, substring(postal_code, 1, 5)) >= 70500 and convert(int, substring(postal_code, 1, 5)) <= 71499) then 2 when country = 1 and (convert(int, substring(postal_code, 1, 5)) >= 32000 and convert(int, substring(postal_code, 1, 5)) <= 34999) then 3 when country = 1 and (convert(int, substring(postal_code, 1, 5)) >= 73300 and convert(int, substring(postal_code, 1, 5)) <= 88599) then 3
else 5 ENDWHERE address_no = @address_no GO
Hey Anne.
We talked about this at _analytic_ Coffee! (Flat White edition). LP_UPDATE_GEOAREA will update new customers (and their new @address) but have you run it yet on your existing db?
Try running it (in test) without the "WHERE address_no = @address_no" and it'll update your existing t_address putting in the GEO_AREA by postcode.
Just wanted to confirm that this worked! Thanks, Heath!
Well done