Thank you Brian for your observations.
I'm of the Jurrasic Pick era with 95% of my world being mv and the other 5%
being MS Access. I am enjoying the GUI development environment of Accuterm
and may convert upcoming MS clients to that GUI front end on top of D3 as
the client doesn't care that much about back end databases when it has a
nice front end.
I've inherited many, many systems (45 in the last 10 years alone) with their
incredibly diverse and over-written methods for many, many tasks. Certainly
I've not seen everything but I've seen a ton of programming of which I can
extract the best methods to continuously add to my own personal library of
what's effecient. I can also ignore the less intelligent ineffeciencies.
My download utility's purpose is for the one-time project. It's pretty much
a TCL only command issued typically by the only cook in the kitchen, me.
I've written many portable subs that I install at all of my clients for
their recurring needs. While there could be some extension of
unidata/universe that allows direct writing to a PC folder, most
implementations don't have it that easy. The native ones don't have it at
all.
Thus I develop my subroutines and tweak them per mv flavour on which they're
installed. Thus whether it's UD/UV, D3, Mvbase, Microdata or native systems,
DOWNLOAD works the same as well as most of my subroutines.
If I were to add DOWNLOAD to a proc or a program, my experience would
prevent me from performing 5 million executes and approach the solution with
a more effecient method. I have subs that easily make CSV's or simple HTML's
and have automated many import/export facilities including unix-ftp, MS-ftp,
VB scripts and other contemporary attachments.
Thus, if my clients were to convert to other version of MV, only my subs
need be changed and not the local changes in dozens if not hundreds of
programs.
One sub that answered the original post is called GET.DICT(FILE, ID, VAL)
which has the embedded English sentence mentioned earlier. I use it in
DOWNLOAD as well as I've put it in regular CUSTOMER maintenance or other
single item programs to get the results of a complex expression instead of
writing the same code again. If the logic is complex or has the possibility
of being changed, business-wise, changing the dict reference causes its use
elsewhere to be changed as well.
One thing I miss in D3 that I enjoy in UD/UV is the more advanced called
subs from dict items. D3's versions can only pass (return) one parameter in
the parameter string. It has access (ACCESS()) to the item-id, file and
record but only once you're in the sub. It also gets a little funky when
returning multi-valued values.
The joy in the UD/UV called subs is that the sub being called doesn't care
if it's called from English or a basic program. Thus, the intelligence can
be shared whereby in D3 is has to be replicated or managed in a more klugy
way. Score one for U2.
My 3 cents.
Mark Johnson
- Original Message -
From: Brian Leach [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, August 03, 2006 9:24 AM
Subject: RE: [U2] Using DICT items in basic program
Tim/Mark
You both make good points. Mark was responding to a specific requirement
(how to get a single field for a single record) with one working and
largely
cross platform solution. Obviously getting a tranch of data requires a
different solution. I don't think Mark was seriously suggesting that a
million executes is a way to go.
Personally I would now look towards XML as that seems to be the best
current
option for integrating the enquiry and development languages - finally
something native to close that gap in the PICK model - though in the past
I
have used everything from REFORMAT (slow but predicatable) to creating
compound I Descriptors of the form:
CONVERT(@FM:@VM:@SVM,CHAR(1):CHAR(2):CHAR(3),field1:@FM:field2:@FM ...)
etc
and doing a SELECT .. SAVING that descriptor. Each ReadNext then gets an
entire row - just CONVERT() the delimiters back again - and the result is
extremely fast. Doesn't work well with WHEN clauses though - but then few
things really do :(
Tim's point about DOWNLOAD does have some merit. But Mark is an old pro
(sorry, forgive the 'old' bit ! ) and I'm sure he writes his utilities in
a
way that other developers can work out what they do grin. Calling a
utility without looking to see how it works first - well that's just lazy.
And it's not just MV that will screw up in those cases! You wouldn't
expect
to call a SQL Server or Oracle stored procedure without some DBA's
approval,
would you?
Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
