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
