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: > 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 > > > &
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: 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
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: 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 t
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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=click __
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: 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
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=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
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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=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 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
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: 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: > > >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
Re: [Hardhats-members] How to obtain a write access of "^" ?
Nancy,
I think I opened a can of worms on this one. I was
assuming that an out patient could also have an
attending physician. But apparently not.
I think this issue is going to be more hassle than I
won't to mess with right now.
Thanks for everyone's help!
Kevin
--- Nancy Anthracite <[EMAIL PROTECTED]> wrote:
> 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:Y<0 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.
> > >
> > >
> > > GTM>zwr DUZ
> > > DUZ=90
> > > DUZ(0)="@"
> > > DUZ(1)=""
> > > DUZ(2)=69
> > > DUZ("AG")="O"
> > > DUZ("AUTO")=1
> > > DUZ("BUF")=1
> > > DUZ("LANG")=1
> > >
> > > GTM>d ^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 Yah
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: > >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: > >>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
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:
> 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:
> > 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:Y<0 X
> > > > LAST EDITED: DEC 07, 1994
> > > > HELP-PROMPT: The provider currently assigned
> to
> t
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: > > 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: > > > 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 P
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:
> 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:
> > 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:Y<0 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)
> > > >
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 still didn'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 "^" ?
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:
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:
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:Y<0 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 "^" ?
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:
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:
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:Y<0 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
Re: [Hardhats-members] How to obtain a write access of "^" ?
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:
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:
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:Y<0 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.
GTM>zwr DUZ
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:
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:
> 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:Y<0 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.
> > > >
> > > >
> > > > GTM>zwr DUZ
> > > > DUZ=90
> > > > DUZ(0)="@"
> > > > DUZ(1)=""
> > > > DUZ(2)=69
> > > > DUZ("AG")="O"
> > > > DUZ("AUTO")=1
> > > > DUZ("BUF")=1
> > > > DUZ("LANG")=1
>
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:
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:
> 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:Y<0 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.
> > > >
> > > >
> > > > GTM>zwr DUZ
> > > > DUZ=90
> > > > DUZ(0)="@"
> > > > DUZ(1)=""
> > > > DUZ(2)=69
> > > > DUZ("AG")="O"
> > > > DUZ("AUTO")=1
> > > > DUZ("BUF")=1
> > > > DUZ("LANG")=1
> > > >
> > > > GTM>d ^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
> > > > >
>
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:
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:Y<0 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.
> > >
> > >
> > > GTM>zwr DUZ
> > > DUZ=90
> > > DUZ(0)="@"
> > > DUZ(1)=""
> > > DUZ(2)=69
> > > DUZ("AG")="O"
> > > DUZ("AUTO")=1
> > > DUZ("BUF")=1
> > > DUZ("LANG")=1
> > >
> > > GTM>d ^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
&
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:Y<0 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.
> >
> >
> > GTM>zwr DUZ
> > DUZ=90
> > DUZ(0)="@"
> > DUZ(1)=""
> > DUZ(2)=69
> > DUZ("AG")="O"
> > DUZ("AUTO")=1
> > DUZ("BUF")=1
> > DUZ("LANG")=1
> >
> > GTM>d ^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=6595&alloc_id=14396&op=click
> >
> > > > > ___
> > > > > Hardhats-members mailing list
> > > > > Hardhats-members@lists.sourceforge.net
> >
> > https://lists.sourceforge.net/lists/
Re: [Hardhats-members] How to obtain a write access of "^" ?
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:Y<0 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.
>
>
> GTM>zwr DUZ
> DUZ=90
> DUZ(0)="@"
> DUZ(1)=""
> DUZ(2)=69
> DUZ("AG")="O"
> DUZ("AUTO")=1
> DUZ("BUF")=1
> DUZ("LANG")=1
>
> GTM>d ^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=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 r
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.
GTM>zwr DUZ
DUZ=90
DUZ(0)="@"
DUZ(1)=""
DUZ(2)=69
DUZ("AG")="O"
DUZ("AUTO")=1
DUZ("BUF")=1
DUZ("LANG")=1
GTM>d ^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=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
>
__
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=6595&alloc_id=14396&op=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 "^" ?
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=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
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=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
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=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
