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
