Karjala, UniObjects is the quickest route for client/server work with U2. It emulates the native model for direct file and stored procedure operations - you open a file, read a record by key, perform operations, write it back. Fast and very efficient for transactional applications.
The advantage/disadvantage of UniObjects is that it is a permanent per-user connection. In other words, each Objects session operates as a database user, just like a TELNET session. This is essential for integrating with BASIC procedures that expect things like common (persistent) variables to remain between calls and that use pessimistic locking (the default for U2 systems). If you are writing a transactional application for a predictable number of users, UniObjects is the way to go. BTW the best way to consider using UniObjects (and we've been using it since day one of its release) is to code all of your procedures in BASIC on the server first, unit test them, then write the front end to deploy against them. Makes debugging in a 'black box' environment very much easier, and allows you to gain performance improvements by keeping the logic close to the server. Now the drawback is if you want to deploy into a Web/Browser based environment, or any environment where you want to scale up the number of users without scaling up the number of sessions on the database (e.g. a public service where the number of users cannot be predicted) UniObjects does not provide that ability (for the reasons above). For that, you need to use a tool like RedBack, which is specifically designed around a responder mechanism. The final IBM options are OleDB and ODBC. I personally wouldn't use either of these for transactional operations: they are too top heavy as they are adding a whole layer of processing just to make U2 look relational. Which is isn't (really). The only time I would consider these is when interfacing to standard packages that don't understand anything else: and then I'd go for OleDB over ODBC for all of the usual client-side performance reasons. Regards, Brian Leach > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Karjala Koponen > Sent: 27 February 2004 19:45 > 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 > > ______________________________________________________________ > __________ > This email was checked by MessageLabs SkyScan before entering > Microgen. ________________________________________________________________________ This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
