New CCBill Admin - Discuss

[Toby]

Originally Posted by Greenie

That's a lie. I refuse to believe that the programmers could not include the paysite's & affiliates code into the new system.

Hell, here's the solution: if my new "unique" account number is 1234567, then have a database that has ALL my old codes in it. Each time it sees one, like 581222 for Amateur facials, replace it with 1234567.

Problem solved.

Greenie, I understand that you don't like change, but I really think you're being a little unreasonable about this.

Adding that additional data for every existing affiliate and the corresponding data lookup for every affiliate link processed isn't as simple as you make it sound. There are substantial side effects and consequences. Hence my mentioning "large high volume database remaining online and stable" in my earlier post.

[MadCat]

Originally Posted by Toby

Greenie, I understand that you don't like change, but I really think you're being a little unreasonable about this.

Adding that additional data for every existing affiliate and the corresponding data lookup for every affiliate link processed isn't as simple as you make it sound. There are substantial side effects and consequences. Hence my mentioning "large high volume database remaining online and stable" in my earlier post.

Also to grab this in from your earlier post:

Yes, that would have been an ideal solution, but when you're talking about implenting changes across such a large high volume database while it remains online and stable, there are simply some limitations to what can be done.

There's a reason that in the software development best practices there is such a thing as a "testing environment" -- a set of systems that mimics the production environment that can be used for testing.

Also, the procedure to switch from one db to another db is this:

1: Get new hardware
2: Set up new DB (dbnew)
3: Poke up the new system and point it at dbnew
4: The new system should in fact be able to update both the dbnew and the old db (dbold).
5: Run both db's simultaneously
6: check db's daily for differences
7: fix whatever is causing differences
8: switch over fully

Presto.

There's a ton of methods to do a live transfer between different db's -- high volume or not. If they are doing anywhere near the amount of db transactions I think they're doing they will have a high availability cluster anyway, and the money to get a 2nd cluster set up for the new system.

All it requires is people that know what they're doing.