Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
A user needed to rescue data from an Informix server whose filesystem was badly corrupted (no FTP/vi, can't edit .rhosts), leaving only ODBC/remote access; dbexport, dbcopy, myexport and similar utilities all failed with error -956 (client host/user not trusted). Suggestions included using dbaccess's non-trusted-host login (which did work for connecting with explicit user/password, though the export tools still failed) and, instead, running UNLOAD TO ... SELECT * FROM table per table, generating the UNLOAD statements with a SELECT over systables where tabid >= 100. The thread ends with the poster asking whether sqlcmd was used for that, so no confirmed resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Simmons, Keith — — source: Usenet: comp.databases.informix
VP
usually if you run dbaccess and the Connect to a non-trusted host
you get a username/password dialogue. If you enter a valid c
combination for he target host you should be able to get access
(unless your assword/sshadow files are corrupt).
Keith
-----Original Message-----
From: vpreatr@gmail.com [mailto:vpreatr@gmail.com]
Sent: Wednesday, June 07, 2006 11:32
To: informix-list@iiug.org
Subject: Re: Help needed in transfering or backing up/restoring Informix
database via ODBC.
David,
Unfortunately I only have ODBC access, the server is not configured to
trust another INFORMIXSERVER nor can I add trust via allow.hosts (or
.rhosts) due to the level of file corruption on the failing server.
Typically I'd access the server via DBACCESS and DBEXPORT remotely
providing a trust relationship was established with the source location
(workstation/server IP, username, etc. ) - that isn't the case here. If
I attempt to access the server with such tools, I'm greeted with a
"Client host or user (myid@myaddress.com) is not trusted by the
server."
So basically unless a utility exists with the capability of dbexport or
dbcopy that can bypass or ignore the client host/use trust
restrictions; I'm limited solely to ODBC and the server is truly on
borrowed time. (If the Informix server were to be shutdown, it would
never start again due to the level of corruption at the filesystem
level)
Thanks!
david@smooth1.co.uk wrote:
> Go to www.iiug.org and the Software section. Get Art Kagels utils_ak2
> and use dbcopy from there to copy the data.
>
> The new tables should not have contraints or indexes on them whilst the
> copy is happening.
>
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
***********************************************************************************************
This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission.
This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems.
***********************************************************************************************
Hi Keith,
I've tried a couple different configuration options between servers
in attempt to access the failing server via DBACCESS and/or DBEXPORT,
all return with a -956 error; same user names, passwords and similar
configurations were attempted; a typical resolve would be a simple
addition to the .rhosts file in the /home/root (and possibly
/home/informix) directories; due to the filesystem damage that isn't
an option; FTP, SU, VI or similar type tools isn't executable
(library corruption). Not to mention the server is off-site, so command
line access has been limited telephone communication; the filesystem is
that badly damaged and I until a backup/export of the data is taken and
confirmed; I'm avoiding any attempts to correct and/or address the
filesystem damage as the server may never come online again. :(
Ultimately the filesystem hard drive is a total loss, Informix is
online as it's all inclusive in memory and the chunks are on a
separate drive.
Well, I'm back to editing long statement .SQL files (truncating them
for Informix usage); thank you (to everyone) that has replied; any
additional thoughts, ideas are certainly welcomed!
Thanks!
Simmons, Keith wrote:
> VP
>
> usually if you run dbaccess and the Connect to a non-trusted host
> you get a username/password dialogue. If you enter a valid c
> combination for he target host you should be able to get access
> (unless your assword/sshadow files are corrupt).
>
> Keith
I've since established DBACESS via TCP by specifying name and password;
however I'm unable to use any of the tools needed; i.e. dbexport,
myschema, myexport - due to the trust error encountered (-956).
Is there a tool similar to dbexport or myexport that allows specifying
hostname, username and password.
Thanks!
UNLOAD TO "filename"
SELECT * FROM <tablename>
or to generate the unload statements you could run
SELECT "UNLOAD TO " || TRIM(tabname) ".unl SELECT * FROM " || tabname
FROM systable
WHERE tabid >= 100
save the output in a file and run the file (you may need to remove the
column heading "expression")
vpreatr@gmail.com wrote:
> I've since established DBACESS via TCP by specifying name and password;
> however I'm unable to use any of the tools needed; i.e. dbexport,
> myschema, myexport - due to the trust error encountered (-956).
>
> Is there a tool similar to dbexport or myexport that allows specifying
> hostname, username and password.
>
> Thanks!
scottishpoet wrote:
> UNLOAD TO "filename"
> SELECT * FROM <tablename>>
> or to generate the unload statements you could run
>
> SELECT "UNLOAD TO " || TRIM(tabname) ".unl SELECT * FROM " || tabname
> FROM systable
> WHERE tabid >= 100
>
> save the output in a file and run the file (you may need to remove the
> column heading "expression")
>
Ooops
systables not systable
scottishpoet,
Are you using sqlcmd to perform the following:
SELECT "UNLOAD TO " || TRIM(tabname) ".unl SELECT * FROM " || tabname
FROM systables
WHERE tabid >= 100
Thanks!
scottishpoet wrote:
> scottishpoet wrote:
> > UNLOAD TO "filename"
> > SELECT * FROM <tablename>> >
> > or to generate the unload statements you could run
> >
> > SELECT "UNLOAD TO " || TRIM(tabname) ".unl SELECT * FROM " || tabname
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.