>From my experience, I really haven't encountered a situation where I'd recomment not >using UniObjects when accessing a U2 database from an outside application. I've >heard people say you shouldn't use it directly from ASP because of threading issues, >but I've successfully gotten around that by insulating the UniObjects objects within >my own COM objects. ASP calls my COM object, my COM objects creates a UniObjects >object, does what it needs, closes and releases the object, life is good. I've never >even actually tried instantiating the UniObjects directly from ASP to know for sure >it's a problem...just went with what others had told me. For straight data access >where ODBC is fine, UniData's ODBC works fine. It's just a bit of a PITA to set up >initially. I think the biggest benefit of using UniObjects is the ability to utilize >existing subroutines in your U2 system. Even going forward, I find it easier to do a >lot of my business rules in U2 subs and call those subs from UniObjects. Makes for a >pretty elegant n-tiered development environment. Anyway, that's my $.02
-----Original Message----- From: Karjala Koponen [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 1:45 PM To: [EMAIL PROTECTED] Subject: When is developing with UniObjects the correct approach? Can someone lay out, in relatively simple terms for a simple guy, when using UniObjects is the correct approach to developing an application using one of the U2 databases? And, perhaps, when UniObjects would seem attractive but is not, in reality, a good choice? And, yes, I am sure that reality has lots of 'it depends ...'. Thanks, Karjala -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
