Could not find prepared statement with handle 2.

This was a very odd and difficult item to track down and fix.  While working with a production migration of an application to sql server 2005, the application did not work properly.  Of course a 3rd party product, error message from client was ambiguous at best, but obviously something wasn't working.

Upon running a sql profiler to try and capture the error message, success, profiler did capture an error (a true shame the front end client doesn't capture the error, as it is being returned to the client, another example of truly great programming!):

Error: 8179, Severity: 16, State: 2

Could not find prepared statement with handle 2.

A Quick review of this error causes me to be slightly dumb founded, as the error is not happenning in QA.   The vendor suggests changing the SQL Server Services to run under the same service account as the application, not sure where that suggestion comes from, but I politely take it under advisement, while privately thinking that i'm dealing with someone who is more clue-less than me.

I've seen some isolated instances where odd errors happen with SQL Cumulative updates, and this instance is on cumulative update 6, so I begin to wonder if it is an issue with the cumulative update, but that doesn't hold up as QA is also on cu 6.  I've also seen issues with the sp_execute and handles having issues due to client resets and the client MDAC stack, I decide to research this a bit.

Finally I find a KB Article on a similiar subject, not exact, but close enough to try, http://support.microsoft.com/kb/913765/en-us.  FIX: An SqlException exception may occur when you call one of the Execute methods on the instance of the SqlCommand class in an ADO.NET 2.0 application. 

I ask the vendor about their data access layer, versions of ado.net and patches. The vendor response is less than enlighting and only re-enforces my belief that i'm dealing with less than steller support.  Remaining composed is critical, as you can't insult the vendor, we're using their product and I'm in the middle of production upgrade that is melting down, with the business waiting...must keep composed and concentrate on the issue....a few choice explicitives are released, thankfully the mute button works properly.

Now why the DBA has to troubleshoot the data access layer of the client, I don't know, but it never fails that it does come down to this.... The DBA has to be one of the most knowledgeable subject matter experts, and not just of the database, but the entire domain that is involved with the application.

Short story ends, patch above is applied, to the client, and all works.  What a shock.