Error "Cannot start transaction while in firehose mode" in terminal server hosted legacy application...

Hi all,

We have a legacy client-server client application (developed with Centura
SQL Windows/32) that connects to a SQL Server 2000 database. In our LAN it
works without mayor flaws. Recently we added support to some remote
offices by using W2K terminal server. The decision was not to allow direct
connection of the terminal server (that is located on a demilitarized
zone, out of the corporate LAN firewall) to the internal SQL Server. We
did the following: We setup an "external" Sql Server 2000 database that
relays the stored procedure calls into the internal real SQL database.
This is done by making a set of stored procedures in the external server
with the same parameters that the rela one, but they only call the real sp
by calling

Exec realserver.realdatabase.dbo.StoredProcName

This way the users connected to the terminal server can access the real
database without any changes to the legacy client application. This works.
Initially we had no mayor problems, but when the number of terminal server
users increased, we get more and more frequently the following error from
the client:
Microsoft Sql Server:7312[Microsoft][ODBC SQL Server Driver][SQL
Server][OLE/DB provider returned message: Cannot start transaction while
in firehose mode.] Microsoft SQL Server:7300[Microsoft]
When this errors happens, the user closes the connection to the terminal
server, reopens a new connection, opens again the legacy application and
the error reappears. I should stop and restart the SQL Server service on
the "external server" in order to allow the user operate normally.
We never had such error when working on the LAN, even when there are many
instances of the client application running on the same machine, so it is
not a fault of the client application. I suppoused it can be caused by
terminal server ODBC connection pooling. May be some way one instance is
using the other's corrupted connection. Then I disabled connection pooling
for the SQL Server driver in the terminal server and nothing changed.
Where is the problem?
This problems has a strategic importance for us 'cause we are considering
increase the number of remote offices connected by terminal server to the
corporate LAN.
Any idea is welcomed.

Thanks in advance
Sammy