I have finally printed out the GTM system
administrator's manual, and am picking through it. I
have some questions about database replication at a
remote site. I'm guessing this is a Bhaskar
question--but anyone can answer.
>From my initial review, it seems that database
replication takes place
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
Thurman,
This will only help you edit them after you have added
them. If you want help doing a batch upload, let me
know off list.
Kevin
--- Thurman Pedigo <[EMAIL PROTECTED]> wrote:
> This should be a great help to me. I have around
> 18,000 file I need to
> convert. Will move me a long way t
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-selec
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
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)
Sel
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
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. P
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 t
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 funct
11 matches
Mail list logo
