SBS 2003 SP1 problem

svamplussvamplus Posts: 11 Bronze 2
edited January 5, 2006 12:50PM in SQL Compare Previous Versions
Hello!
Last Sunday I’ve installed on my Small Business Server 2003 the latest service pack (SP1) and the latest ISA server (2004). Before that SQL compare worked great (latest version – 3.2.1.14). After that it stopped working in a very strange way.
1) If I compare 2 databases on my PC everything is OK.
2) If I put my SBS on the left and my PC on the right of the “Comparison Settings” window, everything works fine.
3) If I put my PC on the left and my SBS on the right of the “Comparison Settings” window, everything works fine.
4) But, if I compare two databases on my SBS (for testing purposes, I’ll compare one database with itself), then the scripting of the left database passes OK, but the right database does not. It gets to up to 3 seconds to the end (estimated time left), waits here for about 30 seconds and then displays a window telling “SQL server does not exist or access denied”. I’m comparing the same database I’ve used in steps 2 and 3 without any errors.


Any suggestions?

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hello,

    It's hard to say on this one. Perhaps you're limiting the number of connections that the server will allow?
  • svamplussvamplus Posts: 11 Bronze 2
    Do you mean the SBS server or the SQL server?
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    In the SQL Server, you can set this on the server properties, on the connection tab. 0=unlimited connections.
  • svamplussvamplus Posts: 11 Bronze 2
    Yes, it is configured like that. I've noticed that when SQL compare hangs, IE also hangs.
    Let me explain: I run SQL compare and the scripting begins, then after a while it hangs. If I open IE at that moment and try to go to our intranet site (hosted on the same server where our SQL server resides) the answer I receive is: The page cannot be displayed.
    When I turn off SQL compare after the hanging, the page in IE is displayed correctly.
    Any ideas?
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    It sounds like you are simply running out of server resources. Try not running the software on the server and running it from a client computer on the network instead.
  • svamplussvamplus Posts: 11 Bronze 2
    SQL compare is installed on my Windows XP SP2 Workstation (AMD Athlon XP 2100+, 512 MB RAM). I think the problem is network related.
    I’ve tried installing SQL compare on the server and I then compare the databases locally. I successfully compared several databases without any problem.
    I emphasize that the problems started when I installed Windows SBS 2003 SP1 on my server. Windows SBS 2003 SP1 includes Win 2003 SP1. Before that I had no problems.
  • Have you got the latest .NET service pack? I believe that would bring your .NET version up to 1.1.4322.2032
  • svamplussvamplus Posts: 11 Bronze 2
    I can see that I have versions v1.0.3705, v1.1.4322 and v2.0.50727 installed. How can I find out the exact version as you specified it?
  • The only way I know if to open %Systemroot%\Assembly and look at the properties of mscorcfg. The version number in the version tab of the property sheet should list the full build version.
  • svamplussvamplus Posts: 11 Bronze 2
    I have installed .NET Framework 1.1 SP1

    mscorcfg.dll -- v1.1.4322.573
    mscordbc.dll -- v1.1.4322.2032

    On internet i found out that .Net Framework SP1 doesn't change version of
    mscorsfg.dll file. There are many articles about it so I'll read little more before I post an answer.
  • svamplussvamplus Posts: 11 Bronze 2
    Any news? Is there any log I can send you for you to investigate this problem?
  • Hi

    i have just reread your original post and have you checked your ISA settings. It could be related to rules allowing traffic from the local network to the machine. Do you have a local host entry in the rules for example?

    Regards
    Dan
    Daniel Handley
    Red Gate Software Ltd
  • svamplussvamplus Posts: 11 Bronze 2
    I have ISA 2004, and in the configuration/networks node I have a Local Host entry.

    I remind you that the problem is with 1 machine we have. The other works fine. And with the machine that does not work, the first database is scripted correctly, the second database fails.
    Both machines are WinXP SP2, with all the WindowsUpdate patches installed; DHCP, Microsoft Firewall client for ISA 2004, in the same location, in the same domain.
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Could it be the MDAC installation on the client running SQL Compare? Can you try downloading MDAC and running an update?

    We have also found that sometimes it helps to force SQL Compare's ADO .NET client to use TCP/IP by putting TCP:<server> in the server box, and also checking the Server Network Utility to make sure TCP/IP is enabled.

    We have noticed that SQL Compare doesn't work nearly as well with Named Pipes as it does with TCP/IP.
  • svamplussvamplus Posts: 11 Bronze 2
    MDAC 2.8 sp1 ON Win SP2

    If I put TCP:PAN (PAN is our servername) SQL compare tells me: "Invalid connection".
    On the client the only allowed protocol is TCP/IP, on the server both TCP/IP and Named pipes are allowed.

    Does SQL compare connect to the second database in a different way than to the first? The scripting of the first database goes extremly fast.
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    You may want to try changing the protocol order as described by Microsoft in this article so that TCP/IP is first in the list. This will prevent the connection from bombing out if an attempt fails at connecting using named pipes:

    http://support.microsoft.com/kb/328383/
  • svamplussvamplus Posts: 11 Bronze 2
    I've finally solved the problem.
    The problem (strangely) was the TCP/IP protocol used to communicate with the server.
    The difference between my computer (the working one) and the computer of my colleague (the NOT working one) was that I had both TCP/IP and Named Pipes as client protocols while he had TCP/IP only. When I configured the server to have TCP/IP only, my computer stopped working also.
    I then added Named Pipes to both the server and the clients and everything started working correctly.
    It seems that the order of the protocols has a part of how fast SQL compare works. If I put TCP/IP and then Named Pipes on the clients it works faster then the other way around.

    Could all this be a strange bug in SQL compare?
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    I haven't identified the cause of the problem but I have notified development so they can look into it. It could be SQL Compare, and it could be ADO .NET. If you use Network Monitor (included with Windows Server 2003) on the server and analyze the network traffic, you see numerous things happening with NETBIOS, eventually culminating in the network library on the client trying to access the server as a network share rather than a SQL Server. This is why forcing TCP/IP helps a lot because SQL Compare doesn't seem to work so well with named pipes.
This discussion has been closed.