Perhaps a security issue of sqlagent. What is its windowsaccount? Local machine, ...

Is the update being done with .Update (can be slow) or with an update-sql statement?

Adding some code to quickly scroll to the bottom and back up?

It is affected by the number of records.

Do you have a covering index on (stime,savg) to avoid bookmark lookups?

High CPU/memory usage can also be caused by massive full table scans.

SP4:

+bugfixes

http://support.microsoft.com/kb/888799

+better corruption/blocking detection

-has an intial bug with AWE (additional hotfixes needed)

-changes index seeks (needs exact typing char(20)vs char(20) etc, to eliminate some false results)

There is also a cumulative post SP4...

the tables"inserted" and "deleted" only exist inside the trigger.

Your code seems to work correctly.

I've tested your code (in tempdb) with

DECLARE @ProjectID int

DECLARE @TimeEntryStart datetime

DECLARE @TimeEntryEnd datetime

DECLARE @TimeEntryUserID int

SET @ProjectID=35

SET @TimeEntryStart=convert(datetime,'2008-04-14 02:30:00.000')/*RETURNS 1*/

SET @TimeEntryStart=getdate()/*returns NULL*/

SET @TimeEntryEnd=NULL

SET @TimeEntryUserID=1035

SELECT [tempdb].[dbo].[f_TimeEntryOverlap]

(@ProjectID, @TimeEntryStart,...

I guess so. You can find sp_who2 in the master database and it is marked as system.

try Me.TabControlRiskForm.Pages(1).enabled = false

instead of

Me.TabControlRiskForm.Pages(1).Locked = True

The stored procedure calls another package?

Have you added some debugging routines in the package to see if it actually executes?

I would create a small program outside of sql server that does this. (datasets in .NET?)

You could also try to store the outputs in temporary tables.

For text-files you might consider...

With the stored procedure sp_who2 you can see which connection is blocked by another connection. Then you could kill the offending connection (beware of the rollback).

Current locks: sp_lock

It might be solved by increasing the mem to leave area to 512mb instead of the default 128mb.

-g 512

Usually the recovery time is less than 1 minute, undo operations excluded.

Are there any long running transactions on the database?