David, I couldn't agree more. Use the client stuff to interface with the
user, and write the "gutsy" stuff in UniVerse. Almost always do I/O in
UniVerse: apart from anything else, it is so much more robust. If the
client goes down, it doesn't matter, just restart it and maybe start your
procedure again.
Also means that as user interfaces develop, the business rules still stay
the same. If the "data processing" is done in UniVerse, it makes it easy to
adopt new user interfaces.
Cheers, Kate
----- Original Message -----
From: "David Jordan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, September 25, 2007 10:54 AM
Subject: RE: [U2] UniSelectList problem
Hi Charles
Use the slap.lastrecordread property to check end of select rather that
key
<> "". You could run into funny issues including type mismatches that
could
fall over.
Also aren't you meant to look in field 3 not field 2 of the key for 000.
If you are new to VB, it is worth considering your design. With Client
server, it is important to keep the business logic close to the database
and
not with the client. The client should be more for display logic. If you
keep the business logic in subroutines in Uv, then you can reuse the
business logic for web pages, web services and other applications.
Regards
David Jordan
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
