• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 152
  • Last Modified:

Tracing a network communication.

We recently migrated a SQL 2000 database and an accompanying file share from a physical to a virtual machine.
All went well and the physical SQL database and file share were taken offline and the shares removed.  No problems so far.
The problem came in that when they physical machine was shut down the client application using the database started to exhibit seizures although on each occasion it would evenutally come back with the right information.

The puzzle is that even with the SQL server service completely disabled on the physical machine the client has no issue, it is only when the server is shut down it somehow brings about a problem.

I realise this problem could have many causes and think that what is needed is a way of detecting what exactly is being accessed on the physical server and by what in order to track down the source of the problem.

Can anybody reccomend a tool I can run on the physical server so I can observe the nature of inbound communications which are being received?

Thanks in advance.
0
dgloveruk
Asked:
dgloveruk
  • 2
1 Solution
 
lcohanDatabase AnalystCommented:
Wow that's interesting...I would use Process Explorere/Monitor
http://technet.microsoft.com/en-us/sysinternals/bb896653
http://technet.microsoft.com/en-us/sysinternals/bb896645

Besides that how are the computers/servers/IP for the OLD new in your DNS tables?
Hopefully you don't have two diferent ip's referenced by the same SQL name
0
 
dgloverukAuthor Commented:
Hi Icohan,
The problem turned out to be that the database clients used a UNC filepath which was still pointing to the old server.  The UNC filepath was for some icons within the client which defaulted to other icons when they could not locate the ICO file on the server they started on.
With the old server on but with the shares disabled the server responded quickly with a denial and so the client defferred after a short delay to the default icons.
With the server off however the server did not respond and caused an even more pronounced delay to the client in trying to resolve the UNC filepath.
I used a script in SQL server to scan every single text field in the database for references to the old server and detected the problem.
Having corrected this not only did it resolve the issue, the client works a darn sight faster than it did in the first place.
Many thanks for your help!
0
 
dgloverukAuthor Commented:
Hi Icohan,
The problem turned out to be that the database clients used a UNC filepath which was still pointing to the old server.  The UNC filepath was for some icons within the client which defaulted to other icons when they could not locate the ICO file on the server they started on.
With the old server on but with the shares disabled the server responded quickly with a denial and so the client defferred after a short delay to the default icons.
With the server off however the server did not respond and caused an even more pronounced delay to the client in trying to resolve the UNC filepath.
I used a script in SQL server to scan every single text field in the database for references to the old server and detected the problem.
Having corrected this not only did it resolve the issue, the client works a darn sight faster than it did in the first place.
Many thanks for your help!
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now