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