Since this seems to be a new issue for Kevin and he has been crawling around in VistA for a while now, is this sort of field not rare as hen's teeth?
I would think that some internal policy in the VA might be responsible for locking up this field. For instance, perhaps they did not want patients to be assigned just one provider when they were taken care of by a team that might rotate on or off a service. On Tuesday 15 February 2005 08:07 pm, Jim Self wrote: > 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 -- Nancy Anthracite ------------------------------------------------------- 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
