I did a quick scan of the DD global searching for "not be edited" and came up with more than a hundred hits. Here are a few pertinent examples (some truncation of extra words was done for clarity):
^DD(58.8,1,21,5,0)=This field should NOT be edited directly using VA FileMan. ^DD(58.8001,.01,23,3,0)=This field should not be edited directly using VA FileMan. ^DD(59.7,20.12,23,3,0)=not be edited through the VA FileMan. ^DD(59.7,20.14,21,3,0)=THIS SHOULD NOT BE EDITED. Editing this could cause corrupted data ^DD(350.9,.06,21,4,0)=This field is updated by the IBE Filer and should not be edited with [FileMan] ^DD(727.4,1,21,15,0)=This field should not be edited through FileMan. Use the appropriate There are probably a dozen reasons not to edit some fields through direct FileMan access or even APIs. Some things are fairly obvious: you shouldn't edit a triggered field unless the trigger conditions have been met, you shouldn't alter an audit trail field, you shouldn't alter a timing or status field used by a background process, etc. There are also some that shouldn't be edited because the validation logic or the trigger logic or special cross-reference logic or audit functionality is built into the application and not the DD. Of the hundred or so fields that used the phrase "not be edited" in the description, I don't know how many fall in any given category nor how many more fields should not be edited but either don't mention it or use a different phrasing. [ok, that last sentence made me go take a look: another quick scan shows over 2,000 fields with ^DD(file,field,9)="^".] In any case, as Steve says, if it has been locked you should know why it's locked before you bypass it. Thom H. "If you can keep your head while all those about you are losing theirs, then perhaps you have misunderstood the situation." - - D.K.Moran -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steven mcphelan Sent: Wednesday, February 16, 2005 7:53 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of "~" ? This "^" write protect has been a feature of Fileman for many many years, at least 10-15 years or more. Every database engine incorporates similar features when there is a need to have a database field that is not editable by end users. We can all think of specific examples. I said that a "^" write protected field could not be edited using Fileman enter/edit. I never mentioned that the field could not be changed using Fileman's DBS APIs. Actually I do not know if it can or cannot, I have not tried. My suspicion is that is can be since the Fileman DBS APIs supposedly do not honor most security restrictions. If the database is being accessed by a Fileman DBS API, the underlying assumption is that the program logic honors all relevant security concerns. Having said that, I would exercise great caution in editing any field that is "^" write protected. That field was configured that way for a reason. Unless you understand the reasons for that configuration, you run the high risk of corrupting the integrated VistA database records with inconsistent data and thus run the risk of jeopardizing patient safety. Before anyone makes a change to the system, they should always try to understand why the system is way it is in the first place. In the case of this one field, I believe Tom supposition is correct. There are so many relevant data elements required to make a logical decision of primary provider and attending, that it is not feasible to build that logic in DD structure of a single field. When assigning a provider, the VA uses a process where other user entered data is evaluated to validate the attending. Also, both of these fields were originally designed for inpatients. I do not know the consequences of putting a value in this field for a patient that is not an inpatient. ----- Original Message ----- From: "Jim Self" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Tuesday, February 15, 2005 8:07 PM Subject: RE: [Hardhats-members] How to obtain a write access of "~" ? > I would appreciate more detailed discussion on this point if possible. It would seem from > what you write that such fields cannot be properly edited from the Fileman DBS API. If so, > that would seem to present a severe impediment to any attempts to put a more modern > general database driven user interface (web or Java or etc) on the affected parts of VistA. > > [EMAIL PROTECTED] wrote: > > The use of "^" as a lock is a neat programmer trick to enforce > >security on a field. It can't be stored in #200 because it will alter > >the number of pieces in the node (since it is the delimiter, as Kevin > >noted). It can't even be entered as a lock character through the normal > >FM field edit functions because it is the "abort" character when entered > >at a prompt. And even if you set it into your own DUZ(0), FileMan > >doesn't honor it. The only way to create it is for a programmer to Set > >it. Of course a programmer could Kill it or change it but that might > >have unintended consequences. > > I suspect that there is a considerable amount of processing > >associated with entering a provider that is hard coded into the routines > >and a decision was made that it should not be bypassed no matter what > >the security level of the user. If that is the case, altering > >^DD(2,.104,9) would let you use the field through FM but might cause > >data integrity issues down the road. It would be nice if the Input > >Transform, the Triggers and all of the other cross references in the DD > >covered every business rule associated with a field but that is not the > >case. Some of the rules are so complex and so dependant on the data > >entry situation that whole sets of routines are required to carry out > >the appropriate data updates and linkages. > > > > tjh > > --------------------------------------- > Jim Self > Systems Architect, Lead Developer > VMTH Computer Services, UC Davis > (http://www.vmth.ucdavis.edu/us/jaself) > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
