Hello Paul, I would also check the active port on the Linux side. Might be worth monitoring that port and looking for data. Maybe one side or the other is not passing what we think it is. Not passing the port on the Linux side might be another situation, depending on what flavor of Linux the box is running. Might be worth doing a list of the iptables (iptables -L) and see if there is something funny going on there.
One other minor annoyance (not something I have seen with database stuff) was on the Windows side passing the CR/LF combination and that not being needed on the Linux side of things. One other URL that you probably have run across that may have some further ideas is: http://www.idevelopment.info/data/MSSQL/DBA_tips/Programming/PROG_2.shtml It does cover some of the TDS protocol issues. What flavor of Linux is running? Are you using Server 2000 or later for the Microsoft end of the connection? If it is something later that Server 2000 there may be some other surprises in store that are keeping things from working. Not being terribly familar with later (Windows) software, I would not be surprised if there are administrative rights or similar stuff causing things to derail. It has been a very long time since I tried the ODBC connector software on Windows, so I may be (and probably am) seriously out of date. The last time I did fight that battle I was following some of the instructions that were for the ODBC link to PostgreSQL ( http://www.postgresql.org ) from Windows. Since your stuffing data in the other direction that may not be relevant at all. Dave On Thu, 2010-07-29 at 16:13 -0500, Paul Boniol wrote: > On Thu, Jul 29, 2010 at 9:29 AM, David R. Wilson <[email protected]> > wrote: > Hmmm... That is what I get for being several hours behind. > > See if this helps: > > http://members.toast.net/strycher/perl/example_dbi_sql.htm > > You may still have some firewall issues to look at. > > Dave > > > Basically I'm up to configuring ODBC on Linux now. (Perl I've had > working with error messages on all connect/prepare/execute/etc. calls > for a few years.) > > > FreeTDS (on Linux) is connecting and executing queries just fine. > > > It appears to be some problem with unixODBC remembering (or thinking > about) DSN's that I've told it about. (The behavior is like changing > a config file but not rebooting a service, so it's still operating > under the previous config. But I've even rebooted Linux, so that's > not it.) > > > I've double checked my spelling of everything. I've done user DSN's, > system DSN's, manual config, tool config. I haven't tried setting up > "ODBC only" config, but that's what I'm trying next. > > > Paul > -- > You received this message because you are subscribed to the Google > Groups "NLUG" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to nlug-talk > [email protected] > For more options, visit this group at > http://groups.google.com/group/nlug-talk?hl=en -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
