C# – Set CommandTimeout used in Strongly Typed DataSet TableAdapter

ado.netcstrongly-typed-datasettimeout

Preamble:

So, over the past 5 years or so various applications and tools have been written here at my company. Unfortunately many of the people who developed these applications used strongly typed datasets, I'm considering outlawing them in our shop now…

One of the larger processes that used strongly typed datasets is now timing out… I intend to rewrite the the whole process using nHibernate in the next few months but for the moment I need to change the timeout to allow our users to use the process, albeit slowly… Unfortunately Microsoft made the commandtimeout methods private so I can't access them directly.

The only solution I've come across so far is to create a partial class for each TableAdapter and include the timeout methods there…

This is quite clunky as it would mean adding partial classes for quite a few TableAdapters…

Anyone know of a more efficient way to handle this?

Best Answer

I "solved" this using reflection. (While the VS2010 model allows exposing the Adapter property, the SelectCommand, etc, will be null prior to GetData, for instance.)

The "ugly code but functional code" I am currently using:

void SetAllCommandTimeouts(object adapter, int timeout)
{
    var commands = adapter.GetType().InvokeMember(
            "CommandCollection",
            BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.NonPublic,
            null, adapter, new object[0]);
    var sqlCommand = (SqlCommand[])commands;
    foreach (var cmd in sqlCommand)
    {
        cmd.CommandTimeout = timeout;
    }
}

// unfortunately this still requires work after a TableAdapter is obtained...
var ta = new MyTableAdapter();
SetAllCommandTimeouts(ta, 120);
var t = ta.GetData();

It is not really possible to type adapter better (although perhaps to a Component), due to lack of common base/interfaces.

Happy coding.

Related Solutions

C# – Adding dumthe Column to strongly typed dataset

The DataBinder will see that you're binding to a DataRow and use its fields rather than any property you define.

You could create a method to do what you want, e.g.:

<%#FormatFlag(DataBinder.Eval(Container.DataItem, "Do_Not_Estimate_Flag" ))%>

where you have a method:

protected string FormatFlag(object doNotEstimateFlag)
{
    if (doNotEstimateFlag.ToString() == "N") return "Yes";
    return "No";
}

An alternative is to modify the query that fills your DataTable. For example, you could have a column "ESTIMATE_ALLOWED" in your typed dataset. The query that fills it would look something like the following (database dependent, this is for SQL Server):

SELECT
   ...
   CASE WHEN Do_Not_Estimate_Flag = 'N' THEN 'Yes' ELSE 'No' END ESTIMATE_ALLOWED,
   ...
FROM
   ...

C# – Strongly Typed DataSet with a set of TableAdapters per database provider

It might be easier to simply ignore the autogenerated TableAdapter commands and use the ADO.Net data access factory objects when it's time for your CRUD operations. That way you can use DbProviderFactory.CreateCommandBuilder to correctly format the parameters in the CRUD operations. Note that this assumes that you aren't doing any tricky property mapping and your schema will remain consistent across data providers.

An aditional option if you use this technique is to create a class that you can enter as the BaseClass property on your TableAdapters. Add an "init"-type method that overrides the connection and the insert, delete, select, and update commands with ones from the factory (based on the auto-generated select command—which should be compatible across most providers).

Best Answer

Related Solutions

C# – Adding dumthe Column to strongly typed dataset

C# – Strongly Typed DataSet with a set of TableAdapters per database provider

Related Topic