Connection refused error
All, Interesting connection issue, here. I think I've done everything correctly, but I am unable to connect from a Windows NT desktop to our Standard Engine (v.5.0) database running on a SCO (v.5.0.5) box on an Intel 386. I've properly set-up and double checked the following: ODBC Administrator (client): Database Name Host Name Service Name Server Name Protocol Type (sesoctcp) SetNet32 (version 7.2) (client): Environment: INFORMIXDIR INFORMIXSERVER Server Information: Informix Server Hostname Protocol Name (sesoctcp) Service Name Host Information: Current Host Password Option (Ask at runtime) Services file (client): Proper services entry sqlhosts file (server): Proper sqlhosts entry with correct servername, protocol, hostname, and service name /etc/services file (server): Proper services entry The error message that I get looks like this: [INTERSOLV][ODBC Informix driver][Informix]Attempt to connect to database server (servername) failed. [INTERSOLV][ODBC Informix driver][Informix]Connection refused I've double-checked that all of my Informix server names match, all of my host names are correct, all of my service names match, all on the client and on the server. We've also tried re-booting both the client and the server. There is no onconfig file on the server like there is with On-Line, so I don't think there's anything else to do. What could be causing this problem? It seems to me I've seen this issue before, even while connecting to On-Line instances with my past company, but we never figured out how to fix it. The current set-up works in my current company when pointed to our On-Line instances on HP's, just not to our SE instance on SCO. Am I missing something here? Is my connectivity software just buggy? Am I using the wrong version of something? Any other thoughts? Anyone seen this before? Thanks again for any insight. Kind regards, -- <><><><><><><><> John Bejarano bebe stores, inc. <><><><><><><><> --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---
You need Informix Star TCP/IP network module with the 5.x engine for client/server archictecture. I-Star is sold as a separate product for the 5.x engines. John Bejarano wrote: > All, > > Interesting connection issue, here. I think I've done everything > correctly, but I am unable to connect from a Windows NT desktop to our > Standard Engine (v.5.0) database running on a SCO (v.5.0.5) box on an > Intel 386. > > I've properly set-up and double checked the following: > > ODBC Administrator (client): > Database Name > Host Name > Service Name > Server Name > Protocol Type (sesoctcp) > > SetNet32 (version 7.2) (client): > Environment: > INFORMIXDIR > INFORMIXSERVER > Server Information: > Informix Server > Hostname > Protocol Name (sesoctcp) > Service Name > Host Information: > Current Host > Password Option (Ask at runtime) > > Services file (client): > Proper services entry > > sqlhosts file (server): > Proper sqlhosts entry with correct servername, protocol, hostname, > and service name > > /etc/services file (server): > Proper services entry > > The error message that I get looks like this: > > [INTERSOLV][ODBC Informix driver][Informix]Attempt to connect to > database server (servername) failed. > [INTERSOLV][ODBC Informix driver][Informix]Connection refused > > I've double-checked that all of my Informix server names match, all of > my host names are correct, all of my service names match, all on the > client and on the server. We've also tried re-booting both the > client and the server. There is no onconfig file on the server like > there is with On-Line, so I don't think there's anything else to do. > > What could be causing this problem? It seems to me I've seen this issue > before, even while connecting to On-Line instances with my past company, > but we never figured out how to fix it. The current set-up works in > my current company when pointed to our On-Line instances on HP's, just > not to our SE instance on SCO. Am I missing something here? Is my > connectivity software just buggy? Am I using the wrong version of > something? Any other thoughts? Anyone seen this before? > > Thanks again for any insight. > > Kind regards, > > -- > <><><><><><><><> > John Bejarano > bebe stores, inc. > <><><><><><><><> > > --== Sent via Deja.com http://www.deja.com/ ==-- > ---Share what you know. Learn what you don't.---
John Bejarano wrote: > > All, > > Interesting connection issue, here. I think I've done everything > correctly, but I am unable to connect from a Windows NT desktop to our > Standard Engine (v.5.0) database running on a SCO (v.5.0.5) box on an > Intel 386. > > I've properly set-up and double checked the following: > > ODBC Administrator (client): > Database Name > Host Name > Service Name > Server Name > Protocol Type (sesoctcp) > > SetNet32 (version 7.2) (client): > Environment: > INFORMIXDIR > INFORMIXSERVER > Server Information: > Informix Server > Hostname > Protocol Name (sesoctcp) > Service Name > Host Information: > Current Host > Password Option (Ask at runtime) > > Services file (client): > Proper services entry > > sqlhosts file (server): > Proper sqlhosts entry with correct servername, protocol, hostname, > and service name > > /etc/services file (server): > Proper services entry And have you run $INFORMIXDIR/lib/sqlexecd on the server? Version 5.0 requires I-Net (a separate product), and you have to have sqlexecd listening for network connections. Since you don't mention this and you do mention just about everything else, this is likely the source of the trouble. V5.x connectivity is rather different from later versions (eg 7.x). > The error message that I get looks like this: > > [INTERSOLV][ODBC Informix driver][Informix]Attempt to connect to > database server (servername) failed. > [INTERSOLV][ODBC Informix driver][Informix]Connection refused > > I've double-checked that all of my Informix server names match, all of > my host names are correct, all of my service names match, all on the > client and on the server. We've also tried re-booting both the > client and the server. There is no onconfig file on the server like > there is with On-Line, so I don't think there's anything else to do. > > What could be causing this problem? It seems to me I've seen this issue > before, even while connecting to On-Line instances with my past company, > but we never figured out how to fix it. The current set-up works in > my current company when pointed to our On-Line instances on HP's, just > not to our SE instance on SCO. Am I missing something here? Is my > connectivity software just buggy? Am I using the wrong version of > something? Any other thoughts? Anyone seen this before? > > Thanks again for any insight. > > Kind regards, > > -- > <><><><><><><><> > John Bejarano > bebe stores, inc. > <><><><><><><><> > > --== Sent via Deja.com http://www.deja.com/ ==-- > ---Share what you know. Learn what you don't.--- -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>
Larry, I-Star is available directly from Informix, correct? Does I-Star live on the client or the server, or are there pieces of it that live on both? Can I-Star co-exist on a client (if that's where it goes), with CLI? Thanks. Kind regards, John Bejarano In article <374486A5.3442976A@maine.rr.com>, Larry Benoit <lbenoit@maine.rr.com> wrote: > You need Informix Star TCP/IP network module with the 5.x engine for > client/server archictecture. I-Star is sold as a separate product for the > 5.x engines. > -- <><><><><><><><> John Bejarano bebe stores, inc. <><><><><><><><> --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---
Jonathan, I'm afraid it's this I-Net or I-Star product that is required, (I just have CLI). sqlexecd is indeed running on the server. Thanks. Kind regards, John Bejarano. In article <3744F3E4.748E@earthlink.net>, jleffler@earthlink.net wrote: > And have you run $INFORMIXDIR/lib/sqlexecd on the server? > Version 5.0 requires I-Net (a separate product), and you have to > have sqlexecd listening for network connections. Since you don't > mention this and you do mention just about everything else, this > is likely the source of the trouble. V5.x connectivity is rather > different from later versions (eg 7.x). > > -- > Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN > #include <disclaimer.h> > > -- <><><><><><><><> John Bejarano bebe stores, inc. <><><><><><><><> --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---
John Bejarano wrote: > I'm afraid it's this I-Net or I-Star product that is required, (I just > have CLI). sqlexecd is indeed running on the server. Thanks. I-Net is used to provide distributed access to SE; I-Star is used with OnLine to provide fully distributed databases. I-Net fundamentally consists of a network-enabled version of the sqlexec process, and a copy of sqlexecd. Since you say sqlexecd is running on the server, you probably already have I-Net. Or are you confusing sqlexec with sqlexecd -- they're two very different programs. If you have sqlexecd running on the server and it is listening to the correct service name (you specify the service name as an argument when you start sqlexecd, but it defaults to the sqlexec service), then you should be able to connect to the database OK. Do you have any other Unix hosts than the SCO box with Informix software on them? If so, you can debug the Unix-to-Unix connectivity more easily (probably). If not, then you can use the //server/database notation to get at the database from the SCO box, but it isn't as good as using a second Unix box. Once you've done that, you should be able to connect from the PC side, though you may have to do some work to get the connections trusted. > In article <3744F3E4.748E@earthlink.net>, > jleffler@earthlink.net wrote: > > And have you run $INFORMIXDIR/lib/sqlexecd on the server? > > Version 5.0 requires I-Net (a separate product), and you have to > > have sqlexecd listening for network connections. Since you don't > > mention this and you do mention just about everything else, this > > is likely the source of the trouble. V5.x connectivity is rather > > different from later versions (eg 7.x). [...I note there was a lot of detailed info in John's original message which has been left off in this and the previous response. If you want to join in the discussion, please backtrack to the original question for the info...] -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>