Stuart Boydell wrote, " I'm wondering what peoples experience of using UniOLEDB is.". Here is our experience.
Our environment experience has been on version 6 of UniData on Windows 2003. 1) Our engineer's had a heck of a time getting the right connection string to work. It has been such a long time back that I don't remember what the problems seemed to revolve around. Once it started we moved on. 2) We used it for an ASP.NET application. I'm not a .NET engineer but since it is a COM DLL I'm certain there was COMInterop involved. Since it was COM then yes it ran in unmanaged code. We were able to implement C# code that called interfaced with the DLL and ran as a Windows service, getting its request from a MSMQ queue. We did not use ADO.NET pooling. I would have to query and engineer on why, but my guess is it does not fit. 3) The real issue is it uses the UniData SQL engine, which did not perform to our expectations. Additionally we implemented our own connection pooling by using window services and MSMQ queues, but we were told this is not how it is intended to be used. It is intended more for a client server implementation. Either as a result of our implementation or the UniOLEDB implementation, we seemed to have issues with timeouts that fully could not be explained. The overhead of using VSG to define the SQL Schema and setting up uci.config and ud_database was not appealing. 4) Note we only used it for querying data and not updates. We have a lot of business logic tied up in UniBasic and SB+ therefore we have to use UniObjects (and RedBack in the past) to call subroutines. So you end up having more database connections than you would like. 5) Our impression has always been that having UniData on Unix on the backend will perform better and be more stable. Our problem is the majority of our market will not support Unix deployments whether on principal or practice. We are running this environment in production though and it is workable just too many issues. Therefore we are moving away from it and using UniObjects.NET and UniData 7.1. We are switching all our SQL statements over to UniQuery statements that generate data to XML. So for most of the simply queries with string data have worked within the MS dataset. We are using XSLT to for the others. One reason is to get in an environment IBM supports and that is not a COM implementation. Additionally IBM says that native access is always faster (native being subroutines and uniquery). If you have questions you can contact me directly. Also though I have not had any experience with it you may want to look at MV.net. Glenn Batson 360.256.4400 www.jenkon.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
