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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ~ ?
Kevin, you have gained good insights into VistA through your dogged exploration of it. Other systems built on a relational database likely have business rules that are not in the database itself, so the business logic is important for maintaining the tables properly. Just going in with a different client and altering the contents of relational tables with SQL could mess up such a system if you happen to operate on some pivotal fields. The key to putting a new face on VistA, it seems to me, is to have well documented interfaces that implement operations that are specified in terms of the domain (i.e. add an Rx, delete a scheduled appt, etc.). Actually, it seems even better if the granularity of some of these interfaces is small enough to be reused and still efficiently assembled to do the domain specific transactions (like some of the RPCs in VistA). As the VA is doing their re-engineering of parts of VistA, they are having to tease out all the rules and data elements that were implemented in the roll-n-scroll based systems and recast the intent in their new technology. Kevin Toppenberg wrote: 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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net 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=6595alloc_id=14396op=click
RE: [Hardhats-members] How to obtain a write access of ~ ?
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
Re: [Hardhats-members] How to obtain a write access of ^ ?
One major use of ^(9)="^" was for computed fields, which clearly cannot be edited and have no place to be filed. Those account for most if not all of the 2000 you found. I'm guessing that programmers took advantage of the screening out of computed fields--done by checking for "^" in ^(9)--to also implement screens for other fields that should not be edited via FileMan because of possible data corruption issues. Marianne Follingstad 301 251 0139 "Holloway, Thomas (EDS)" wrote: 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
Re: [Hardhats-members] How to obtain a write access of ~ ?
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=6595alloc_id=14396op=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
Re: [Hardhats-members] How to obtain a write access of ^ ?
I do not know if the feature changed about S DUZ(0)=^. I do not remember ever being able to edit a field that was write protected with the ^. But I have not tried S DUZ(0)=^ in years. Uneditable and write protection using ^ are two different things with similarities. An uneditable field is selectable as an edit field. A ^ write protected field is not selectable. One can enter data in an uneditable field if there is no current value in that field. Once there is a value one cannot edit nor delete the value. Since the field was selectable, FM will display the field with its value and then immediately move to the next field in the field string. Thus you can see the value in the field in Edit mode, but you cannot edit that field. - Original Message - From: Greg Woodhouse [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Monday, February 14, 2005 11:29 AM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? I suspect something else must be going on. I tried setting the write protection to ^ (BTW, you can do this because the field sits by itself on a global node in the DD) and, sure enough, DUZ(0)=@ does trump ^, just as Marianne said. If yhou were using DIC, I'd think perhaps you had a pre-selection action. Does the file have a special lookup routine? --- Greg Kreis [EMAIL PROTECTED] wrote: Has this been changed? It used to be that you could set DUZ(0)=^ and it would permit the edit. As mentioned here, it was a want to 'write protect' a field so that only a trigger could enter the data (a trigger asks if you want to write protect a field). Holloway, Thomas (EDS) 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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON
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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] How to obtain a write access of ~ ?
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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net 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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ~ ?
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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] How to obtain a write access of ^ ?
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: Actually, the @ is a superaccess that should be sufficient for any situation, no matter what the file DD, read, write, delete access code is. In other words, you should not have any difficulty doing anything in any file. Are you having difficulty or are you just anticipating having difficult
Re: [Hardhats-members] How to obtain a write access of ^ ?
BUFFER ERROR That should have been 'it is a way', not 'it was a
want'. If only I could keep my typing buffer in sync with my thinking
buffer ;-)
Greg Kreis wrote:
Has this been changed? It used to be that you could set DUZ(0)="^" and
it would permit the edit. As mentioned here, it was a want to 'write
protect' a field so that only a trigger could enter the data (a trigger
asks if you want to write protect a field).
Holloway, Thomas (EDS) 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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Chris
Richardson
Sent: Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn't use Fileman to
Fill
the field. That would keep most users (except for programmers) from
changing the data. Interesting business rule. I see the value of it.
- Original Message -
From: "steven mcphelan" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 7:50 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
If a field is write protected with the "^" then no DUZ(0) will allow
you
to
edit that field using Fileman enter/edit.
- Original Message -
From: "Nancy Anthracite" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 9:57 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Maybe it is because you don't have a patient who has been admitted!
Note
that
it says inpatient below.
On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote:
I noted that only active providers are allowed, so do your docs
have
the
PROVIDER key and the only thing I could see that might have to do
with
that
and show activity was the PERSON CLASS, in file 200, which has an
expiration date which I believe you can leave blank. Do your docs
have
a
person class of physician or one of those variants?
2,.104PROVIDER .104;1 POINTER TO NEW PERSON
FILE
(#200)
INPUT TRANSFORM: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
D
^DIC K DIC S DIC=DIE,X=+Y K:Y0 X
LAST EDITED: DEC 07, 1994
HELP-PROMPT: The provider currently assigned to
this
inpatient applicant.
DESCRIPTION: From the available listing select
the
provider who is currently treating this patient.
SCREEN: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
EXPLANATION: Allow only active providers.
EXECUTABLE HELP: D HELP^DGPMDD(DA,DT)
CROSS-REFERENCE: 2^APR
RE: [Hardhats-members] How to obtain a write access of ^ ?
Greg asked: "Has this been changed?"
I don't know Greg. I just tested it by putting a ^ in
DUZ(0) and that stilldidn't allow me to select the field. Based on
that result,it was an assumption on my part that FileMan doesn't honor
that particular character as a key to unlock the lock. Possibly there was
a flaw in my test?
tjh
"It's a philosophy of life - - go whole hog and
accept the consequences.", Robert Fulghum
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg
KreisSent: Monday, February 14, 2005 10:22 AMTo:
hardhats-members@lists.sourceforge.netSubject: Re: [Hardhats-members]
How to obtain a write access of "^" ?
BUFFER ERROR That should have been 'it is a way', not 'it was
a want'. If only I could keep my typing buffer in sync with my thinking
buffer ;-)Greg Kreis wrote:
Has this
been changed? It used to be that you could set DUZ(0)="^" and it would
permit the edit. As mentioned here, it was a want to 'write protect' a
field so that only a trigger could enter the data (a trigger asks if you want
to write protect a field).Holloway, Thomas (EDS) 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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Chris
Richardson
Sent: Monday, February 14, 2005 2:34 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Stephen;
Then that sounds like the loading of this field is programatic (data
loaded
at the time of the action being recorded) and doesn't use Fileman to
Fill
the field. That would keep most users (except for programmers) from
changing the data. Interesting business rule. I see the value of it.
- Original Message -
From: "steven mcphelan" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 7:50 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
If a field is write protected with the "^" then no DUZ(0) will allow
you
to
edit that field using Fileman enter/edit.
- Original Message -
From: "Nancy Anthracite" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Sunday, February 13, 2005 9:57 PM
Subject: Re: [Hardhats-members] How to obtain a write access of "^" ?
Maybe it is because you don't have a patient who has been admitted!
Note
that
it says inpatient below.
On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote:
I noted that only active providers are allowed, so do your docs
have
the
PROVIDER key and the only thing I could see that might have to do
with
that
and show activity was the PERSON CLASS, in file 200, which has an
expiration date which I believe you can leave blank. Do your docs
have
a
person class of physician or one of those variants?
2,.104PROVIDER .104;1 POINTER TO NEW PERSON
FILE
(#200)
INPUT TRANSFORM: S DIC("S")="I
$$SCREEN^DGPMDD(Y,DA,DT)"
D
^DIC K DIC S DIC=DIE,X=+Y K:Y0 X
LAST EDITED: DEC 07, 1994
HELP-PROMPT: The provider currently assigned to
this
inpatient applicant.
DESCRIPTION: From the available listing select
the
RE: [Hardhats-members] How to obtain a write access of ^ ?
Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin
RE: [Hardhats-members] How to obtain a write access of ^ ?
Here's an example of what happens when you try to edit an uneditable field. (TEST is both the field name and the .01 field of the record with ien 1, which is a little confusing.) Select MESSAGE TEMPLATE NAME: `1 TEST TEST: U Select MESSAGE TEMPLATE NAME: `1 TEST TEST: U// (No Editing) Select MESSAGE TEMPLATE NAME: --- Greg Woodhouse [EMAIL PROTECTED] wrote: Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2
RE: [Hardhats-members] How to obtain a write access of ^ ?
You've got me, Greg. I was curious about Kevin's issue and just tried a few things. What I wrote is just my observation, I didn't have anything to do with the design, and the things that I work on don't generally require the use of this technique. tjh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Monday, February 14, 2005 10:58 AM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] How to obtain a write access of ^ ? Does this trick offer any advantages over using the Uneditable Data option in Fileman to make the field uneditable? The effect is basically the same: Fileman disallows writes and deletes. --- Holloway, Thomas (EDS) [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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ
Re: [Hardhats-members] How to obtain a write access of ^ ?
I suspect something else must be going on. I tried setting the write protection to ^ (BTW, you can do this because the field sits by itself on a global node in the DD) and, sure enough, DUZ(0)=@ does trump ^, just as Marianne said. If yhou were using DIC, I'd think perhaps you had a pre-selection action. Does the file have a special lookup routine? --- Greg Kreis [EMAIL PROTECTED] wrote: Has this been changed? It used to be that you could set DUZ(0)=^ and it would permit the edit. As mentioned here, it was a want to 'write protect' a field so that only a trigger could enter the data (a trigger asks if you want to write protect a field). Holloway, Thomas (EDS) 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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Monday, February 14, 2005 2:34 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing
Re: [Hardhats-members] How to obtain a write access of ^ ?
As you might guess, that's a trick that is sometimes employed to discourage unauthorized fiddling with sensitive files. Off the top of my head, I'm not sure if Fileman will complain if you set DUZ(0) programmatically to ^ before attempting an update, but I believe this will work. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: Hello all, I want to edit fields .104 (PROVIDER) and .1041 (ATTENDING PHYSICIAN) in file 2 (PATIENT file). I have a fileman code of @ In the data dictionary, these two fields have a code of ^ required. I assume this means that my DUZ(0) must contain a ^. This is normally loaded (I believe) from field 3 FILE MANAGER ACCESS CODE in file 200 (NEW PERSON file). This is stored in piece 4 of node 0. But how would a ^ character be stored, when the ^ character is used as the pieces divider? Perhaps I am coming at this the wrong way. All I want it do is have the attending physician be properly displayed in CPRS for a given physician. Thanks Kevin __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ^ ?
Take a look at the FILE MANAGE ACCESS CODE field in file 200. Maybe you can put a ^ there with D P^DI and then see what happens. On Sunday 13 February 2005 05:14 pm, Kevin Toppenberg wrote: Hello all, I want to edit fields .104 (PROVIDER) and .1041 (ATTENDING PHYSICIAN) in file 2 (PATIENT file). I have a fileman code of @ In the data dictionary, these two fields have a code of ^ required. I assume this means that my DUZ(0) must contain a ^. This is normally loaded (I believe) from field 3 FILE MANAGER ACCESS CODE in file 200 (NEW PERSON file). This is stored in piece 4 of node 0. But how would a ^ character be stored, when the ^ character is used as the pieces divider? Perhaps I am coming at this the wrong way. All I want it do is have the attending physician be properly displayed in CPRS for a given physician. Thanks Kevin __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ^ ?
I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: Actually, the @ is a superaccess that should be sufficient for any situation, no matter what the file DD, read, write, delete access code is. In other words, you should not have any difficulty doing anything in any file. Are you having difficulty or are you just anticipating having difficult, in which case go ahead and try it first. You should not even have to change DUZ(0). Marianne Follingstad Greg Woodhouse wrote: As you might guess, that's a trick that is sometimes employed to discourage unauthorized fiddling with sensitive files. Off the top of my head, I'm not sure if Fileman will complain if you set DUZ(0) programmatically to ^ before attempting an update, but I believe this will work. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: Hello all, I want to edit fields .104 (PROVIDER) and .1041 (ATTENDING PHYSICIAN) in file 2 (PATIENT file). I have a fileman code of @ In the data dictionary, these two fields have a code of ^ required. I assume this means that my DUZ(0) must contain a ^. This is normally loaded (I believe) from field 3 FILE MANAGER ACCESS CODE in file 200 (NEW PERSON file). This is stored in piece 4 of node 0. But how would a ^ character be stored, when the ^ character is used as the pieces divider? Perhaps I am coming at this the wrong way. All I want it do is have the attending physician be properly displayed in CPRS for a given physician. Thanks Kevin __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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=6595alloc_id=14396op=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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ^ ?
If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: Actually, the @ is a superaccess that should be sufficient for any situation, no matter what the file DD, read, write, delete access code is. In other words, you should not have any difficulty doing anything in any file. Are you having difficulty or are you just anticipating having difficult, in which case go ahead and try it first. You should not even have to change DUZ(0). Marianne Follingstad Greg Woodhouse wrote: As you might guess, that's a trick that is sometimes employed to discourage unauthorized fiddling with sensitive files. Off the top of my head, I'm not sure if Fileman will complain if you set DUZ(0) programmatically to ^ before attempting an update, but I believe this will work. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: Hello all, I want to edit fields .104 (PROVIDER) and .1041 (ATTENDING PHYSICIAN) in file 2 (PATIENT file). I have a fileman code of @ In the data dictionary, these two fields have a code of ^ required. I assume this means that my DUZ(0) must contain a ^. This is normally loaded (I believe) from field 3 FILE MANAGER ACCESS CODE in file 200 (NEW PERSON file). This is stored in piece 4 of node 0. But how would a ^ character be stored, when the ^ character is used as the pieces divider? Perhaps I am coming at this the wrong way. All I want it do is have the attending physician be properly displayed in CPRS for a given physician. Thanks Kevin __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- 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=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] How to obtain a write access of ^ ?
Stephen; Then that sounds like the loading of this field is programatic (data loaded at the time of the action being recorded) and doesn't use Fileman to Fill the field. That would keep most users (except for programmers) from changing the data. Interesting business rule. I see the value of it. - Original Message - From: steven mcphelan [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 7:50 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? If a field is write protected with the ^ then no DUZ(0) will allow you to edit that field using Fileman enter/edit. - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Sunday, February 13, 2005 9:57 PM Subject: Re: [Hardhats-members] How to obtain a write access of ^ ? Maybe it is because you don't have a patient who has been admitted! Note that it says inpatient below. On Sunday 13 February 2005 09:18 pm, Nancy Anthracite wrote: I noted that only active providers are allowed, so do your docs have the PROVIDER key and the only thing I could see that might have to do with that and show activity was the PERSON CLASS, in file 200, which has an expiration date which I believe you can leave blank. Do your docs have a person class of physician or one of those variants? 2,.104PROVIDER .104;1 POINTER TO NEW PERSON FILE (#200) INPUT TRANSFORM: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) D ^DIC K DIC S DIC=DIE,X=+Y K:Y0 X LAST EDITED: DEC 07, 1994 HELP-PROMPT: The provider currently assigned to this inpatient applicant. DESCRIPTION: From the available listing select the provider who is currently treating this patient. SCREEN: S DIC(S)=I $$SCREEN^DGPMDD(Y,DA,DT) EXPLANATION: Allow only active providers. EXECUTABLE HELP: D HELP^DGPMDD(DA,DT) CROSS-REFERENCE: 2^APR 1)= S ^DPT(APR,$E(X,1,30),DA)= 2)= K ^DPT(APR,$E(X,1,30),DA) On Sunday 13 February 2005 08:26 pm, Kevin Toppenberg wrote: I also thought @ was a master access setting. But here is a screen log of what I am seeing. GTMzwr DUZ DUZ=90 DUZ(0)=@ DUZ(1)= DUZ(2)=69 DUZ(AG)=O DUZ(AUTO)=1 DUZ(BUF)=1 DUZ(LANG)=1 GTMd ^XUP Setting up programmer environment Terminal Type set to: C-VT102 Select OPTION NAME: diedit INPUT TO WHAT FILE: NEW PERSON// 2 PATIENT (69454 entries) EDIT WHICH FIELD: ALL// Provider?? EDIT WHICH FIELD: ALL// .104?? EDIT WHICH FIELD: ALL// .1041?? EDIT WHICH FIELD: ALL// Is there something else wrong that I am doing? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: Actually, the @ is a superaccess that should be sufficient for any situation, no matter what the file DD, read, write, delete access code is. In other words, you should not have any difficulty doing anything in any file. Are you having difficulty or are you just anticipating having difficult, in which case go ahead and try it first. You should not even have to change DUZ(0). Marianne Follingstad Greg Woodhouse wrote: As you might guess, that's a trick that is sometimes employed to discourage unauthorized fiddling with sensitive files. Off the top of my head, I'm not sure if Fileman will complain if you set DUZ(0) programmatically to ^ before attempting an update, but I believe this will work. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: Hello all, I want to edit fields .104 (PROVIDER) and .1041 (ATTENDING PHYSICIAN) in file 2 (PATIENT file). I have a fileman code of @ In the data dictionary, these two fields have a code of ^ required. I assume this means that my DUZ(0) must contain a ^. This is normally loaded (I believe) from field 3 FILE MANAGER ACCESS CODE in file 200 (NEW PERSON file). This is stored in piece 4 of node 0. But how would a ^ character be stored, when the ^ character is used as the pieces divider? Perhaps I am coming at this the wrong way. All I want it do is have the attending physician be properly displayed in CPRS for a given physician. Thanks Kevin
