Fileman navigation question

[Kevin Toppenberg]

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 how do I pick the record I want?

Thanks

Kevin

[Kevin Toppenberg]

No way to do this?

Kevin

[Marianne Susaanti Follingstad]

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

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Kevin Toppenberg]

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

[Walkup, John H. (KCVA)]

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: hard...@googlegroups.com [mailto:hard...@googlegroups.com] On Behalf Of Kevin Toppenberg
Sent: Tuesday, August 28, 2012 5:08 PM
To: hard...@googlegroups.com
Subject: [Hardhats] Re: Fileman navigation question

 

No way to do this?

--

[Kevin Toppenberg]

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

[Nancy Anthracite]

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)
>
> wrote:
> > 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:* hard...@googlegroups.com <javascript:> [mailto:
> > hard...@googlegroups.com <javascript:>] *On Behalf Of *Kevin Toppenberg
> > *Sent:* Tuesday, August 28, 2012 5:08 PM
> > *To:* hard...@googlegroups.com <javascript:>
> > *Subject:* [Hardhats] Re: Fileman navigation question

[Marianne Susaanti Follingstad]

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.

 

Best wishes,

Marianne

----- Original Message -----

From: Kevin Toppenberg

To: hard...@googlegroups.com

[Marianne Susaanti Follingstad]

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 -----

> > 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:* hard...@googlegroups.com <javascript:> [mailto:
> > hard...@googlegroups.com <javascript:>] *On Behalf Of *Kevin Toppenberg
> > *Sent:* Tuesday, August 28, 2012 5:08 PM
> > *To:* hard...@googlegroups.com <javascript:>
> > *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 how do I pick the record I want?
> >
> >
> >
> > Thanks
> >
> > Kevin

[George Timson]

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 will investigate and fix in the next release at http://www.hardhats.org/fileman/MSC.html.

--George Timson

[George Timson]

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.

[Kevin Toppenberg]

Thanks George.  I knew you would have thought about this issue already.

Kevin

[Walkup, John H. (KCVA)]

There weren’t any “double quotes” in my example.

 

John H. Walkup <IRM>

Kansas City VA Medical Center

816.922.2946

 

 

“The more people it takes to hold the light bulb, the fewer are available to turn the chair”

 

 

--

[Skip]

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.  :-)

[Sam Habiel]

Skip,

We talked about this before. We think it's a defect in the updater.

https://groups.google.com/forum/?fromgroups=#!msg/hardhats/ZiJYkMODEpA/hzywmSsm34YJ

[Skip]

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.

[Skip]

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.