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: <[email protected]> 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 > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
