Alexander;

This may not be the best or only way to do things but my approach is a bit different. I use a data class as a part of my project. The data class calls the stored procedure and I do nothing to create .NET objects within the stored procedure. I leave that to the data class.

I have many large tables and customers are happy with the speed.

Tom


>Kevin,
>
>This is function, which contains Fill():
>

>      public StoredProcParameter[] Execute(ref DataSet ds, string strSpName, StoredProcParameter[] _arrParams,TransactionEx tran)
>      {
>         StoredProcParameter[] _arrOutParams = null;
>         using (TransactionHolder tranHolder = new TransactionHolder(tran))
>         {
>            using (SqlCommand sqlCmd = new SqlCommand(strSpName, tranHolder.Connection, tranHolder.SqlTransaction))
>         {
>            sqlCmd.CommandType = CommandType.StoredProcedure;
>            // set command time-out to 15 minites
>            sqlCmd.CommandTimeout = _nStoredProcTimeout;
>
>            // prepare command parameters
>            PrepareStoredProcedureParams(strSpName, sqlCmd, _arrParams);
>
>            using (SqlDataAdapter da = new SqlDataAdapter(sqlCmd))
>            {
>               string strTableName = strSpName;
>               da.Fill(ds, strTableName);
>            }
>            tranHolder.Commit();
>            _arrOutParams = TransformParams(sqlCmd.Parameters);
>         }
>         }
>         return _arrOutParams;
>      }
>

>Connection is already open at that moment, and created with first access to TransactionHolder.Connection property:
>

>	get
>	{
>		return new SqlConnection(strDBConnectionString);
>	}
>

>
>Thank you,
>Alexander
>
>>Alexander,
>>
>>I've never come across that large a difference in times. Can you post the .NET code, from the point where you're doing the connection, to the point where you're doing the Fill()?
>>
>>Thanks,
>>Kevin