Default patron address issue (address type 01 vs. 02)

Description:

On all of our Aleph systems we have noticed some unusual behavior in regards to the default patron addresss. Previously when loading patron records we included a "Valid to" date range that was in the past. This caused some errors in our logs that while did not threaten the system in anyway we'd like to clean up. In fixing the problem (we updated our script so that patrons had a valid to date that was in the future) we discovered that the systems was switching the default patron address from the 01 address to the 02. This was not what we wanted and subsequently we had to fall back to our previous script so that notices printed with the (correct) expected addresses.

I have been unsuccessful thus far in finding the root of this issue. Previously, we had no "DEFAULT-ADDRESS" defined in tab100 of our ADM library. I added a line for that (even though it should default to 01) and that had no effect. We did have lines in our tab_bor_address file that looked like they hadn't been valid for quite some time. I commented those out and it had no effect. Is there another place where this could be set? I find it odd that it seems to go against the default configuration.
 

Resolution:

The intention is that the type 01 is the permanent (home) address and the type 02 is the mailing (campus) address. 

The programs will typically look for an un-expired type 02 address, and, failing to find one, they will look for a type 01.

That is why, when your type 02 is expired, it picks up the type 01.

You should be able to use tab_bor_address to circumvent this logic.

Update $data_tab/tab_bor_address with a current date range for type 01 and 02 define valid addresses.

! TABLE_KEY 1,2,3
!
! COL   1.   8; DATE; ;
!               From date;
!               From date;
! COL   2.   8; DATE; ;
!               To date;
!               To date;
! COL   3.   2; NUM; ;
!               Address type;
!               Address type;
!   1       2      3
!!!!!!!!-!!!!!!!!-!!
20160101 20160501 01
20160502 20161231 02

• Article last edited: 10/8/2013