Mono doesn’t need DAAB, and 3 rounds with ADO.NET

I recently posted about how the MS patterns and practices License sucks, and how I’d like to use DAAB with Mono. Well, the license still sucks, but I found Mono’s Provider Factory. This looks good enough. It may not be all of what DAAB is, but it is an excellent alternative. It even does important things which DAAB neglects, namely exposing an IDbDataAdapter factory.

I went 3 rounds with ADO.NET today and lost. But it was the most educational 3 rounds ever. It was like when Rocky fought Apollo Creed and lost at the beginning of the movie, but trained and got smart and got quick and became a tank, a steel Italian tank. Then at the end of the movie Rocky went a full 15 rounds with Apollo and won. That kid has heart. Well, I won’t be going 15 rounds. I’ll win in a KO in the first round next time. ADO.NET is mine. Now don’t get me wrong, this was not ADO.NET 101. I’ve used ADO.NET for almost a year now. I’ve use DataReader to just read things in an old school way (reminicent of PHP) and DataAdapter to fill a DataSet. What I had not done was use a CommandBuilder to actually do the CUD part of CRUD. Well, using CommandBuilder with DAAB was obviously not something the DAAB designers intended, its no problem, an easy work around. However, I’m working on syncronizing two tables in two different databases. CommandBuilder doesn’t expect that you will want to update an identity column.

I’m not entirely sure at this point, but I think I can just add the identity column as a Parameter to the InsertCommand of my DataAdapter. It should work, I just have to work out the kinks. If not, I can just create all my own Commands for use with the Adapter, but I’d rather just augment what CommandBuilder does. Either way it is just another days work.