We received this attached error on our intranet when we try and open a specific application.This problem occurs randomly.It has gotten worse the last few weeks where we actually have to restart the server for the application to open.I can't restart the server every day!
The two scenarios that i think is possibly causing this could be
:
1) The software installed by a third party company (This Web Based Employee clocking system) is causing issues with the ISS and ASP.net because of bugs in their software.2 months previously after they "fixed" an asp.net and IIS issue onsite on our premises everything was working fine until about a month ago when this error (attached) started popping up again .
2) Problem on our network or server but then other sections of the nework would also be slow?
if that is this clocking system then you need to ask them to have a look at this and change timeout settings I would say.
ingriT
Is the database server the same as the webserver? It could be a SQL query is creating a lock, or a SQL query is just very slow.
You could profile your SQL Database to see what's going on there. It could also be another database on the same server creating performance issues on this server.
The_Nibbler
ASKER
Att: ingriT.
Yes the database server,Mail server is all on one server.
Haven't used SQL Profiler before so i'll see if i can make sense of this built-in function within SQL Server 2008.
I've attached another screen which within SQL Server when trying to delete a row within a view in this specific Webregister db.Even creating a table within this db is giving this error.
Yes,it looks like the Logfile is causing the issue.I see the people who installed this third party software set the db + logfile to autogrowth by 10% in SQL Server which is not recommended by a lot of users on the internet.The actual size of these files in the relevant folder under Program Files is higher than the specified space reserved for space.
We do not have a development server,everything is life.
Can i change the the size properties for this db to a higher value and then run one of the above scripts in our production server.Is this to risky though or not really?
I'll do the backup now.I'm not going to shrink the db but rather increase the space because we do have the space available
ingriT
Oké, that is an even better solution :)
But do keep in mind, that it will fill up some day, maybe set an alert in SQL if that is possible, or set autoshrink (see the previous link) on it at some point.
if that is this clocking system then you need to ask them to have a look at this and change timeout settings I would say.