>>As Rob points out there's no advantage, memory wise, in using StringBuilder() here - you are still creating a new string with each call. If you are doing multiple replaces with repeated calls for the same initial string then this shows one approach (and an interesting speed comparison):
>
>A client application does a lot of SQL Server requests. One of them is looping over 75000 records. Each of them has a very intensive logic and applies a bunch of additional requests. So, there is no initial point. All of those locations are not related to another. So, they have to call this method for some replacements. So, it is not the same initial string. I believe, if we would look in the archive here, that this enhancement to StrTran() method was turned into a StringBuilder() approach for performance issue when negotiating with a large string where some replaces are needed. At first, it was using a string replace. But, the fact that it now uses a StringBuilder(), on one very particular situation, it causes this situation. Knowing that all those calls do not come from the same initial string, is the link you provided still applicable?

Gregory's given a good explanation of the difference in memory footprint between a straight String.Replace() and using StringBuilder() where only one 'replace' is being made to the string - StringBuilder() only begins to be advantageous when multiple 'replaces' are made to the same string. The first link I provided won't be applicable with just one replace operation.

The second link *might* be applicable - it provides a way of detecting an upcoming OOM exception (from which you can't recover) and instead throws a 'InsufficientMemoryException' which can be trapped an would allow for recovery. But, without knowing the context, I don't know what action you might want to take in that scenario.....