And you've completely missed the point ...
Yes it is a local file. But it's created as part of the bigger process
of enabling access to the account. Just creating the file is useless.
Once it's created, getting HS.UPDATE.FILEINFO to run isn't enough. It's
all the other things that "prepare this account for odbc access" does
that aren't getting done.
What's the point of creating the file, if the odbc daemon doesn't know
the account exists to look for it? etc etc. I don't know what's going on
under the bonnet, and if the car splutters to a halt half way down the
road EVERY time I try, I'm not going to get very far, am I?
Anyway - this problem was caused (I presume) because I kept *deleting*
the file to try and give each subsequent attempt another clear shot at
eanbling access. So it's clear that just creating it is going to do
nothing.
Cheers,
Wol
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Peter Olson
Sent: 26 February 2004 12:48
To: 'U2 Users Discussion List'
Subject: RE: ODBC problem - biggie and technical
isn't hs_file_access a local file in the account you want to export
tables
from ?
if not create it ?
then see if you can see table from client
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Anthony Youngman
Sent: Thursday, February 26, 2004 4:30 AM
To: [EMAIL PROTECTED]
Subject: ODBC problem - biggie and technical
I'm trying to enable odbc access to an account. odbc is working fine for
other accounts, so it SEEMS to be a problem with just this one account.
However, I suspect I may have damaged the HS.ADMIN account in my efforts
to get this to work :-(
Okay. What's caused the problem is wIntegrate. As you may know (various
people have moaned) it will occasionally terminate a session for no
apparent reason whatsoever. The only program that does this to us is
HS.UPDATE.FILEINFO. You can guess what's coming ...
The "enable odbc access" option in HS.ADMIN calls HS.UPDATE.FILEINFO as
part of its workings. It killed the session half way through ...
After several attempts to get it to behave itself, I am now getting
errors where it is unable to initialise the HS_FILE_ACCESS file. I'm not
sure whether there is supposed to be an HS_FILE_ACCESS file in the
HS.ADMIN account, but if there is, I've accidentally deleted it. It
doesn't appear to be there on my other server, though.
So I'm now stuffed. How do I get HS.ADMIN working again, or
alternatively bypass it completely to enable ODBC access. If anybody
knows what *HS.ACTIVATE does (in detail), or can slip me the source or
tell me where to find it, or can help me some other way, thanks very
much.
Cheers,
Wol
***
This transmission is intended for the named recipient only. It may
contain
private and confidential information. If this has come to you in error
you
must not act on anything disclosed in it, nor must you copy it, modify
it,
disseminate it in any way, or show it to anyone. Please e-mail the
sender to
inform us of the transmission error or telephone ECA International
immediately and delete the e-mail from your information system.
Telephone numbers for ECA International offices are: Sydney +61 (0)2
9911
7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York
+1
212 582 2333.
***
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
Notice of Confidentiality: The information included and/or attached in
this
electronic mail transmission may contain confidential or privileged
information and is intended for the addressee. Any unauthorized
disclosure,
reproduction, distribution or the taking of action in reliance on the
contents of the information is prohibited. If you believe that you have
received the message in error, please notify the sender by reply
transmission and delete the message without copying or disclosing it.
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
