I think you either misunderstood the point that was being made ("never trust the client") or misstated what happened in your original post. You wrote:
The client i wrote was filtering inputs and was making sure that only the expected parameters were sent to the server.
As was stated earlier, you can't rely on the client to filter the inputs, so putting the filtering code back into the client won't solve the problem. The filtering needs to happen on the server. Otherwise, there's nothing to keep someone from writing their own client program to send whatever data to the server.
Also, the most damaging attack (in my opinion) is not one that destroys or obviously corrupts the data. That type of attack is noticed quickly and the data is soon restored from a backup. The most damaging attack is one that modifies the data in small ways: swapping the address of one company with that of another, randomly modifying balances, randomly creating bogus debits/credits, etc. By the time people notice something is wrong (such as when incorrect bills are sent to the wrong companies), you're faced with spending a huge amount of time fixing it. That means tracking down when the problems began, then either restoring the database from just before that point (which might mean blowing away nearly a month's worth of input) or examining each record to determine what is correct and what is not. Not to mention the hit to the company's reputation if they've sent Company A's bill to Company B.
