the appl as I understand it is a many to many interface.
to my knowledge no one has discussed migration, in detail, as an
(semi)automated process but I think it would be a good thread.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Ean Schuessler sent the following on 12/13/2010 4:57 AM:
Calling it an "application" seems fine. Is there a good example of an
upgradeable multi-table application?
----- "BJ Freeman" wrote:
how about a contactlistappl that other entities can use in the future
change the contactlistid to the contactlistappl.
then would also a allow a upfrade path with a service.
Ean Schuessler sent the following on 12/12/2010 4:50 PM:
Currently, contact lists are associated with marketing campaigns via a
contactListId field on ContactList. It seems to me that contact lists would be
used repeatedly over a long period of time by numerous campaigns. Would there
be an objection to deprecating the marketingCampaignId field in ContactList and
creating a new MarketingCampaignContactList entity? I would imagine that this
entity would follow the fromDate/thruDate pattern.
