The Customer Address entity is one of those special entities in CRM. As you probably know it stores address and shipping information for accounts and contacts. I had worked on a project where we had hoped that we could attach a custom entity to the address entity like any other entity. We found out that customer address is special. It’s one of those entities where Microsoft slaps your hands and says only we can use it so keep out, but that’s another story.

The interesting thing about the address entity is that as you look at an account or contact form fields you’ll notice that there are fields for address1 and address2 addresses. You can add as many additional addresses as you want, but the first two are special. On the same project I mentioned previously we were synchronizing information between Microsoft CRM and ERP systems. We had an issue in that the ERP systems were not giving me a unique way of identifying an address. Every time I would get an update I did the easiest thing which was to remove all addresses and then add them back according to what the ERP said they should be. I found this to be problematic as for some records (specifically contacts) I was unable to save the record anymore in the interface getting an error of Generic SQL error which I love so much.

After some theories and tests I discovered the issue. Despite the fact that you see both address1 and address2 fields on the contact form the addresses are not actually stored on that entity. All the addresses are stored in the customer address entity. The fields you see on account and contact are really pointers to these records. The problem saving I had was partially my fault and partially Microsoft’s. I don’t believe Microsoft ever intended for anyone to actually remove the first two addresses even though it was perfectly “legal” to do in code. I noticed that when I did this and try to add new addresses that my new addresses were pushed back to start with address 3 instead of 1. I found that behind the scenes Microsoft was automatically recreating the addresses that I deleted at least for address 1. Address 2 was never recreated (pre-rollup releases) and there was a pointer to this address 2 record that was supposed to be there for the entity. After I stopped removing address1 and 2 and instead chose to update these two addresses instead my problems went away.

So the premise of this blog is that if you are going to do anything special with addresses do not ever remove address 1 or 2. These are built in and should only be updated else you may find yourself looking at a generic SQL error message that tells you nothing about what is actually happening.