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.
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
This should be a great help to me. I have around 18,000 file I need to
convert. Will move me a long way toward complete conversiontx/t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hardhats-
> [EMAIL PROTECTED] On Behalf Of Nancy Anthracite
> Sent: Sunday, February 13, 2005 7:
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
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
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: d
Nice going, Kevin! The VistA Office folks might like this once you get your
last problem solved.
On Sunday 13 February 2005 08:03 pm, Kevin Toppenberg wrote:
> Hey all,
>
> I have some code to offer othes here (if they want
> it), and some thoughts and questions.
>
> First, I wrote some custom
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, i
Time to start over again, Thurman. Maybe it will work this time!
--
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 liv
Hey all,
I have some code to offer othes here (if they want
it), and some thoughts and questions.
First, I wrote some custom code that bulk-created
patient records in the PATIENT file. I ported over
around 70,000 patients. Now, as I use these patients,
I am finding that some tweeking needs to b
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 (PATIEN
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 Top
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)
f
13 matches
Mail list logo
