This touches on the downside of the naming styles for variables. It seems like these alias's are an attempt to be like other databases which have no percieved numerical elements, rather TABLENAME<DOT>FIELDNAME as the only way to get at the data. In MV you get the best of both worlds. If you have SALES.JAN and SALES.FEB etc as alias's, you can still FOR...NEXT 1-12 to clear them.
Your Manage-2000 concept brings forth another question. A data file of 40 fields may have 100 or more dictionary items referencing to those 40 real fields. Does Manage-2000 take coorelative-style dict items into consideration and make them useful in a program or it knows to skip those. If it does then I'd be interested to see how that works. I've tried many ways to include dict items in data/basic programs and all seem tricky at best. It appears that trying to process 002, 007 or 008 correlatives inside of a program is just a different interpeter. And that's beyond my scope to write a dict item interpeter. About the only way that I've been able to use the complete collection of dict items in a program is to create a single record, single field English sentence and CAPTURE the answer (minus the headings and other peripheral stuff). I have a utility for this that I localize per platform and works for both regular and multi-valued fields. It's a little funky on MvBase though. Thanks. Mark Johnson ----- Original Message ----- From: "Allen E. Elwood" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 12, 2005 7:58 PM Subject: RE: [U2] Remove Scenario > You'd hate Manage-2000. Their DICT.BUILD creates a MFG.LAYOUTS file which > creates two INCLUDES for each file. All the dict items are prefixed with > the file name, and then the rest of the dict item is at the end. And the > standard at which all programmers are forced, er...*encouraged* to use > mandate these includes for each file. > > So everything is like: > > IF CM.Credit_Limit > ARH.Dollars_Outstanding THEN > blablabla > > Makes is a real PITA to work with sometimes. Especially when you have > everything memorized by the attr#, and now you have to remember sometimes > very similar names for fairly different dict items. > > And the same for the DEBUG, you'll get a symbol not found and then have to > put in CM.REC<XX> so it really forces you to have to remember or keep a > cheat sheet handy when debugging. > > fwiw....Allen > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > Sent: Friday, August 12, 2005 16:32 > To: [email protected] > Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > > > I'll go out on a limb here and make a conclusive opinion. > > I don't like EQUATES inside of a program. That doesn't mean I don't like > EQUATES. I just don't like them as some form of higher programming when they > are in a program. > > I do like them in a consistent manner and the way to make them consistent is > in an INCLUDE. Thus have a SETUP include that has all of the housekeeping > crap like > EQUATE TRUE TO 1, FALSE TO 0 > EQUATE AM TO CHAR254, 253, 252 ETC > PROMPT "" > EQUATE BELL TO CHAR(8) > blah, blah, blah. > > and then have your file-defining EQUATES in their own single INCLUDE. Thus > the filehandle, DIM size and all of the things you are trying to normalize > are consistent. > > Like before, I've seen too many scattered examples of half-baked ideas of > EQUATES that really don't impress me much. Sometimes I see one or two > EQUATES like > EQUATE CUSTNAME TO 1 > EQUATE PRODDESC TO 6 > > and they're used properly but in the same program you see: > > PRINT CUSTREC<CUSTNAME>"L#30":" ":CUSTREC<49>"D2/" > > C'mon. Either all or none at all. > > That begs the question. EQUATE the attribute number for a dynamic array > (compiler replacement) or EQUATE the field for a dimensioned array, (alias > concept). I've seen many examples of both but I think they lean more towards > the DIM variety. And the survey says....... > > Thanks. > > ----- Original Message ----- > From: "Marilyn Hilb" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Friday, August 12, 2005 2:48 PM > Subject: RE: [Maybe spam] RE: [U2] Remove Scenario > > > > I am on MasterPack. Whenever I 'deliver' a modification with a dictionary > on it from one system to another, that process actually re-builds the equate > includes for any new dictionary item I may have added. So yup, got lots of > these, but not something I or any recent programmer before me did > intentionally. > > > > > > -----Original Message----- > > From: Mark Johnson [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 12, 2005 1:35 PM > > To: [email protected] > > Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > > > > I'll add another localized comment from my experience. > > > > My client with the 17 different expressions of CUSTOMER NAME actually had > 17 > > versions of > > > > EQUATE CUST.NAME.ATTRIBUTE TO 1 > > EQUATE CUSTOMER.NAME.ATT TO 1 > > EQUATE CNAME.ATR TO 1 > > etc. > > > > So I still stand by my original belief that if these EQUATES are localized > > as in this example, then you are missing the point and only adding to the > > confusion. You cannot remember which version is in each different program > > without going to the top of the program to find it. > > > > Only by having these EQUATES in an application-wide INCLUDE concept can > its > > value be realized. Otherwise, it's just another half-baked inconsistent > > method. > > > > My 1 cent. > > Mark Johnson > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Friday, August 12, 2005 1:27 PM > > Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > > > > > > > In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, > > > [EMAIL PROTECTED] writes: > > > > > > > > > > Thank you for clearing up the issue of using EQUATES. I was ready to > > pile > > > > on you along with Les Hewkin. We use EQUATES and live by what they > > > > describe. I have learned never to trust DICTS. > > > > > > The only problem being (or at least last time I checked) was that RAID > > > doesn't understand EQUATES. So you're walking through the code and see > > > CUST.ADDRESS = '' > > > and you type > > > */CUST.ADDRESS > > > and it says whatever something like "variable not found" or something I > > > forget. > > > > > > So is there a downside to using a construct like > > > A.CUST.ADDRESS = 40 > > > CUST.REC<A.CUST.ADDRESS> = "" > > > > > > Then RAID is quite happy with it. > > > > > > Will Johnson > > > ------- > > > 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/ > > ------- > > 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/ > ------- > 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/
