Brian, I think you're missing one of the main features of ADO.NET, which is to make the source of your data independent of how your application works with it. I don't necessarily want to access my MV environment via SQL, but I do want to be able to pull the data into a dataset so that it's transparent to my app that the data is MV. How you get the data into the dataset is irrelevant, but despite the "data access flavor of the week" sentiment which I fully agree with, all current databases have at least one data provider which will work with the current paradigm (there's that dreaded word again). Once you get the data into the dataset, yes, you're going to use SQL queries on it for retrieval and update. Now how that translates with a disconnected table that's Relational on the outside and MV on the inside ... ?
So if IBM is going to put ".NET" onto the back end of the name of a connectivity component for a database, I'd kinda hope that they go all the way and provide the same sort of access that the world expects and gets for all other databases. If it's some custom API for the back end that doesn't conform to the standards for a data provider, OK, I think MV people can live with that, but if the resulting data needs to be manually force fed into a dataset in order to make it work with standard .NET tools, then there isn't much of a point of having a UO.NET except for marketing. I trust IBM has done a lot more and I apologize that I haven't read the docs on it yet - this is an open comment to Brian rather than a comment on the UO.NET itself. In addition to evaluating UO.NET on its own merits, I'm curious about how it's going to position with PDP.NET from Raining Data. From what I see so far, subject to change of course, if you want basic managed connectivity as a step up from VB6, then UO.NET should be fine. But if you want more of a real .NET feel (what .NET people expect out of .NET products) then PDP.NET is still a worthy product for advanced U2 development. 2 cents, ching ching Tony Nebula R&D Brian Leach wrote: [snipped] > David, > > The history of ODBC and OleDB on U2 shows what a bad idea that is. > > Frankly, accessing U2 using relational methods is pretty much a waste > of time - ... > > So I for one am glad that UniObjects.NET does not try to become an > ADO.NET provider but keeps to the best way to talk to these > databases. I have no objections to seeing a *different* provider for > ADO.NET - but let's leave it out of UniObjects. > > Perhaps I'm just too cynical but I've been burned enough times by the > MS strategic data visions. ADO.NET may be the latest flavour of the > month, but that doesn't mean it is any good. ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
