>The following methods, for specific operations, can be called millions of times:
>
>

>    ' Equivalent of VFP StrTran()
>    ' expC1 String
>    ' expC2 Search for specific character
>    ' expC3 Replace
>    Public Function StrTran(ByVal tcSearchIn As String, ByVal tcSearchFor As String, _
>     ByVal tcReplace As String) As String
>        Dim loStringBuilder As StringBuilder = New StringBuilder(tcSearchIn)
>        Return loStringBuilder.Replace(tcSearchFor, tcReplace).ToString()
>    End Function
>

>
>However, this is usually not the case. So, a hit will require about 20 SQL Server requests, which in turn call this method for some adjustments, combined with some other application code logistic that might require it. The problem is if this is called millions of times in a short period, such as within 30 seconds or a minute, I have this "Out of memory" issue. Is there something I am missing here? I am returning a string to the caller. This is fairly simple. It is just two lines.

As the others have said - you do not need a stringbuilder.


You make the situation worse by using a string builder

Explanation
This creates one extra string on the heap

return tcSearchIn.Replace(tcSearchFor, tcReplace);

Next is worse

StringBuilder sb = new StringBuilder(tcSearchIn);
return sb.Replace(tcSearchFor, tcReplace).ToString();

The stringbuilder, initialized with tcSearchIn, holds a char array presentation of the string
This construct creates
(1) a char array on the heap
(2) a new string on the heap

If the solution without the stringbuilder uses something like 100 Mb (temporarily), the solution with the stringbuilder uses 200 Mb.
The extra 100 Mb is used for the char arrays