I am looking for suggestions. We are doing some experimenting with future subscription orders that requires the orders to be paid, and I am sure I will have to do this entire operation several times. What is the cleanest way to handle mass payment of multiple orders in Test?
Clarke
Clarke,
This sounds like an interesting predicament to be sure. I must confess myself curious as to what sort of thing would require fake payment of new orders that cannot also be achieved by using past orders. Especially if you took past orders and just updated the order dates or something like that to achieve your required situation.
But to your question, unless someone else has already done this before and has specific scripts for you, it sounds like this is going to have to be something you create yourself. I would suggest opening SQL Profiler, starting a trace, and then paying a couple of orders. Look at the results of the trace, and see what specific procedures are called and actions taken, and then use that to construct what I can only assume would be a rather large and involved cursor that runs through your series of 5K+ orders.
John
Since you asked...
We have a lot of subscribers, with multiple overlapping seasons. As part of our mission to keep these people happy and loyal, we allow them to exchange dates for free. Before we tell them what dates they have for upcoming seasons, we do make certain there are no date conflicts.
However, we also have numerous constituents who want to go to shows with particular friends, and a large chunk of subscribers who are only in town for part of the year. It is a very complicated puzzle, and it is hard on the box office when the tsunami of change requests comes in.
We are exploring (in Test) how practical it will be to try to respect the “attends with” and the seasonal preferences at the same time we resolve date conflicts. Tessitura does give us this information without too much fuss, so if we can save later anguish by doing more work before sending dates to our customers, we should do it. Moreover, if we can encourage people who live here all year to have their subscriptions during the less hectic months, that will also make everyone’s lives better.
The fake payment is just to make the order details in our future subscription season malleable in Test, so we can try the experiment.
Sounds like an interesting time of it for sure, and the idea of being able to unseat-reseat everything makes sense. And that is certainly a more complicated set up than we have here. I do love the idea of exploring ways of simplifying exchanges in general, too. Something like that always seems simpler to the patron than it is to the staff member.
Best of luck!