OracleCommand.ExecuteReader [b]always[/b] parses the statement?

Question

Hi to all,
we currently run some performance tests using ODP.Net Version 9.2.0.2.102.
It seems that whenever we call command.ExecuteReader, the statement is parsed, allthough we assign the statement before the loop.
Is there any way to achive the desired behaviour, which would be one parse and many executes?
Thanks for any help.
Marcel
This is our test source code:
using System;
using Oracle.DataAccess.Client;
namespace OnlyExecute
     class ExecuteTest
          [STAThread]
          static void Main(string[] args)
               OracleConnection connection = new OracleConnection();
               try
                    connection.ConnectionString = @"Data Source=oratest;User ID=xyz;Password=xyz";
                    connection.Open();
                    OracleCommand command = new OracleCommand();
                    command.Connection = connection;
                    command.CommandText = "SELECT COUNT(*) FROM user_objects";
                    command.Prepare(); //declared as a no-op
                    for (int i = 0; i<5; i++)
                         OracleDataReader reader = command.ExecuteReader();
                         while (reader.Read())
                              Console.WriteLine("{0}", reader[0]);
                         reader.Dispose();
                    command.Dispose();
               finally
                    connection.Close();
Tkprof shows us this output:
SELECT COUNT(*)
FROM
user_objects
call count cpu elapsed disk query current rows
Parse 5 0.01 0.02 0 0 0 0
Execute 5 0.00 0.00 0 0 0 0
Fetch 5 0.15 0.15 0 13115 0 5
total 15 0.16 0.17 0 13115 0 5

Answer 1

Ok,
please put this back in as soon as possible.
I suggest you add a property to the Connection class which let us set whether we want to have the cursors automatically closed or not. This property could then be inherited to all newly created Command objects.
If the default would be not to close the cursors, then people who don't care about scalability and performance would still be happy, and the others could set the property once at connect-time.