Ok...
I went back, downloaded the binaries, dumped them into my site. It broke some skin work, but I prefer for the Recurring Shipping to work properly over skin work...
Using freshly downloaded compiled binaries, this issue still happens..
(where did steps 1-4 go? they are in the post that was blocked...see first post)
Step 5
Here we see myself create a recurring order for my sis. Everything looks good and her ShippingAddressID is fine so far, since the storefront correctly shows her shippingaddressID.
Step 6
Here we see myself create a recurring order for myself. Things don't look good anymore in this image. The shippingaddressid for my sisters recurring order stored in the ShoppingCart has been replaced by my own shippingaddressid.
Again... this was done using new binaries from a version 8 that I downloaded. These are stock binaries, no fiddling with them.
It appears that the recurring order system does not work for more than one address, since their appears to be a bad update that hits the ShoppingCart table whenever someone selects a new address from the address book.
Ok... I am not here just to point fingers, but also offer a temporary solution while the smart people fix this:
First create a new table to store the ShippingAddressIDs... (For some reason as soon as the recurring orders go through the ShippingID's are overwritten in the PARENT order 
. So basically you will lose all history of the original shippingorderid that was used in the parent order. (yes here is the URL is you want to see the same data shown above after the recurring orders get charged http://www.revgenetics.com/images/sq...base Query.jpg )
Now, as I was saying... create a new table and call it "Orders_ParentAddress". This will hold the original shippingIDs. :
C#/VB.NET Code:
CREATE TABLE [dbo].[Orders_ParentAddress](
[OriginalRecurringOrderNumber] [int] NULL,
[ShippingAddressID] [int] NULL,
[CreatedDate] [datetime] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Orders_ParentAddress] ADD CONSTRAINT [DF_Orders_ParentAddress] DEFAULT (getdate()) FOR [CreatedDate]
GO
Then write a nasty, horrible piece of SQL (stored Proc) that will serve as a bandaid ... But mind you... you may still not get all of them right. But it should catch most address id issues if you run it right before you charge your daily recurring orders (I know, not good for most.. but it works for me):
C#/VB.NET Code:
Create Procedure [dbo].[zpInsertMatchedAddressInParentAddress]
as
Insert Into Orders_ParentAddress
Select
o.OrderNumber as OriginalRecurringOrderNumber,
max(a.AddressID) as ShippingAddressID,
getdate() as CreatedDate
from Address a inner join Orders o
On a.Address1 = o.ShippingAddress1
and a.Address2 = o.ShippingAddress2
and a.City = o.ShippingCity
and a.zip = o.Shippingzip
and a.FirstName = o.ShippingFirstName
and a.customerid = o.customerid
left outer Join Orders_ParentAddress OA
on o.OrderNumber = OA.OriginalRecurringOrderNumber
Where o.ParentOrderNumber is null and OA.OriginalRecurringOrderNumber is null
Group by o.OrderNumber,
o.transactionstate,
a.CustomerID,
a.Address1
order by o.OrderNumber
Update shoppingcart
--Select o.BillingFirstName,o.ShippingFirstName, shoppingcart.*
set shoppingcart.ShippingAddressID = Orders_ParentAddress.ShippingAddressID
From shoppingcart inner join Orders_ParentAddress
on shoppingcart.OriginalRecurringOrderNumber = Orders_ParentAddress.OriginalRecurringOrderNumber
inner join Orders o
on shoppingcart.OriginalRecurringOrderNumber = o.OrderNumber
where o.BillingFirstName <> o.ShippingFirstName
Go
Again I present all the code above without any warranties what-So-Ever, if you lose data it is not my problem. I am just letting you know my solution to this horrible mess.
Freezing Recurring Shipping Address
Copyright © 2012, AspDotNetStorefront. All rights reserved.