views:

135

answers:

7

I have a table, tblClient, which stored a client's date of birth in a field of type datetime, DOB.

The goal here is that, when a client reaches 65 years old (need to be calculated thru DOB), I need to insert a new record into another table.

But since the age of a client does not change due to a database transaction (INSERT,UPDATE,DELETE), trigger is out of question.

What would be a good idea to montior such changes?

+2  A: 

create a sql agent job that runs daily or hourly that will do this calculation with T-SQL and then if someone reaches 65 it will do the insert

SQLMenace
+1  A: 

A scheduled task or SQL Server maintenance plan that runs a stored procedure as often as required, updating the required rows.

Joe Koberg
+1  A: 

What about a nightly job using SSIS with a stored procedure that checks and if it happens that they are 65 it enters a new row in the table?

Bmw
why SSIS when you can use T-SQL from a SQL Agent job?
SQLMenace
@SQLMenace - is there a difference which scheduling service one uses?
DVK
if you use SSIS now you also need to deploy the package and for all we know he isn't even using SSIS
SQLMenace
+2  A: 

Keep it as self-contained to SQL Server as possible - a SQL Server Agent job that periodically executes a stored procedure should do nicely.

Ian Nelson
+1  A: 

you can create a SQL Server Agent Job within the database using SQL Server Management Studio for this:

http://www.databasedesign-resource.com/sql-server-jobs.html

Set up a daily job to EXEC BirthdayProcessingProcedure or whatever you want to name it.

As long as the database is up and running, the JOB will run according to the schedule you set up (from within the database).

KM
+1  A: 

I'm going to propose another approach - run something every time a DOB is updated (or added) that calculates the period from now until the first person reaches 65. Then (re-)schedule a job to run at that time.

Also, I can't believe you need to insert that row the second they reach 65, so a once-a-day procedure that calculates today's new 65year olds would seem good enough?

Paul
Running daily sounds reasonable enough now I think about it... thanks Paul,
Sung Meister
+1  A: 

How about a new field that is age65 date. Calculate it once on record insert, then you can query to your hearts content on this field. You will need to do this is a trigger (and account for updates, they are rare for DOB fields but possible when they are mistyped.) Now that I think about it some, a calculted filed will probably work instead of a trigger.

Then run a daily job to catch anyone who turned 65 since the last time the job was run successfully. Make sure to handle this so that if the job fails one day, the people from that daty are picked up the next run.

The reason why I suggest this is that calculating the age of every person inyour database every day is such a waste of resources for a calculation that really only needs to be done once. Ok not a big deal when you have 100 people, big problem when you have a million. Doindthis kindof calc on a million records to identify the three you need is painful. Doing it once on data entry, not so bad.

HLGEM
Not sure I see the difference between calculating a date 65 years ago from today once a day/night and then query any DOB's equal to that date or your suggestion of: age65date = getdate() ? Indexing DOB all the better.
Jeff O
the differnce is between performing a calculation once on insert and doing it daily (when the thedate the person wil turn 65 is not a changing number in general) especially over a large dataset. It is not efficient to do calculations like this repeately when they are not bnecessary. Why waste server resources doing the same work over and over every day?
HLGEM