See this posting I recently made to CDP on the topic. Then look down two posts to where I provide more detail about the issues and solution. http://tinyurl.com/av4jj When OLEDB does work, I can't tell you how it works with ADO.NET - I'm curious to hear more about this as well.
mv.NET uses a fetch mode so that data is passed from server to client only as needed, effectively providing the data pooling that you ask about. This is different from connection pooling which is very helpful in maximizing use of DBMS licenses - mv.NET supports connection pooling where UO and ODBC/OLEDB do not. mv.NET also fully supports the standard ADO.NET Command functions Select, Insert, Update, and Delete. It can stack multiple commands for any operation. It can use BASIC programs as StoredProcedures to perform Command functions. And it can perform dynamic normalization using extended Dict definitions. But one doesn't need to use the Adapter library to populate ADO.NET DataSets - this can also be done using the BASIC-like syntax of the Core Objects library. For those who want to use ADO.NET to bind data to form controls, mv.NET includes a separate Binding Objects library, which provides a properly formatted DataSource for controls without ADO.NET and without manual coding. When developers are considering the tools they want to use, product support is very important. The support for mv.NET is phenomenal. Responses are quick and some fixes are made and delivered immediately. This is far better than some other products which are fairly static or take months between patches. We were unable to get a fix for ODBC/OLEDB issues from IBM, but we do get fast fixes and enhancements for mv.NET when required. I don't like mv.NET because I sell it. Of all of the products available in our market, I sell it because I like it. In brief response to Glenn Batson: It's my understanding that UO.NET is a managed wrapper around UO, but UO itself is of course unmanaged by the CLR. Errors returned from UO.NET clearly show calls to P/Invoke and UO under the covers. That's not a problem, and mv.NET can use UO as the data conduit as well, but it's important to note that just because there is UO and UO.NET doesn't mean the .NET version is fully managed code. HTH Tony TG@ removethisNebula-RnD.com Nebula R&D is an authorized Distributor for mv.NET http:// removethisNebula-RnD.com/products/mvdotnet/mvdotnet.htm Stuart.Boydell wrote: > I'm wondering what peoples experience of using UniOLEDB is. > General impressions, is it reliable? Does it run in > unmanaged code? How about the CALL interface, does it > work okay from the .NET framework? Does the standard > ADO.NET pooling work okay with it? Are there any gotchas > that have come up? ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
