Rows not being caught by regular expression - regex

Question

I write my PL SQL code in TOAD V10.6 which is then run on Oracle servers, and I believe is 11g.
Because I am working with client adrs information, I cant actually post any results.
The goal of my program is to parse address data into its correct fields. Its not the whole address thankfully. The pieces of information it does contain are building number, street name, street type, direction, and sub-unit. The information is not always in the same presentation and I have worked my way around that by the sequence in which I parse the information out.
The way I go about parsing the address field
I load the address data into a new table
I delete duplicate rows
I mark key adrs patterns as errors (such as not enough fields since an address needs at least 3 to be valid)
I extract sub-unit which can appear anywhere in the adrs
I extract the direction which can appear anywhere in the adrs
I extract the building number and make sure its only numbers
I check to see if an apartment was hyphened onto the building number
I check to make sure there is still enough information for a valid address as I still need a street type and name
I extract the street type
Whatever remains is considered the street name
I have 27,000 which are being correctly parsed, about 3000 which contain errors and are excluded, and 2200 which are not handled correctly but do not trigger any errors, this is the second last step.
UPDATE TEMP_PARSE_EXIST
SET V_STREET_TYPE = REGEXP_SUBSTR(ADRS, '\w+.$')
WHERE ADT_ACT IS NULL;
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'EMPTY STREET TYPE'
WHERE V_STREET_TYPE IS NULL AND ADT_ACT IS NULL;
I had an almost identical issue before during the parsing of the sub-units. I never figured out what caused it or why moving the regular expression from the where clause to a different part corrected it.
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL
AND REGEXP_COUNT(ADRS, '\s' || S_COM_RES_TYPE || '.+\s.+' || S_COM_RES_TYPE , 1, 'i') > 1;
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--the second one is less strict about that
--if there starts to be an issue then a space before can be added
--however, adding a space after would having it miss cases where there is no space after for the unit number
--the block of code below is suspected of being where the error is happening
--the error in question is where suite is not being noticed and extracted from the adrs line
--however there are many more similar examples being correctly handled
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = REGEXP_SUBSTR(ADRS, S_COM_RES_TYPE || '(\s?\w+|$)', 1, 1, 'i')
--'(\s\w+|$)' was the original expression, but the ? was added in to account for there not being a space
--so the pattern grabs the sub-unit, and allows for a possible space between it and the number, or allows the end of string as there are some cases of that
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL AND REGEXP_COUNT(ADRS, S_COM_RES_TYPE, 1, 'i') = 1;
--this removes v_second_line from the adrs
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
The following code doesnt have the same error as above
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE REGEXP_like(adrs, '\s' || S_COM_RES_TYPE || '\s(|.+)' || S_COM_RES_TYPE , 'i');
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--which is a common issue if I am not so strict about it
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = trimmer(REGEXP_substr(adrs, '\s' || S_COM_RES_TYPE || '\s\w+',1,1 ,'i'))
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL;
--this removes v_second_line from the adrs, this is done for both parts
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
I havent been able to figure out why this happening.
I am on an irregular project in my area, and the people I work with do not need to use regular expressions and have been unable to help me.
So the question is, why are there valid address's making it past the regular expression?
Update:
Here are examples of adrs which are correctly handled and all pieces are successfully parsed
Full example adrs Dirn Sub-unit number type name
100 Street1 Dr E E 100 Dr Street1
1000 1st Ave Suite 501 Suite 501 1000 Ave 1st
1000 100th St 1000 St 100th
1000 1st Ave N Unit 7 N Unit 7 1000 Ave 1st
Here are examples which are getting past the expression
Full example adrs Dirn Sub-unit number type name
1000 1st Avenue E E 1000 1st Avenue
1000 Street1 Road 1000 Street1 Road
1000 Street2 Street 1000 Street2 Street
1000 Street3 Drive 1000 Street3 Drive
100 1st Avenue S Unit 100 S Unit 100 100 1st Avenue
All the example address listed above were real (I changed the building numbers and names) and come from the same data set. There are no extra characters missing such as whitespace or special characters.

Answer 1

Jorge Campos is kind of correct that this was an XY problem.
The problem end up being a piece of code that I had not included, because it was so simple I didnt think it could be the cause. I have a case statement correcting the abbreviations of the street types to full names, with no else statement. So when a correct name was there, it got nulled out, because there were only correction statements.