Developers often ask about better concurrency options on DataAdapters and of course our new TableAdapters. This was a difficult call. Just so you know we do care, , the ConflictOptions enum/flags that appear on SqlCommandBuilder was actually by request of our design time team. Early on this enum/flags had over a dozen or so values, all of which could be OR’d together. As the product started to stabilize the runtime team wasn’t able to finish and guarantee that all the combinations would work. There was a lot going on at the time and the DataWorks team had to balance their feature workload to get ready to ship. We discussed conflict options at length, and at the end of the day DataWorks just couldn’t fit this in the schedule. We had to do some major scale back work in order to meet the schedule. What remains is compare all values, only compare the PK and TimeStamp. Unfortunately, because of the late switch we couldn’t get the logic in our designers to know whether we could enable TimeStamp based on the table selected in the wizard. This is a bit lame I realize but one of the things we do as we close down a product cycle is focus on the features that were core goals. Issues that have work arounds get a lower priority then issues that block a core feature and either don’t have a work around or would just be too goofy to ship. We also take into consideration if we can fix it in the next release without breaking backwards compat. Unfortunately we had to make the call to revert back to Everett behavior here. We have the infrastructure in place to add this post Whidbey. I don’t remember the exact tradeoff at the time, but one feature we knew we wanted to add was the nullable support on the TableAdapter parameters. Since TableAdapters are new components, this was our chance to get it right without backwards compat issues in VNext. And, it enables one more piece of the impediance mismatch between database types and runtime types.
Just another scary insight into the minds of the team
Visual Studio Smart Client Data