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.
Servio Velasco wanted to use CONNECT in a stored procedure to reach another server without trusted relations on IDS 11.50.FC3. Art Kagel said CONNECT cannot be used there but distributed query syntax database@server:table can. Fernando Nunes questioned the trust objections and listed alternatives: PAM, an 11.7 trust file, or a Java procedure with password storage issues.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello everybody
Anybody know how to use "Connect" statement in a Store procedure.
I am needing to connect to other server and instance but I can not use trusted
relations between computers.
Thanks a lot
Regards
Servio Velasco
On Wed, Jun 20, 2012 at 5:37 PM, SERVIO VELASCO
<servio_velasco@hotmail.com>wrote:
> Hello everybody
>
> Anybody know how to use "Connect" statement in a Store procedure.
>
I believe you can't.
>
> I am needing to connect to other server and instance but I can not use
> trusted
> relations between computers.
>
Why?
Which version?
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--00248c70fdddee50ce04c2ea1c6e
You cannot use CONNECT in a stored procedure, however, you CAN use
distributed query syntax to get data from another server:
select *
from remote_db@remote_instance:remote_table.column...
;
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Jun 20, 2012 at 12:37 PM, SERVIO VELASCO <servio_velasco@hotmail.com
> wrote:
> Hello everybody
>
> Anybody know how to use "Connect" statement in a Store procedure.
>
> I am needing to connect to other server and instance but I can not use
> trusted
> relations between computers.
>
> Thanks a lot
> Regards
>
> Servio Velasco
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--90e6ba21225739fe5104c2ea7eac
On Wed, Jun 20, 2012 at 6:03 PM, SERVIO VELASCO
<servio_velasco@hotmail.com>wrote:
> Why?
> Because security politics of company.
> Which version?
> Informix Dynamic Server 11.50.FC3 in Solaris 11
>
Sorry if this looks too incisive, but what are those policies trying to
prevent?
"trusted servers" usually means people are afraid of users connecting from
one server to another vi login etc... And this is a misconception.
You don't need to make all the users trusted. And setting up ".rhosts" or
/etc/hosts.equiv will only allow remote logins if you have your r* services
running. And if you do, I rest my case (and you can throw your policies to
the trash can).
Other options would include PAM and if you were on 11.7 you could use a
specific file to define the trusted relations (this file is only used by
the Informix instance).
Another option would be Java. Only in a Java procedure you can explicitly
connect. But then you'd have the problem of how you store the password. Any
way I know would clash with reasonable security policies.
Consider all this, and feel free to point your objections.
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--485b393aab7384130a04c2eaa104
Your privacy choices
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.