January 14, 2005 at 8:03 am
However I would suggest he did potentially dig himself a hole.
From what you said.
1) It is Firefox.
Issue is firefox is designed to be self contained and not rely on system DLLs, this is why it can be installed easily to a network drive.
What steps led hime to his statement and what proff does he have?
2) It damaged DLLs related to SQLs funtionality.
Ask for the list of damaged DLLs and their current version number.
3) If he knows what is broken why hasn't he fixed it?
Reinstall is not a fix most times a way to cover incompentence or lack of ability to troubleshoot the root issue.
I spent a day figuring out why a paritcular vendor application was throwing a specific error for a friend for the last month and a half.
The vendors error message reported a failuer but they could not pinpoint the issue.
Here were the things we knew from testing thou.
The front end when savin a large sum of data to a text column would fail.
Restoring the vendor DB to a test server and using the application there for testing would not fail.
Restoring the master from production then to this server would cause the failure.
So they and we knew the answer was tied to master somehow.
Going thru all the settings for user accounts and server configuration turned up no obvious problem but it hit me all of a sudden.
Shortly before the problem becgan they changed from a log shipping replication because of a locking issue to transactional replication.
We then tested on the good working test copy setting up transactional replication and were able to produce the issue exactly.
So we knew the factors were replication and data size to text columns.
The final answer was a simple base configuration that wasn't enforced except when replication is on and that was max text repliaction size of 64k.
We then used sp_configure to set the value to the maximum allowed (these forms in the designer are huge many times but have yet to reach that large) and tested.
This solved the issue in test and was applied to production where things are back to normal now.
So what steps did he follow and how did he come to the determination that it was FireFox which has not relationships to any DLLs that would affect SQL?
I suggest you go thru a bit more of what you said before and see if you can find a beter answer.
1) What version and revision is your SQL Server where this is happening?
2) Check the application log and SQL Server logs to look for a message when SQL stopped to see if the request was intiated normally or did it just drop out of memory.
Also make a note of any error message in any logs that happen between run and failure.
3) Find the Doc Watson memory dumps that should produce when SQL fails and look at them (might need help or have to send to MS to verify what was in memroy and what the crash reported from).
4) If you have a copy of all the software (server and sql) do an install on a clean machine and install FireFox to see if the server runs or fails, you may need to put a load on it. If no failure do and uninstall and reinstall FireFox multiple times and even once while pulling the plug on the system during install and see if that affects SQL.
5) How long between install of FireFox and the first occurrance of the issue actually occurr?
Realize tat once they reimage the server or reinstall anything the root issue will be gone forever and your proof of a half-@$$ job is gone.
Viewing post 16 (of 15 total)
You must be logged in to reply to this topic. Login to reply