Re: [Hardhats-members] More DINUM problems
I am still confused as to why Kevin is going through all these gyrations for creating scripts to set up a user especially since his scripts appear to be hardcoding the values to assign. The Kernel has provided APIs to do this very thing for many years. Staff at the VA set up a new user with one option which is the option to clone a user. What they do is setup a standardized NEW PERSON file entry (I will call a dummy user) with all the Kernel components they need for that job's function. Then when a real user comes on board, they choose the clone a user option. They select the appropriate dummy user. Voila, the real user now has all the options, security keys, mail groups, etc. that they need. This is not 100% but it goes a long ways to making an onerous task easier. For example, I believe the Kernel clone a user option will not copy over some package specific configurations like CPRS parameters. But if Kevin is going through these gyration to learn, then that is good. If the purpose is to have a tool to make a task simpler, then why not use the already existing VistA options that accomplish that task or write a script to those options? - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 5:37 PM Subject: RE: [Hardhats-members] More DINUM problems Thanks Skip, I also have gotten this working. For complex reasons, my install scripter was adding the record, and then trying to overwrite it a second time. It working now. I think you cheated a bit below, though. You sent the error messages to ZZERR, and then showed that there were no errors in DIERR. LOL. I see below that it did work though. Thanks again Kevin --- 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
I suspect he is creating a generic populatioin tool so he can move data into the system, automate tasks driven by a GUI, etc. But, hey, Kevin... tell us again about your approach. steven mcphelan wrote: I am still confused as to why Kevin is going through all these gyrations for creating scripts to set up a user especially since his scripts appear to be hardcoding the values to assign. The Kernel has provided APIs to do this very thing for many years. Staff at the VA set up a new user with one option which is the option to clone a user. What they do is setup a standardized NEW PERSON file entry (I will call a dummy user) with all the Kernel components they need for that job's function. Then when a real user comes on board, they choose the clone a user option. They select the appropriate dummy user. Voila, the real user now has all the options, security keys, mail groups, etc. that they need. This is not 100% but it goes a long ways to making an onerous task easier. For example, I believe the Kernel clone a user option will not copy over some package specific configurations like CPRS parameters. But if Kevin is going through these gyration to learn, then that is good. If the purpose is to have a tool to make a task simpler, then why not use the already existing VistA options that accomplish that task or write a script to those options? - Original Message - From: "Kevin Toppenberg" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 5:37 PM Subject: RE: [Hardhats-members] More DINUM problems Thanks Skip, I also have gotten this working. For complex reasons, my install scripter was adding the record, and then trying to overwrite it a second time. It working now. I think you cheated a bit below, though. You sent the error messages to ZZERR, and then showed that there were no errors in DIERR. LOL. I see below that it did work though. Thanks again Kevin --- 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
: Tuesday, November 23, 2004 5:37 PM Subject: RE: [Hardhats-members] More DINUM problems Thanks Skip, I also have gotten this working. For complex reasons, my install scripter was adding the record, and then trying to overwrite it a second time. It working now. I think you cheated a bit below, though. You sent the error messages to ZZERR, and then showed that there were no errors in DIERR. LOL. I see below that it did work though. Thanks again Kevin --- 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
the appropriate dummy user. Voila, the real user now has all the options, security keys, mail groups, etc. that they need. This is not 100% but it goes a long ways to making an onerous task easier. For example, I believe the Kernel clone a user option will not copy over some package specific configurations like CPRS parameters. But if Kevin is going through these gyration to learn, then that is good. If the purpose is to have a tool to make a task simpler, then why not use the already existing VistA options that accomplish that task or write a script to those options? - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 5:37 PM Subject: RE: [Hardhats-members] More DINUM problems Thanks Skip, I also have gotten this working. For complex reasons, my install scripter was adding the record, and then trying to overwrite it a second time. It working now. I think you cheated a bit below, though. You sent the error messages to ZZERR, and then showed that there were no errors in DIERR. LOL. I see below that it did work though. Thanks again Kevin --- 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
Look at the option:
'Grant Access by Profile' Option name: XUSERBLK
This option allows the adding or editing of one or more users according
to an existing user profile. The complete profile of the actual or
dummy user, menus and keys included, is copied to the other users. For
new users, security forms will be generated. (Use the Help Processor
menu to edit the XUSER COMPUTER ACCOUNT help frame containing the text
of the forms.) To route forms, be sure that the user profile has a
service/section and that the corresponding entry in the Service/Section
file has a Coordinator.
This option is locked with the XUMGR key and is restricted for use by
systems management staff.
If you are creating a new real user, you will get a new set of prompts. You
may get additional prompts or screen writes if you want the change the role
of an existing user to a new role, for example, changing a resident to an
attending physician.
- Original Message -
From: Kevin Toppenberg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 24, 2004 9:57 AM
Subject: Re: [Hardhats-members] More DINUM problems
Steven,
Thanks for your feedback.
My intent in creating an installation program was to
create a one-shot install wizard. I am not aware of
any code that will do this currently. I have the
following layers (from lowest to highest):
1. VistA code
2. Script interpreter
3. XML Script
4. (Potential wizard to query for unique user data)
The hard-coding part of my script is to put user
data into a format like this:
Values id=TMG
Field
id=ParentDomainPARENT.TMGDOMAIN.COM/Field
Field id=DomainTMG.TMGDOMAIN.COM/Field
Field id=SiteNameTMGSITE/Field
Field id=SiteNumber777/Field
Field id=DivisionTMGDivison/Field
Field id=InstitutionTMG-Greeneville/Field
Field id=MedCenterDivisionTMGCenterDiv/Field
Field id=StateTENNESSEE/Field
Field id=ShortNameThe Medical Group
(TMG)/Field
Field id=CityGreeneville/Field
Field id=Zip37745/Field
Field id=VaTypeOC-IND/Field
Field id=FacilityTypeOC/Field
Field id=AgencyCodeOTHER/Field
Field id=VolumeSetVOL/Field
Field id=UCIUCI/Field
Field id=ListenPort9210/Field
/Values
The above data values are then pulled into records for
given files. In the below example, the INSTITUTION
file is set up. Notice that if a data value, such as
UCI is needed multiple places, that the user will only
have to edit it at ONE place (the data set shown
above)
Record id=Institution File=INSTITUTION
Field
id=NAME{{Values[TMG].Field[Institution]}}/Field
Field
id=STATE{{Values[TMG].Field[State]}}/Field
Field id=SHORT
NAME{{Values[TMG].Field[ShortName]}}/Field
Field id=CITY{{Values[TMG].Field[City]}}/Field
Field id=ZIP{{Values[TMG].Field[Zip]}}/Field
Field id=VA TYPE
CODE{{Values[TMG].Field[VaType]}}/Field
Field id=FACILITY
TYPE{{Values[TMG].Field[FacilityType]}}/Field
Field
id=DOMAIN{{Values[TMG].Field[Domain]}}/Field
Field id=AGENCY
CODE{{Values[TMG].Field[AgencyCode]}}/Field
Field id=STATION
NUMBER{{Values[TMG].Field[SiteNumber]}}/Field
/Record
So while this data is hard-coded, it is easily
modifiable--either by a user with a text editor, or by
a future wizard that asks a question and stores answer
in this XML format.
There is a very good chance that I am re-inventing the
wheel, but the fact that I can't find a wheel that has
already been created shows a weakness in the current
VistA setup. There has been much discussion of
potential bridging documentation. The need for this
can't be overestimated. I am trying to make a
bridging script that allows for installation without
having to do extensive work before one can even get
started. Take a look at the install instructions that
Nancy, David Whitten and others have set up. They are
not exactly easy for a beginner to do. When working
with a system that is already up and going, it is easy
to forget how one got the thing working in the first
place. Perhaps this doesn't apply to everyone, but
I've heard long-time VistA administrators say that
everyone had forgotten how to get a system up and
running from the ground up.
The VistA API's also leave much to be desired, in my
opinion. This is both in terms of documentation (and
the difficulty in finding the correct documentation),
and in code functionality. The fact that it takes so
much discussion to upload a simple data set into a
database is unfortunate.
So while I continue to learn more about the system,
and I'm sure I will discover easier ways to do what
I'm trying to do, I'll keep slogging along.
I greatly appreciate the help everyone has given me.
And I appreciate feedback like this one. I just hope
I don't drive everyone crazy with my 10,000 questions.
Thanks again, and Happy Thanksgiving everyone!
Kevin
--- steven mcphelan [EMAIL PROTECTED] wrote:
I am still confused as to why Kevin
Re: [Hardhats-members] More DINUM problems
Nancy, Thanks for your post. I don't think that the FILE^DIE and UPDATER^DIE will balk as partial matches. In other words, if I tell it XUPROG, it does not get confused with XUPROGMODE. I know that interactive fileman will ask about this, but I have already used it for looking up menu options, and haven't had any similar problems. Thanks Kevin --- Nancy E. Anthracite [EMAIL PROTECTED] wrote: Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens that user #1 in file 200 already has this key, in entry #1. I can enter this value directly via Fileman. What am I doing wrong? Thanks Kevin __ 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
There's actually a flag to control this behavior. If you look at the documentation for FIND^DIC, you'll find the following description for the O (for Only) flag: Only find exact matches if possible. The Finder first searches for exact matches on the requested Index(es); if any are found, it returns all exact matches to the lookup value. Only if it finds none in the file does it search for partial matches, returning every partial match. For example, if the lookup value is EINSTEIN and the file contains entries EINSTEIN and EINSTEIN,ALBERT, only the first record is returned. If the first record did not exist, the Finder would return EINSTEIN,ALBERT as a match. If FLAGS does not contain an O, the Finder returns all matches, partial and exact. If the lookup is done on a compound index, exact matches must be made for every data value subscript in the index in order to consider the entry to be an exact match. (This flag is revised.) --- Greg Kreis [EMAIL PROTECTED] wrote: I just did some testing and Kevin is right. I was surprised to see that if a field is a pointer and you 'file' a value for field that makes an exact name match in the pointed to file, it doesn't bring up the partials that would normally match it. It goes with the exact match. But, further testing revealed that if the exact name match is on more than one record in the pointed to file, it won't pick one, as I would have expected. Kevin Toppenberg wrote: Nancy, Thanks for your post. I don't think that the FILE^DIE and UPDATER^DIE will balk as partial matches. In other words, if I tell it XUPROG, it does not get confused with XUPROGMODE. I know that interactive fileman will ask about this, but I have already used it for looking up menu options, and haven't had any similar problems. Thanks Kevin --- Nancy E. Anthracite [EMAIL PROTECTED] wrote: Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens that user #1 in file 200 already has this key, in entry #1. I can enter this value directly via Fileman. What am I doing wrong? Thanks Kevin __ 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! 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
RE: [Hardhats-members] More DINUM problems
The following is an example of adding the XUPROG key for a specific user, that is the IEN/DUZ(0) is known: OUTPUT FROM WHAT FILE: NEW PERSON// Select NEW PERSON NAME:TESTER,CHESTER D CCT DEC 01, 2003 ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields DISPLAY AUDIT TRAIL? No// NO NAME: TESTER,CHESTER D INITIAL: CCT SNIP SIGNATURE BLOCK PRINTED NAME: CHESTER D TESTER VCD,FMAS FDA(200.051,+2,1142,,.01)=XUPROG VCD,FMAD UPDATE^DIE(E,FDA,ZZERR) VCD,FMAZW DIERR VCD,FMAD P^DI VA FileMan 22.0 Select OPTION: INQUIRE TO FILE ENTRIES OUTPUT FROM WHAT FILE: NEW PERSON// Select NEW PERSON NAME:TESTER,CHESTER D CCT DEC 01, 2003 ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields DISPLAY AUDIT TRAIL? No// NO NAME: TESTER,CHESTER D INITIAL: CCT SNIP SIGNATURE BLOCK PRINTED NAME: CHESTER D TESTER KEY: XUPROG GIVEN BY: ORMSBY,SKIP DATE GIVEN: NOV 23, 2004 Please notice that I use the UPDATE API because I knew I was adding the entry. Also I didn't pass the K flag because in my file the Keys multiple/.01 field does not have a xref set as a Key. Of course, Kevin, you might have added that kind of New Style Cross Reference, in which case then you need to pass the K flag. I hope this helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Tuesday, November 23, 2004 12:55 PM To: [EMAIL PROTECTED] Subject: Re: [Hardhats-members] More DINUM problems There's actually a flag to control this behavior. If you look at the documentation for FIND^DIC, you'll find the following description for the O (for Only) flag: Only find exact matches if possible. The Finder first searches for exact matches on the requested Index(es); if any are found, it returns all exact matches to the lookup value. Only if it finds none in the file does it search for partial matches, returning every partial match. For example, if the lookup value is EINSTEIN and the file contains entries EINSTEIN and EINSTEIN,ALBERT, only the first record is returned. If the first record did not exist, the Finder would return EINSTEIN,ALBERT as a match. If FLAGS does not contain an O, the Finder returns all matches, partial and exact. If the lookup is done on a compound index, exact matches must be made for every data value subscript in the index in order to consider the entry to be an exact match. (This flag is revised.) --- Greg Kreis [EMAIL PROTECTED] wrote: I just did some testing and Kevin is right. I was surprised to see that if a field is a pointer and you 'file' a value for field that makes an exact name match in the pointed to file, it doesn't bring up the partials that would normally match it. It goes with the exact match. But, further testing revealed that if the exact name match is on more than one record in the pointed to file, it won't pick one, as I would have expected. Kevin Toppenberg wrote: Nancy, Thanks for your post. I don't think that the FILE^DIE and UPDATER^DIE will balk as partial matches. In other words, if I tell it XUPROG, it does not get confused with XUPROGMODE. I know that interactive fileman will ask about this, but I have already used it for looking up menu options, and haven't had any similar problems. Thanks Kevin --- Nancy E. Anthracite [EMAIL PROTECTED] wrote: Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens
RE: [Hardhats-members] More DINUM problems
Thanks Skip, I also have gotten this working. For complex reasons, my install scripter was adding the record, and then trying to overwrite it a second time. It working now. I think you cheated a bit below, though. You sent the error messages to ZZERR, and then showed that there were no errors in DIERR. LOL. I see below that it did work though. Thanks again Kevin --- Ormsby, Skip [EMAIL PROTECTED] wrote: The following is an example of adding the XUPROG key for a specific user, that is the IEN/DUZ(0) is known: OUTPUT FROM WHAT FILE: NEW PERSON// Select NEW PERSON NAME:TESTER,CHESTER D CCT DEC 01, 2003 ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields DISPLAY AUDIT TRAIL? No// NO NAME: TESTER,CHESTER D INITIAL: CCT SNIP SIGNATURE BLOCK PRINTED NAME: CHESTER D TESTER VCD,FMAS FDA(200.051,+2,1142,,.01)=XUPROG VCD,FMAD UPDATE^DIE(E,FDA,ZZERR) VCD,FMAZW DIERR VCD,FMAD P^DI VA FileMan 22.0 Select OPTION: INQUIRE TO FILE ENTRIES OUTPUT FROM WHAT FILE: NEW PERSON// Select NEW PERSON NAME:TESTER,CHESTER D CCT DEC 01, 2003 ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields DISPLAY AUDIT TRAIL? No// NO NAME: TESTER,CHESTER D INITIAL: CCT SNIP SIGNATURE BLOCK PRINTED NAME: CHESTER D TESTER KEY: XUPROG GIVEN BY: ORMSBY,SKIP DATE GIVEN: NOV 23, 2004 Please notice that I use the UPDATE API because I knew I was adding the entry. Also I didn't pass the K flag because in my file the Keys multiple/.01 field does not have a xref set as a Key. Of course, Kevin, you might have added that kind of New Style Cross Reference, in which case then you need to pass the K flag. I hope this helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Tuesday, November 23, 2004 12:55 PM To: [EMAIL PROTECTED] Subject: Re: [Hardhats-members] More DINUM problems There's actually a flag to control this behavior. If you look at the documentation for FIND^DIC, you'll find the following description for the O (for Only) flag: Only find exact matches if possible. The Finder first searches for exact matches on the requested Index(es); if any are found, it returns all exact matches to the lookup value. Only if it finds none in the file does it search for partial matches, returning every partial match. For example, if the lookup value is EINSTEIN and the file contains entries EINSTEIN and EINSTEIN,ALBERT, only the first record is returned. If the first record did not exist, the Finder would return EINSTEIN,ALBERT as a match. If FLAGS does not contain an O, the Finder returns all matches, partial and exact. If the lookup is done on a compound index, exact matches must be made for every data value subscript in the index in order to consider the entry to be an exact match. (This flag is revised.) --- Greg Kreis [EMAIL PROTECTED] wrote: I just did some testing and Kevin is right. I was surprised to see that if a field is a pointer and you 'file' a value for field that makes an exact name match in the pointed to file, it doesn't bring up the partials that would normally match it. It goes with the exact match. But, further testing revealed that if the exact name match is on more than one record in the pointed to file, it won't pick one, as I would have expected. Kevin Toppenberg wrote: Nancy, Thanks for your post. I don't think that the FILE^DIE and UPDATER^DIE will balk as partial matches. In other words, if I tell it XUPROG, it does not get confused with XUPROGMODE. I know that interactive fileman will ask about this, but I have already used it for looking up menu options, and haven't had any similar problems. Thanks Kevin --- Nancy E. Anthracite [EMAIL PROTECTED] wrote: Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries
Re: [Hardhats-members] More DINUM problems
Wait... by calling UPDATE with the internal value for the .01 field,
you won't be performing the .01 field's input transform that created
DINUM. So, it looks like you have to use the inbound IEN array to
specify a sub-file record number for the new record that is the same
value as the .01 field. Yuck...
It looks like creating a screened lookup of a .01 pointer shouldn't
have leaked the ^DIC call into the input transform. The poor Input
Transform is a bit overloaded... hindsight is 20/20 as they say.
This is why I avoid DINUM in my file designs. It is too restrictive.
Greg Kreis wrote:
Kevin Toppenberg wrote:
Greg,
Thanks for your reply.
So in my install script, I have a long list of keys
that I want to ensure that a given user has. Am I
getting this DINUM error because I am trying to add a
key that already exists for the user, or because the
FILE^DIE function can't handle DINUM entries?
FILE^DIE can't add entries - only update them. That means you must be
editing and DINUMed files can't have their .01 field edited.
Since all you can do is add the entry if not there, use the UPDATE^DIE
call to add sub-file records. I guess one way to determine what needs
to be added is to scan the sub-file's entries, seeing if the sub-file
IENs are any of the IEN values of keys you want to add. If not there,
put them in the FDA array and when done, call UPDATE^DIE.
How else should I go about this, other than manually
entering them via option DIEDIT?
Regarding the "E" flag, it IS set up. See the "KE"
below? I'm pretty sure that flags parameter is the
first paremeter of FILE^DIE.
Doh... my bad. I was looking at the wrong parameter. (One of the
pains of the DBS calls is trying to get all the parameters lined up...
;-). Actually, though, you don't want to enter the external value for
a pointer, because you might be entering a value that is not unique.
In this case, XUPROG will find XUPROG and XUPROGMODE. FM won't choose
for you. For an automated operation, derive the pointer values for
storing so they are unique. (VistA's database was created long before
FM had support for keys that could provide a unique match with field
values to make for accurate automated updates.)
Thanks
Kevin
--- Greg Kreis [EMAIL PROTECTED] wrote:
Kevin Toppenberg wrote:
I am hitting a DINUM error message again that I
don't
understand. I know that a DINUMed error is when a
user is trying to add multiple records when there
is
supposed to be only one entry.
DINUM is simply a way to control the record number a
new record
receives. That is all. So, how does one come up
with a number that
should be used? You read the INPUT TRANSFORM of the
.01 field and see
what they are doing to get the value of DINUM. In
the 200.051 sub-file,
the .01 field input transform is doing a screened
lookup to find only
records in the SECURITY KEY file that the current
user is allowed to
give out. Once they select one, it sets the value
of DINUM to the value
of the record number (the IEN) of the selected
SECURITY KEY. That means
you can't give the key out twice, because that would
mean overwriting
the same record. You can't edit a field that is
using DINUM. That means
once that .01 field has a value, it is that way for
good. The only way
to edit it with FM is to delete the record and
recreate it.
Why can't you edit the .01? Because that likely
means the derived DINUM
value would change, meaning the record # should
change and record
numbers can't be changed. FM won't let you do it.
But I am getting this when I try to add keys to a
user. There are supposed to be multiple entries
here,
so I don't know where the error is coming from.
Here is a screen log:
GTMzwr FDA
FDA(200.051,"1,1,",.01)="XUPROG"
Because you didn't set the "E" flag, the data in the
FDA has to be in
internal format and the .01 field is a pointer. You
need to find the
pointer value (the IEN of the XUPROG security key,
in this instance) and
store it. But again, only on a NEW record (which
would mean using an
extended IEN). You can't edit an existing one's .01
because it is DINUM.
GTMd FILE^DIE("KE","FDA","ErrMsg")
GTMzwr ErrMsg
ErrMsg("DIERR")="1^1"
ErrMsg("DIERR",1)=520
ErrMsg("DIERR",1,"PARAM",0)=3
ErrMsg("DIERR",1,"PARAM",1)="DINUMed"
ErrMsg("DIERR",1,"PARAM","FIELD")=.01
ErrMsg("DIERR",1,"PARAM","FILE")=200.051
ErrMsg("DIERR",1,"TEXT",1)="A DINUMed field cannot
be
processed by this utility.
"
ErrMsg("DIERR","E",520,1)=""
GTM
This is occuring in my script environment. I am
trying to add the key XUPROG. It just so happens
that
user #1 in file 200 already has this key, in entry
Re: [Hardhats-members] More DINUM problems
Kevin Toppenberg wrote:
Greg,
Thanks for your reply.
So in my install script, I have a long list of keys
that I want to ensure that a given user has. Am I
getting this DINUM error because I am trying to add a
key that already exists for the user, or because the
FILE^DIE function can't handle DINUM entries?
FILE^DIE can't add entries - only update them. That means you must be
editing and DINUMed files can't have their .01 field edited.
Since all you can do is add the entry if not there, use the UPDATE^DIE
call to add sub-file records. I guess one way to determine what needs
to be added is to scan the sub-file's entries, seeing if the sub-file
IENs are any of the IEN values of keys you want to add. If not there,
put them in the FDA array and when done, call UPDATE^DIE.
How else should I go about this, other than manually
entering them via option DIEDIT?
Regarding the "E" flag, it IS set up. See the "KE"
below? I'm pretty sure that flags parameter is the
first paremeter of FILE^DIE.
Doh... my bad. I was looking at the wrong parameter. (One of the
pains of the DBS calls is trying to get all the parameters lined up...
;-). Actually, though, you don't want to enter the external value for
a pointer, because you might be entering a value that is not unique.
In this case, XUPROG will find XUPROG and XUPROGMODE. FM won't choose
for you. For an automated operation, derive the pointer values for
storing so they are unique. (VistA's database was created long before
FM had support for keys that could provide a unique match with field
values to make for accurate automated updates.)
Thanks
Kevin
--- Greg Kreis [EMAIL PROTECTED] wrote:
Kevin Toppenberg wrote:
I am hitting a DINUM error message again that I
don't
understand. I know that a DINUMed error is when a
user is trying to add multiple records when there
is
supposed to be only one entry.
DINUM is simply a way to control the record number a
new record
receives. That is all. So, how does one come up
with a number that
should be used? You read the INPUT TRANSFORM of the
.01 field and see
what they are doing to get the value of DINUM. In
the 200.051 sub-file,
the .01 field input transform is doing a screened
lookup to find only
records in the SECURITY KEY file that the current
user is allowed to
give out. Once they select one, it sets the value
of DINUM to the value
of the record number (the IEN) of the selected
SECURITY KEY. That means
you can't give the key out twice, because that would
mean overwriting
the same record. You can't edit a field that is
using DINUM. That means
once that .01 field has a value, it is that way for
good. The only way
to edit it with FM is to delete the record and
recreate it.
Why can't you edit the .01? Because that likely
means the derived DINUM
value would change, meaning the record # should
change and record
numbers can't be changed. FM won't let you do it.
But I am getting this when I try to add keys to a
user. There are supposed to be multiple entries
here,
so I don't know where the error is coming from.
Here is a screen log:
GTMzwr FDA
FDA(200.051,"1,1,",.01)="XUPROG"
Because you didn't set the "E" flag, the data in the
FDA has to be in
internal format and the .01 field is a pointer. You
need to find the
pointer value (the IEN of the XUPROG security key,
in this instance) and
store it. But again, only on a NEW record (which
would mean using an
extended IEN). You can't edit an existing one's .01
because it is DINUM.
GTMd FILE^DIE("KE","FDA","ErrMsg")
GTMzwr ErrMsg
ErrMsg("DIERR")="1^1"
ErrMsg("DIERR",1)=520
ErrMsg("DIERR",1,"PARAM",0)=3
ErrMsg("DIERR",1,"PARAM",1)="DINUMed"
ErrMsg("DIERR",1,"PARAM","FIELD")=.01
ErrMsg("DIERR",1,"PARAM","FILE")=200.051
ErrMsg("DIERR",1,"TEXT",1)="A DINUMed field cannot
be
processed by this utility.
"
ErrMsg("DIERR","E",520,1)=""
GTM
This is occuring in my script environment. I am
trying to add the key XUPROG. It just so happens
that
user #1 in file 200 already has this key, in entry
#1.
I can enter this value directly via Fileman.
You are creating a new one, right?
What am I doing wrong?
Thanks
Kevin
__
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://productguide.itmanagersjournal.com/
Re: [Hardhats-members] More DINUM problems
Greg, Thanks for your reply. So in my install script, I have a long list of keys that I want to ensure that a given user has. Am I getting this DINUM error because I am trying to add a key that already exists for the user, or because the FILE^DIE function can't handle DINUM entries? How else should I go about this, other than manually entering them via option DIEDIT? Regarding the E flag, it IS set up. See the KE below? I'm pretty sure that flags parameter is the first paremeter of FILE^DIE. Thanks Kevin --- Greg Kreis [EMAIL PROTECTED] wrote: Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. DINUM is simply a way to control the record number a new record receives. That is all. So, how does one come up with a number that should be used? You read the INPUT TRANSFORM of the .01 field and see what they are doing to get the value of DINUM. In the 200.051 sub-file, the .01 field input transform is doing a screened lookup to find only records in the SECURITY KEY file that the current user is allowed to give out. Once they select one, it sets the value of DINUM to the value of the record number (the IEN) of the selected SECURITY KEY. That means you can't give the key out twice, because that would mean overwriting the same record. You can't edit a field that is using DINUM. That means once that .01 field has a value, it is that way for good. The only way to edit it with FM is to delete the record and recreate it. Why can't you edit the .01? Because that likely means the derived DINUM value would change, meaning the record # should change and record numbers can't be changed. FM won't let you do it. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG Because you didn't set the E flag, the data in the FDA has to be in internal format and the .01 field is a pointer. You need to find the pointer value (the IEN of the XUPROG security key, in this instance) and store it. But again, only on a NEW record (which would mean using an extended IEN). You can't edit an existing one's .01 because it is DINUM. GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens that user #1 in file 200 already has this key, in entry #1. I can enter this value directly via Fileman. You are creating a new one, right? What am I doing wrong? Thanks Kevin __ 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens that user #1 in file 200 already has this key, in entry #1. I can enter this value directly via Fileman. What am I doing wrong? Thanks Kevin __ 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] More DINUM problems
Sorry for my earlier post. I saw later that it was all sorted out and I am way off base. -- Forwarded Message -- Subject: Re: [Hardhats-members] More DINUM problems Date: Monday 22 November 2004 10:37 pm From: Nancy E. Anthracite [EMAIL PROTECTED] To: [EMAIL PROTECTED] Could this be the issue? XUPROG and XUPROGMODE both start the same, so if you put that you want to give someone the XUPROG key, it will want to know if it is XUPROG or XUPROGMODE you are talking about. So maybe you are tapping into something designed to prevent confusion about that sort of problem? That problem is only present for a few keys. On Monday 22 November 2004 08:03 pm, Kevin Toppenberg wrote: I am hitting a DINUM error message again that I don't understand. I know that a DINUMed error is when a user is trying to add multiple records when there is supposed to be only one entry. But I am getting this when I try to add keys to a user. There are supposed to be multiple entries here, so I don't know where the error is coming from. Here is a screen log: GTMzwr FDA FDA(200.051,1,1,,.01)=XUPROG GTMd FILE^DIE(KE,FDA,ErrMsg) GTMzwr ErrMsg ErrMsg(DIERR)=1^1 ErrMsg(DIERR,1)=520 ErrMsg(DIERR,1,PARAM,0)=3 ErrMsg(DIERR,1,PARAM,1)=DINUMed ErrMsg(DIERR,1,PARAM,FIELD)=.01 ErrMsg(DIERR,1,PARAM,FILE)=200.051 ErrMsg(DIERR,1,TEXT,1)=A DINUMed field cannot be processed by this utility. ErrMsg(DIERR,E,520,1)= GTM This is occuring in my script environment. I am trying to add the key XUPROG. It just so happens that user #1 in file 200 already has this key, in entry #1. I can enter this value directly via Fileman. What am I doing wrong? Thanks Kevin __ 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Nancy Anthracite --- -- 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://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
