Here you can see what is at the moment produced in the UI:

By way of providing some history and context, #446 is the last time we discussed DbDataAdapter support. Really happy that this has been picked up!

Ok if we are going to do this, lets really make it sing and dance. From a UI perspective, I can see where you are going and I'm thinking we can do a bit more.

What if we introduced a new ado message type (CommandParametersMessage) which is for publishing a list of parameters for a given command. With the way this could be done, in a case like this, an "individual" command it could have multiple CommandParametersMessage messages registered.

Off the top of my head CommandParametersMessage would be pretty simple and probably look just like this:

public class CommandParametersMessage : AdoCommandMessage
{
    public CommandParametersMessage(Guid connectionId, Guid commandId, IList<CommandExecutedParamater> parameters)
        : this(connectionId, commandId)
    {
        Parameters = parameters;
    }

    public IList<CommandExecutedParamater> Parameters { get; protected set; }
}

Then in the MessageAggregator would be updated to pickup what ever CommandParametersMessage's have been registered for a given command.

Due to backwards compatibility, we can't remove the Parameters property from CommandExecutedMessage but the MessageAggregator could be responsible for the logic that says if the Parameters on the CommandExecutedMessage is null, check to see what CommandParametersMessage's are present.

Also due to backwards compatibility, I don't think we can update the Parameters property on the CommandMetadata object, but we could add a BatchParameters property, which is IList<IList<CommandParameterMetadata>>.

With this in place, the Sql tab could be updated to process this BatchParameters property in a format the tab can better show. When doing this, you would update the parameter var to ultimately be of type object (with the way Glimpse works it really don't matter what the type is at the end) and if (command.Parameters.Count > 0) it would do what it currently does and else if (command.BatchParameters.Count > 0) then you would create an object that looks similar to the following:

...
else if (command.BatchParameters.Count > 0)
{
    var index = 0;
    var batchParams = new List<object>();
    foreach (var parameterSet in command.BatchParameters) 
    {
        var batchParam = new List<object> ();
        foreach (var parameter in command.Parameters)
        {
            parameters.Add(new { Name = parameter.Name, Value = parameter.Value, Type = parameter.Type, Size parameter.Size });
        }
        batchParams.Add(new { Index = index++, Values = batchParam });
    }
    parameters = batchParams;
}
...

When you do this, I think you should see the UI update to something that looks much more supported.

Does all that make sense? What you think?

p.s. Great PR so far, HUGE thanks!

OK, will try my best here (I always say I'm the console guy, but I might want to improve.)
Regardless of the UI, I still think that the plain fix for the correct handling of the missing Update method should be applied.

Altered the code a bit so that it stores the batched parameters information seperately. Also tweaked the UI a bit, I think the Size column can be visually reused for this.

One you feel things are ready to go, the last thing is to get the cla signed. Once you do that, send it through to anthony dot vanderhoorn at the google place and we can pull in the code. Thanks for all your hard work!

Ok, just wondering if you are good for us to go with pulling this in? As far as I can tell only bit left it to back out the Dup track changes. Once we have that we are good to go :D

Thanks for this contribution @ThomasBombadil!

Done; SQL command do no longer consider parameter values in duplicate checking.

Correct. It's only the base query that is taken into account. The duplicate
logic is trying to find out what queries could be consolidated into one.
Most of the time this is queries that have the same structure but have
different parameters.

On Wednesday, May 7, 2014, Thomas Krüger [email protected] wrote:

Done; SQL command do no longer consider parameter values in duplicate
checking.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/786#issuecomment-42441458
.

Just wondering how things are going here and if you have any outstanding commit?

@ThomasBombadil Just wondering how you got on with this. We are getting a release ready to go and it would be good to have this in it.

Looks like @ThomasBombadil has moved on @avanderhoorn. (Thanks Thomas!)

It seems like there is quite a bit of value here. Can we pull it in as is?

Sorry for having such a long break, but I think this is ok to get pulled.