Member Avatar for jlivvers

Hi,

I have a windows form application that is designed to monitor payments made within agreed timescales. Once a timescale has passed any payments that are outstanding will get assigned as arrears.

What I need to decide is the best way to handle the task that checks if the due date has passed and then updates the related tables.

I was simply using a timer control to figure out the time of day but realised that there is no garuantee that a user will run the program which would lead to the updates not happening. So i need a way to fire the event whether the user runs the app or not. The app will be deployed to run on a server when complete.

whats the correct way to approach this kind of problem?

  • 2 Contributors
  • 1 Reply
  • 253 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by mcriscolo

Dani AI

Generated

Short, practical guidance to complement ' description and 's two options. An unattended server-side scheduler is required so the UI’s timer is not relied on. Two broad, practical choices are (1) run the work inside the database on a scheduled job, or (2) run an external scheduled process/service that calls the application/business logic. Which to pick depends on complexity, testability and external dependencies.

If the rule is simple and purely data-driven, a database-scheduled job (SQL Agent / stored procedure) is the simplest and most robust: it runs independently, can update in a single atomic statement, and avoids extra infrastructure. Take care to keep logic small and testable, index Status+DueDate, run updates in batches, and record audit rows. Use DB-level advisory locks (for example sp_getapplock in SQL Server) or a “job running” flag to prevent overlap.

If business rules touch external services, use existing application logic: host a small console app/Windows Service, or use a scheduler library (Hangfire, Quartz.NET) or cloud timer functions (Azure Functions TimerTrigger, AWS EventBridge + Lambda). This keeps rules in one place and easier to unit-test. Make the job idempotent (only transition rows whose status still matches the pre-condition), use optimistic checks (rowversion or status WHERE clause), and add retries and monitoring.

Operational checklist: store all timestamps in UTC, schedule at a reasonable cadence (hourly/daily) depending on SLA, process in small batches to avoid long transactions, add alerting for job failures, and include automated tests for the transition logic. Example safe batch update pattern (SQL Server style):

WHILE 1=1
BEGIN
  ;WITH cte AS (
    SELECT TOP (500) PaymentId
    FROM Payments
    WHERE Status <> 'Arrears' AND DueDateUtc < GETUTCDATE()
    ORDER BY DueDateUtc
  )
  UPDATE p
  SET Status = 'Arrears', ArrearDateUtc = GETUTCDATE()
  FROM Payments p
  JOIN cte ON p.PaymentId = cte.PaymentId;

  IF @@ROWCOUNT = 0 BREAK;
END

These practices give reliable, auditable transitions while avoiding duplicate work and large locking windows.

Member Avatar for mcriscolo

Depending on the complexity of the task, I can think of 2 ways off the top of my head:

1) Write a C# process that does your check and updates the required tables (most likely a Windows Console application). Set it up to run on your server as a Windows Scheduled Task, in the interval you need to check.

2) Develop a database procedure (e.g., in SQL Server, a stored procedure) that does your check and update. Set up a scheduled database job that runs your procedure.

Hope this helps!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.