Actually, the DBS calls only skip input validation (act like a 4 slash stuff) if you omit the "E" flag". If you include the "E" flag, input will be validated, and trying to update an uneditable field will result in an error. However, I think you can still update an ordinary field with write protection of "^".
--- steven mcphelan <[EMAIL PROTECTED]> wrote: > 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 > ===== A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli ==== Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- 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
