It seems to me that VistA is not just a database, with secondarily important routines to adjust that data. Instead, it seems that it is both. Thus this "locked" database field is not supposed to be altered except through the proper channels (the program code.)
So it may well be problematic trying to work with the data by circumventing the interaction code. Kevin --- Jim Self <[EMAIL PROTECTED]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
