ADO inserting extra T-SQL text

Question

According to the documentation for the Execute Method of the ADO Connection Object: 
CommandText
A String value that contains the SQL statement, stored procedure, a URL, or provider-specific text to execute. Optionally, table names can be used but only if the provider is SQL aware. For example if a table
name of "Customers" is used, ADO will automatically prepend the standard SQL Select syntax to form and pass "SELECT * FROM Customers" as a Transact-SQL statement to the provider.
Now when I invoke a stored procedure in the text as "EXECUTE usp_MyStoredProc @Param1  = " & someVal (this is classic ASP), I get an error on occasion that makes no sense in relation to the text.  Upon reviewing the submitted SQL
in the SQL Server Profiler I see "select * from EXECUTE usp_MyStoredProc @Param1  =  0" (for example from the above).  So why does ADO arbitrarily prepend the extra command portion in this instance?  Can I turn this off?
 I am using the SQL Server Native Client provider and I am randomly seeing this on my SQL Server 2005, 2008 and 20012 instances.  No rhyme or reason as to when it decides to this.
Your insight is most welcome on this issue.

Answer 1

Sky13 wrote:
... and you can cut and past. Impressive.Everybody relax, you're so excitable you lost your E there (paste / past) :)
I'm still not sure I follow what capturing the SQL Text is going to do for you.
You have an application that is misbehaving and putting in data you say shouldn't be allowed. How is capturing the SQL Text going to help you identify where in the application that SQL is coming from? Seems like it would be just as simple to search the code for the table name in question for all insert statements (or API's that allow insert into the table in question).
If on the other hand you put a check in the trigger that raises an application error when the condition is hit (you can't use a check constraint referencing sysdate, not with your Oracle version, and even in version 11 it's not straight forward to do) and apply that to a test environment, you can run the application or have others run it for you and it will become pretty evident in a hurry which portion of the application is abusing your data, since the application will (should) stop working.
I don't see the value of adding a potentially damaging trigger in to a production environment (that's been my impression of what you plan on doing with this, please correct me if I'm mistaken).
Cheers,