TableAdapter Conflict Options

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
Steve Lasker
Program Manager
Visual Studio Smart Client Data

Comments (1)

  1. Bill Vaughn says:

    Frankly, I think this sucks. We’ve been talking about this for five years—ever since the first Command(Don’tUse)Builder was released in Betas. This functionality is, was and has always been very important to those trying to eek performance and functionality out of Visual Studio—you agreed and promised a fix. I think it’s sad that in all this time your team has not been able to implement even the most basic RowVer/TimeStamp functionality. As I said, it’s important first and foremost to fix what you have before adding new whiz-bang features. If you want people to convert from Visual Basic 6.0 and ADO classic, you need to concentrate on the functionality that they had way back then. In my opinion you still aren’t there and you haven’t made much progress. Early in the cycle we lost server-side cursors (of course the implementation was unacceptable—you were trying for dynamic cursors to keep from having to deal with cache management) and we lost asynchronous connections and other ADO classic features that make a difference to developers. Now that SNAC is here the requirement to convert seems to have been lessened—developers can access new SQL Server 2005 features from Visual Basic 6.0—without ADO.NET. I’m very disappointed and disheartened.

Skip to main content