I agree with the advice given in a previous post by Kathleeni and
this one by Andy.
NEVER try to use UV/ODBC against the standard production account!
ALWAYS create another account with F pointers that point to the
product account data sections but have local CLEAN dictionaries. I
also adv
This is a brand new uv account - the problem seems to be on a uv file
D_UV_ASSOC and I'm not sure if I can delete that
Mac
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anthony Youngman
Sent: 25 Jun 2008 16:34
To: 'u2-users@listserver.u2ug.org'
Subject
There is a slot where you can specify the name of a program that gets called
when a responder starts. We use that to initiate the COMMON block and in
there we put REDBACK into one of our common variables and check that
everywhere it matters.
George Land
APT Solutions Ltd
UK U2 Distributor
www.u2u
Yes I know it's a UV file. That was point of me mentioning PTERM.FILE - that's
a UV file too and it was UV files that gave me the most grief.
Does anybody know what UV_ASSOC does? Is it safe to delete the VOC pointer? It
looks to me like it's part of the SQL table mechanism so if you're not actu
Just had a thought. Could it be access rights? If, as looks likely, this is
used by UV to manage schemas, it might be locked down so only the SQL DBA can
edit it. What's the betting that would cause your problem?
In that case, it's nasty, because it also means any attempt to run
HS.UPDATE.FILEI
One of the previous recommendations seems to fit the bill, use @logname or
@who to determine if it's your Redback user and adjust the code accordingly.
All Redback requests will have the ID of user ID used to set it up.
Mike Randall, MCP
-Original Message-
From: [EMAIL PROTECTED]
Where is this slot defined? LOGIN paragraph is called, as normal is all I
knew we could count on...
Where is this slot? Is it called before or after the LOGIN paragraph?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of George Land
> Sent: Thursday