Utility to update pricemaps

Our intrepid DBA is out on vacation this week,  but he has built us a wonderful gadget that allows us to add price maps on to prices.  It is kind of like season manager, but it does not overwrite existing price maps.  So far we have only ever raised prices by $5 at a time, so I have a couple of price maps for each house that are $5 increases.  When we are ready to raise prices on a show I use the gadget to dictate which performances, and which price types get the new price maps added on.  What is great about using the gadget instead of season manager is that I don't have to worry about what the original price map is (weekend vs. matinee price, etc).

If this is something you might be interested in we can check in with Bob when he returns from vacation to see if he can put it together to share.

Thanks for the replies. Our price increases are completely random (ok, maybe not random, but unpredictable). We can change prices $3 in some sections and $10 in others, so creating "standard" pricemaps for those increases wouldn't really work for me. I would still love to pass your wonderful DBA's work on to our wonderful DBA to see if it would be a good place for him to start.

My next question is: What is the advantage and/or disadvantage to 1) creating new pricemaps for the incremental price increases and adding them to the original pricemap or 2) creating completely new pricmaps which reflect the full value of the new pricing and expiring the old pricemaps?

Thanks all!

For us the biggest issue in deciding between the two was that certain reports, and the season overview, count "seats" based on "active 'tickets' pmaps" , not actual seats. We didn't want the increase to show up under "other" on Season Overview and we also didn't want the seats double counted. So that's why we went the "end the old pmap, start a completely new one with the new full value" route. But I can see the other side of it where having that money in "other" could be a totally desirable way to segregate the gain, and that would avoid the double coutning issue. So a second (or third or fourth) map that just adds the additional amount could be quite tidy.

For us the biggest issue in deciding between the two was that certain reports, and the season overview, count "seats" based on "active 'tickets' pmaps" , not actual seats. We didn't want the increase to show up under "other" on Season Overview and we also didn't want the seats double counted. So that's why we went the "end the old pmap, start a completely new one with the new full value" route. But I can see the other side of it where having that money in "other" could be a totally desirable way to segregate the gain, and that would avoid the double coutning issue. So a second (or third or fourth) map that just adds the additional amount could be quite tidy.