There is a way to do it, at least in classic FileMan (which is where I'm used to working). Have "U" in DIC(0) when you are using the pointer to another file as the input. The "U" says to not do any input transforms. ("U" used to be undocumented but is on Hardhats, just not sure if it's kosher VA at this point.)
So for example: S DIC=22719,DIC(0)="UE",X=1234567 D ^DIC.
If you want to add an entry with 1234567 as the .01, add "L" to DIC(0). The "E" allows the user to see and select among multiple entries or respond to add a new entry.
I did an article in the June 1990 Mug Quarterly that has examples, including how to have multiple entries with that pointer.
It's been a while since I worked on this, but I'm pretty sure that is correct. Hope that helps.
----- Original Message ----- From: Kevin Toppenberg To: hardhats@googlegroups.com Sent: Tuesday, August 28, 2012 6:08 PM
Subject: [Hardhats] Re: Fileman navigation question
No way to do this?
Kevin
On Monday, August 27, 2012 10:11:35 PM UTC-4, Kevin Toppenberg wrote:
I have a custom Fileman file (22719), and the .01 field is a pointer to the TIU DOCUMENT file (8925).
How can I select the record in file 22719 that has a value in the .01 field of `1234567?
When I try to enter `1234567, Fileman thinks I am referring to the record number in 22709, not in 8925.
Thank you for your reply. I was not aware of the "U" option. I'll have to check that out.
But looking back at my original post, I realize I wasn't clear. What I was wondering, was can this be done from the command line, roll-and-scroll interface. Not with a programming call.
I'm wondering if one could set up a custom looking routine for the file, such that the user's input of "`1234567" is interpreted to mean record number of the pointed-to .01 field rather than the record number of the file.
Again, thanks for your answer.
Kevin
On Tuesday, August 28, 2012 7:23:02 PM UTC-4, Marianne Susaanti Follingstad wrote:
> There is a way to do it, at least in classic FileMan (which is where I'm > used to working). Have "U" in DIC(0) when you are using the pointer to > another file as the input. The "U" says to not do any input transforms. > ("U" used to be undocumented but is on Hardhats, just not sure if it's > kosher VA at this point.)
> So for example: > S DIC=22719,DIC(0)="UE",X=1234567 D ^DIC. > If you want to add an entry with 1234567 as the .01, add "L" to > DIC(0). The "E" allows the user to see and select among multiple entries > or respond to add a new entry.
> I did an article in the June 1990 Mug Quarterly that has examples, > including how to have multiple entries with that pointer.
> It's been a while since I worked on this, but I'm pretty sure that is > correct. Hope that helps.
Select <V15 West> VA FileMan Option: 2 Print File Entries
OUTPUT FROM WHAT FILE: 22719//
SORT BY: NAME// .01: ç the colon takes you into the pointed to file
TIU DOCUMENT: NUMBER="1234567"
WITHIN NUMBER="1234567", SORT BY:
John H. Walkup <IRM>
"The more people it takes to hold the light bulb, the fewer are available to turn the chair"
From: hardhats@googlegroups.com [mailto:hardhats@googlegroups.com] On Behalf Of Kevin Toppenberg
Sent: Tuesday, August 28, 2012 5:08 PM
To: hardhats@googlegroups.com
Subject: [Hardhats] Re: Fileman navigation question
No way to do this?
Kevin
On Monday, August 27, 2012 10:11:35 PM UTC-4, Kevin Toppenberg wrote:
I have a custom Fileman file (22719), and the .01 field is a pointer to the TIU DOCUMENT file (8925).
How can I select the record in file 22719 that has a value in the .01 field of `1234567?
When I try to enter `1234567, Fileman thinks I am referring to the record number in 22709, not in 8925.
Thanks for the feedback. That will sort by the pointed-to file.
I was thinking more of selecting a record, e.g. for an Inquire.
But I have decided to avoid the whole problem by setting up the file in a DINUM fashion, to the pointed-to record number and the record number are the same.
Thanks everyone,
Kevin
On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA) wrote:
I don't know how many times I have heard experienced programmers warn other programmers not to DINUM anything unless absolutely necessary as it almost always comes back to bite you. If someone can suggest and alternate solution, please consider using it or at least waiting until the experienced programmers get a chance to weigh in on why NOT to DINUM.
On Wednesday, August 29, 2012, Kevin Toppenberg wrote:
> John
> Thanks for the feedback. That will sort by the pointed-to file.
> I was thinking more of selecting a record, e.g. for an Inquire.
> But I have decided to avoid the whole problem by setting up the file in a
> DINUM fashion, to the pointed-to record number and the record number are
> the same.
> Thanks everyone,
> Kevin
> On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA)
Your thought of using DINUM is the only way to do what you intended, so go for it. What I was suggesting was useful to avoid confusion in lookups that had multiple entries in a pointing file, particularly if the pointed to file had ambiguities (like a patient file). It involved spliting the lookup into two steps, the first doing the lookup in the pointed to file, the second (the part I mentioned) using that pointer to lookup in the target file. The article I mentioned had examples to show the differences.
----- Original Message ----- From: Kevin Toppenberg To: hardhats@googlegroups.com Sent: Wednesday, August 29, 2012 6:02 AM
Subject: Re: [Hardhats] Re: Fileman navigation question
Marianne,
Thank you for your reply. I was not aware of the "U" option. I'll have to check that out.
But looking back at my original post, I realize I wasn't clear. What I was wondering, was can this be done from the command line, roll-and-scroll interface. Not with a programming call.
I'm wondering if one could set up a custom looking routine for the file, such that the user's input of "`1234567" is interpreted to mean record number of the pointed-to .01 field rather than the record number of the file.
Again, thanks for your answer.
Kevin
On Tuesday, August 28, 2012 7:23:02 PM UTC-4, Marianne Susaanti Follingstad wrote:
There is a way to do it, at least in classic FileMan (which is where I'm used to working). Have "U" in DIC(0) when you are using the pointer to another file as the input. The "U" says to not do any input transforms. ("U" used to be undocumented but is on Hardhats, just not sure if it's kosher VA at this point.)
So for example: S DIC=22719,DIC(0)="UE",X=1234567 D ^DIC.
If you want to add an entry with 1234567 as the .01, add "L" to DIC(0). The "E" allows the user to see and select among multiple entries or respond to add a new entry.
I did an article in the June 1990 Mug Quarterly that has examples, including how to have multiple entries with that pointer.
It's been a while since I worked on this, but I'm pretty sure that is correct. Hope that helps.
Best wishes,
Marianne
----- Original Message ----- From: To: hard...@googlegroups.com Sent: Tuesday, August 28, 2012 6:08 PM
Subject: [Hardhats] Re: Fileman navigation question
No way to do this?
Kevin
On Monday, August 27, 2012 10:11:35 PM UTC-4, Kevin Toppenberg wrote: I have a custom Fileman file (22719), and the .01 field is a pointer to the TIU DOCUMENT file (8925).
How can I select the record in file 22719 that has a value in the .01 field of `1234567?
When I try to enter `1234567, Fileman thinks I am referring to the record number in 22709, not in 8925.
So don't use DINUM if you need multiple entries pointing to the same entry in another file. Although you can get around that if you extend the DINUM to increment by something (say .0001) if you know there won't be too many entries pointing to that same file entry. But then what Kevin wants won't work and you'd have to do something like I suggested.
Personally I loved using DINUM as it allowed ordering things in ways that optimized the file or even subfile entries.
----- Original Message ----- From: "Nancy Anthracite" <nanthrac...@earthlink.net>
To: <hardhats@googlegroups.com>
Cc: "Kevin Toppenberg" <kdt...@gmail.com>; <john.wal...@va.gov>
Sent: Wednesday, August 29, 2012 9:39 AM
Subject: Re: [Hardhats] Re: Fileman navigation question
I don't know how many times I have heard experienced programmers warn other
programmers not to DINUM anything unless absolutely necessary as it almost
always comes back to bite you. If someone can suggest and alternate solution,
please consider using it or at least waiting until the experienced programmers
get a chance to weigh in on why NOT to DINUM.
-- Nancy Anthracite
On Wednesday, August 29, 2012, Kevin Toppenberg wrote:
> John
> Thanks for the feedback. That will sort by the pointed-to file.
> I was thinking more of selecting a record, e.g. for an Inquire.
> But I have decided to avoid the whole problem by setting up the file in a
> DINUM fashion, to the pointed-to record number and the record number are
> the same.
> Thanks everyone,
> Kevin
> On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA)
First of all, the double-quotes suggestion by Mr Walkup is incorrect, because the FileMan convention is that input within double quotes is taken to mean "this is a new (LAYGO) entry". That's not what Kevin wants.
I actually have an answer to this question, that is supposed to work in my (MSC) FileMan. The answer is to type this: ``1234567 Note the 'double grave'. If you look at your copy of the DIC routine, you should see a line tag 'DBLGRV' if and only if you're using MSC FileMan.
Unfortunately, this fine enhancement seems no longer to be working for me, even when the .01 field is, as is necessary, cross-referenced.
I see that Mr Walkup was suggesting using the "PRINT" Option, and his example was not incorrect. It's just, as Kevin says, there should be a way of getting the pointed-to entry just thru a lookup, from the "Select ...: prompt.
On Wednesday, August 29, 2012 10:45:31 AM UTC-4, George Timson wrote:
> First of all, the double-quotes suggestion by Mr Walkup is incorrect, > because the FileMan convention is that input within double quotes is taken > to mean "this is a new (LAYGO) entry". That's not what Kevin wants.
> I actually have an answer to this question, that is supposed to work in my > (MSC) FileMan. The answer is to type this: > ``1234567 > Note the 'double grave'. If you look at your copy of the DIC routine, you > should see a line tag 'DBLGRV' if and only if you're using MSC FileMan.
> Unfortunately, this fine enhancement seems no longer to be working for me, > even when the .01 field is, as is necessary, cross-referenced.
"The more people it takes to hold the light bulb, the fewer are
available to turn the chair"
From: hardhats@googlegroups.com [mailto:hardhats@googlegroups.com] On
Behalf Of Kevin Toppenberg
Sent: Wednesday, August 29, 2012 10:55 AM
To: hardhats@googlegroups.com
Subject: [Hardhats] Re: Fileman navigation question
Thanks George. I knew you would have thought about this issue already.
Kevin
On Wednesday, August 29, 2012 10:45:31 AM UTC-4, George Timson wrote:
First of all, the double-quotes suggestion by Mr Walkup is incorrect,
because the FileMan convention is that input within double quotes is
taken to mean "this is a new (LAYGO) entry". That's not what Kevin
wants.
I actually have an answer to this question, that is supposed to work in
my (MSC) FileMan. The answer is to type this:
``1234567
Note the 'double grave'. If you look at your copy of the DIC routine,
you should see a line tag 'DBLGRV' if and only if you're using MSC
FileMan.
Unfortunately, this fine enhancement seems no longer to be working for
me, even when the .01 field is, as is necessary, cross-referenced.
Just ran into a good reason DINUM can byte you big time. Was using: UPDATE^DIE("","FDA") to change the pointers from IENx to IENy. Life was good until it hit the DINUMed .01 entry in a file, I ended up adding a new entry. Oh well job security. :-)
On Wednesday, August 29, 2012 9:51:03 AM UTC-4, Marianne Susaanti
> So don't use DINUM if you need multiple entries pointing to the same entry > in another file. Although you can get around that if you extend the DINUM > to increment by something (say .0001) if you know there won't be too many > entries pointing to that same file entry. But then what Kevin wants won't > work and you'd have to do something like I suggested.
> Personally I loved using DINUM as it allowed ordering things in ways that > optimized the file or even subfile entries.
> Best wishes, > Marianne > ----- Original Message ----- > From: "Nancy Anthracite" <nanth...@earthlink.net <javascript:>> > To: <hard...@googlegroups.com <javascript:>> > Cc: "Kevin Toppenberg" <kdt...@gmail.com <javascript:>>; <john....@va.gov<javascript:>>
> Sent: Wednesday, August 29, 2012 9:39 AM > Subject: Re: [Hardhats] Re: Fileman navigation question
> I don't know how many times I have heard experienced programmers warn > other > programmers not to DINUM anything unless absolutely necessary as it almost > always comes back to bite you. If someone can suggest and alternate > solution, > please consider using it or at least waiting until the experienced > programmers > get a chance to weigh in on why NOT to DINUM.
> -- > Nancy Anthracite
> On Wednesday, August 29, 2012, Kevin Toppenberg wrote: > > John
> > Thanks for the feedback. That will sort by the pointed-to file.
> > I was thinking more of selecting a record, e.g. for an Inquire.
> > But I have decided to avoid the whole problem by setting up the file in > a > > DINUM fashion, to the pointed-to record number and the record number are > > the same.
> > Thanks everyone, > > Kevin
> > On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA)
On Sun, Sep 23, 2012 at 7:25 AM, Skip <skip.orm...@gmail.com> wrote:
> Just ran into a good reason DINUM can byte you big time. Was using:
> UPDATE^DIE("","FDA") to change the pointers from IENx to IENy. Life was
> good until it hit the DINUMed .01 entry in a file, I ended up adding a new
> entry. Oh well job security. :-)
> On Wednesday, August 29, 2012 9:51:03 AM UTC-4, Marianne Susaanti
> Follingstad wrote:
>> So don't use DINUM if you need multiple entries pointing to the same
>> entry
>> in another file. Although you can get around that if you extend the
>> DINUM
>> to increment by something (say .0001) if you know there won't be too many
>> entries pointing to that same file entry. But then what Kevin wants
>> won't
>> work and you'd have to do something like I suggested.
>> Personally I loved using DINUM as it allowed ordering things in ways that
>> optimized the file or even subfile entries.
>> Best wishes,
>> Marianne
>> ----- Original Message -----
>> From: "Nancy Anthracite" <nanth...@earthlink.net>
>> To: <hard...@googlegroups.com>
>> Cc: "Kevin Toppenberg" <kdt...@gmail.com>; <john....@va.gov>
>> Sent: Wednesday, August 29, 2012 9:39 AM
>> Subject: Re: [Hardhats] Re: Fileman navigation question
>> I don't know how many times I have heard experienced programmers warn
>> other
>> programmers not to DINUM anything unless absolutely necessary as it
>> almost
>> always comes back to bite you. If someone can suggest and alternate
>> solution,
>> please consider using it or at least waiting until the experienced
>> programmers
>> get a chance to weigh in on why NOT to DINUM.
>> --
>> Nancy Anthracite
>> On Wednesday, August 29, 2012, Kevin Toppenberg wrote:
>> > John
>> > Thanks for the feedback. That will sort by the pointed-to file.
>> > I was thinking more of selecting a record, e.g. for an Inquire.
>> > But I have decided to avoid the whole problem by setting up the file in
>> a
>> > DINUM fashion, to the pointed-to record number and the record number
>> are
>> > the same.
>> > Thanks everyone,
>> > Kevin
>> > On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA)
Right but in my case Sam I think you will find no matter how you edit this file:
9999999.06 (LOCATION) you will get a new entry. In the WorldVistA version try changing IEN=67 to IEN=1. I will be interested in your results.
> On Sun, Sep 23, 2012 at 7:25 AM, Skip <skip....@gmail.com <javascript:>>wrote:
>> Just ran into a good reason DINUM can byte you big time. Was using: >> UPDATE^DIE("","FDA") to change the pointers from IENx to IENy. Life was >> good until it hit the DINUMed .01 entry in a file, I ended up adding a new >> entry. Oh well job security. :-)
>> On Wednesday, August 29, 2012 9:51:03 AM UTC-4, Marianne Susaanti >> Follingstad wrote:
>>> So don't use DINUM if you need multiple entries pointing to the same >>> entry >>> in another file. Although you can get around that if you extend the >>> DINUM >>> to increment by something (say .0001) if you know there won't be too >>> many >>> entries pointing to that same file entry. But then what Kevin wants >>> won't >>> work and you'd have to do something like I suggested.
>>> Personally I loved using DINUM as it allowed ordering things in ways >>> that >>> optimized the file or even subfile entries.
>>> Best wishes, >>> Marianne >>> ----- Original Message ----- >>> From: "Nancy Anthracite" <nanth...@earthlink.net> >>> To: <hard...@googlegroups.com> >>> Cc: "Kevin Toppenberg" <kdt...@gmail.com>; <john....@va.gov> >>> Sent: Wednesday, August 29, 2012 9:39 AM >>> Subject: Re: [Hardhats] Re: Fileman navigation question
>>> I don't know how many times I have heard experienced programmers warn >>> other >>> programmers not to DINUM anything unless absolutely necessary as it >>> almost >>> always comes back to bite you. If someone can suggest and alternate >>> solution, >>> please consider using it or at least waiting until the experienced >>> programmers >>> get a chance to weigh in on why NOT to DINUM.
>>> -- >>> Nancy Anthracite
>>> On Wednesday, August 29, 2012, Kevin Toppenberg wrote: >>> > John
>>> > Thanks for the feedback. That will sort by the pointed-to file.
>>> > I was thinking more of selecting a record, e.g. for an Inquire.
>>> > But I have decided to avoid the whole problem by setting up the file >>> in a >>> > DINUM fashion, to the pointed-to record number and the record number >>> are >>> > the same.
>>> > Thanks everyone, >>> > Kevin
>>> > On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. (KCVA)
Okay, I see what is going on and yes the problem should be reported as a bug to the VA via whatever is currently in vogue.
It happens at the subfile level. In this example I am changing the .01 field of the DIVISION subfile of the New Person file:
Before:
Global ^VA(200,1,2
^VA(200,1,2,0)="^200.02P^67^1"
^VA(200,1,2,67,0)="67^1"
^VA(200,1,2,"AX1",1,67)=""
^VA(200,1,2,"B",67,67)=""
TST>ZW DUZ
DUZ=1
DUZ(0)="@"
DUZ(1)=""
DUZ(2)=67
DUZ("AG")="E"
DUZ("BUF")=1
DUZ("LANG")=""
After:
Global ^VA(200,1,2
^VA(200,1,2,0)="^200.02P^67^1"
^VA(200,1,2,67,0)="1^1"
^VA(200,1,2,"AX1",1,67)=""
^VA(200,1,2,"B",1,67)=""
TST>K
TST>S DUZ=1 D ^XUP
Setting up programmer environment
This is a TEST account.
Terminal Type set to: C-VT100
You have 259 new messages.
Select OPTION NAME:
TST>ZW DUZ
DUZ=1
DUZ(0)="@"
DUZ(1)=""
DUZ(2)=67 <===should be 1
DUZ("AG")="E"
DUZ("BUF")=1
DUZ("LANG")=""
Be that as it may, the down side to using DINUM is even if UPDATE^DIE had worked as expected, I would still have to move the rest of the data from, in this case, IEN=67 to IEN=1 and maybe deleting IEN=67 after the data move. Whereas, if the .01 field was not DINUMed, all I would have to do is change the pointer value and life would be good.
On Monday, September 24, 2012 6:18:55 PM UTC-4, Skip wrote:
> Right but in my case Sam I think you will find no matter how you edit this > file:
> 9999999.06 (LOCATION) you will get a new entry. In the WorldVistA version > try changing IEN=67 to IEN=1. I will be interested in your results.
> On Monday, September 24, 2012 4:12:41 PM UTC-4, Sam Habiel wrote:
>> Skip,
>> We talked about this before. We think it's a defect in the updater.
>> On Sun, Sep 23, 2012 at 7:25 AM, Skip <skip....@gmail.com> wrote:
>>> Just ran into a good reason DINUM can byte you big time. Was using: >>> UPDATE^DIE("","FDA") to change the pointers from IENx to IENy. Life was >>> good until it hit the DINUMed .01 entry in a file, I ended up adding a new >>> entry. Oh well job security. :-)
>>> On Wednesday, August 29, 2012 9:51:03 AM UTC-4, Marianne Susaanti >>> Follingstad wrote:
>>>> So don't use DINUM if you need multiple entries pointing to the same >>>> entry >>>> in another file. Although you can get around that if you extend the >>>> DINUM >>>> to increment by something (say .0001) if you know there won't be too >>>> many >>>> entries pointing to that same file entry. But then what Kevin wants >>>> won't >>>> work and you'd have to do something like I suggested.
>>>> Personally I loved using DINUM as it allowed ordering things in ways >>>> that >>>> optimized the file or even subfile entries.
>>>> Best wishes, >>>> Marianne >>>> ----- Original Message ----- >>>> From: "Nancy Anthracite" <nanth...@earthlink.net> >>>> To: <hard...@googlegroups.com> >>>> Cc: "Kevin Toppenberg" <kdt...@gmail.com>; <john....@va.gov> >>>> Sent: Wednesday, August 29, 2012 9:39 AM >>>> Subject: Re: [Hardhats] Re: Fileman navigation question
>>>> I don't know how many times I have heard experienced programmers warn >>>> other >>>> programmers not to DINUM anything unless absolutely necessary as it >>>> almost >>>> always comes back to bite you. If someone can suggest and alternate >>>> solution, >>>> please consider using it or at least waiting until the experienced >>>> programmers >>>> get a chance to weigh in on why NOT to DINUM.
>>>> -- >>>> Nancy Anthracite
>>>> On Wednesday, August 29, 2012, Kevin Toppenberg wrote: >>>> > John
>>>> > Thanks for the feedback. That will sort by the pointed-to file.
>>>> > I was thinking more of selecting a record, e.g. for an Inquire.
>>>> > But I have decided to avoid the whole problem by setting up the file >>>> in a >>>> > DINUM fashion, to the pointed-to record number and the record number >>>> are >>>> > the same.
>>>> > Thanks everyone, >>>> > Kevin
>>>> > On Wednesday, August 29, 2012 8:45:14 AM UTC-4, Walkup, John H. >>>> (KCVA)
