TableAdapters will support TimeStamp Concurrency Checks

I’m happy to report that we were able to get TimeStamp comparison added. The issue we faced was by the time the DBCommandBuilder API stabilized we were in what we call UI freeze which means we couldn’t change UI elements without some major negotiating. We didn’t think we could get this done, but after reading several posts from Sahil , Bill and others, we took a little more time to see what we can do.
…so, here’s how we got this done. If the developer checks the Concurrency checkbox in the advanced section and we find a TimeStamp column we’ll use it. If we don’t find a TimeStamp we’ll revert back to the compare all columns. What this means is developers really don’t have a way to choose compare all columns if the table has a TimeStamp column, but we figured who would want compare all columns if you’ve got a timestamp.
This work was completed the other day, so the next CTP after the July CTP will have this change.


Comments (4)

  1. Bob Archer says:

    In VFP there are 4 choices:

    1. Key field only

    So, basically no concurency checking here. I assume you have this.

    2. Key and updateable fields.

    So, this is basically equivelent to your "all columns".

    3. Key and modified fields.

    This only adds the modified fields to the where. So, if I change First Name and You change Last name, they still both update without conflit.

    4. Key and Timestamp

    So, this uses timestamp. Which you said you will default to if you select Concurency.

    So you have the equivelent of 1, 3 and 4… and you can choose 1 by not checking Concurency and 3/4 if you check it based on if there is a timestamp column. I personally thinkg you should have all option above, but in the least I think instead of defaulting to ALL columns you should default to MODIFIED columns. With ALL columns there is ALWAYS a conflict (same as timestamp sure) but with MODIFIED there is only an conflict if two people change the same field. Much more intitive I think most people would prefer this option as the non-timestamp option to ALL columns.

  2. diegov says:

    So, with the UI freeze, I guess it will be very difficult to get other low hanging fruit harvested…

    I have to ask you, anyway, to take a look at my suggestion, that the MSDataSetGenerator generates code that uses DBProviderFactory for creating connections and commands (you can see it at and at my blog

    Others have asked you to separate the DataSet from the DataTableAdapters in different files to be able to create database engine specific versions of the adapters. I think by using the DBProviderFactory you solve the issue in the majority of cases.

    If I cannot get this for RTM, what do you think my best options are?

  3. Bill Vaughn says:

    Thanks Steve etal. I know this will be appreciated–except by the authors whose books are already done… 😉

  4. MDeevi says:

    The DataAdaptor in Beta 1 had a generate WebMethod property. In Beta 2 this property isn’t there. I want to know how to web-enable the dataset and update data across the web using the DataSet designer rather than hand coding it, the way I could use the generateWebMethod property.

    Please let us know whether this feature will be available in VS2005 RTM product.