This can be due to a number of reasons, but there are some things you can try. Try running the following command:
RESTORE DATABASE <database name> WITH RECOVERY
If that doesn't do it, you can try deleting the database and restore it again.
I think i can tell you exactly what the issue is,
I spent over 48 hours trying to sort this. didnt find anything on the net. also happen to be with 1and1
look at these settings:
IP security policies.....
which opens box...............Packet Filter Properties
near the bottom of the list there is a box ticked called :
'Close MSDE (TCP/UDP)' (I am asuming that MSDE = Microsoft SQL Database Engine?)
Select it
Press Edit...
which opens box............... Edit Rule Properties
Select (again) >> 'Close MSDE (TCP/UDP)'
Press Edit...
which opens box................IP filter List
then you will see a list of ports tcp 1433, udp 1434
{Thats our list of ports all down as a blocking rule.....}
I think what needs to be done from here is
either....
close that screen ..IP filter List
on the screen Edit Rule Properties
there is a tab Filter action, could just change that from Block to permit?
(maybe changing it to permit, will allow us to tick the "Block All" option again - which sounds safer, but the support guys said there is a know bug, so might not work)
or
on the Packet Filter Properties
just untick the the rule 'Close MSDE (TCP/UDP)'
you might have to untick the rule 'Block ALL' to get it running
its probably to late for this to help you, but hopefully will help someone else with the same issue.
Best Answer
The only way to do this is by having set up some form of monitoring process prior to (and during) the operation. E.g. the Profiler tool allows you to log the duration of (and any statements, but not results) of any batch, or you could issue a
SELECTorPRINTshowing the results ofgetdate()prior to, and after, the statement.With modification operations like a
DELETE, there will be a record in the transaction log (assuming it hasn't been truncated since, with a log backup or a checkpoint in simple recovery mode), but mere mortals can't inspect the transaction log with built-in tools. Third-party log inspectors are available though, but the transaction log shows the time an operation occurred, it doesn't contain information about its duration :)I realise that this is shutting the gate after the horse is bolted, but there's no built-in record of things like this that will survive a reboot, sorry!