Actuarial Outpost
 
Go Back   Actuarial Outpost > Actuarial Discussion Forum > Software & Technology
FlashChat Actuarial Discussion Preliminary Exams CAS/SOA Exams Cyberchat Around the World Suggestions



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 12-07-2018, 12:13 AM
Fish Actuary's Avatar
Fish Actuary Fish Actuary is offline
Member
Non-Actuary
 
Join Date: Jun 2006
Location: Australia
Posts: 11,322
Default Database log file?

I'm not much of a database person, so perhaps these are some really dumb questions...

At work, we have an Access database that has multiple people entering data into it (which seems like really bad practice to me, and worries me a lot...). Is there some way of automatically logging who's changed what recently?

If this functionality doesn't exist in Access, does it perhaps exist in a different database program?

Is there some way of semi-automatically <not sure if this is the right way of calling it> maintaining the data in two separate states. Basically, older entries that have passed a QA/QC process and newer entries that still need to undergo a QA/QC process?
Reply With Quote
  #2  
Old 12-07-2018, 12:20 AM
Colonel Smoothie's Avatar
Colonel Smoothie Colonel Smoothie is offline
Member
CAS
 
Join Date: Sep 2010
College: Jamba Juice University
Favorite beer: AO Amber Ale
Posts: 48,109
Default

I can't say for access but real databases like sql server ought to have the feature. As for QA you might want to create a separate table that contains QA checks as a transaction. You can join the main table to it to check which entries have undergone a check.
__________________
Recommended Readings for the EL Actuary || Recommended Readings for the EB Actuary

Quote:
Originally Posted by Wigmeister General View Post
Don't you even think about sending me your resume. I'll turn it into an origami boulder and return it to you.
Reply With Quote
  #3  
Old 12-07-2018, 12:32 PM
oedipus rex's Avatar
oedipus rex oedipus rex is offline
Member
SOA AAA
 
Join Date: Nov 2002
Favorite beer: too many to list here
Posts: 15,355
Default

if you are that worried about access control to this data, you should probably discuss with IT what can be done to maintain data integrity and design a robust solution for this data. this way they can also put some controls around the process, which really is required if you read the data quality asop closely. alternatively you can make the database read only and password protect it, that way if someone needs to make a change they need to go through you first.
__________________
Life can only be understood backwards; but it must be lived forwards. --S.K.
Reply With Quote
  #4  
Old 12-07-2018, 05:20 PM
Fish Actuary's Avatar
Fish Actuary Fish Actuary is offline
Member
Non-Actuary
 
Join Date: Jun 2006
Location: Australia
Posts: 11,322
Default

Quote:
Originally Posted by oedipus rex View Post
if you are that worried about access control to this data, you should probably discuss with IT what can be done to maintain data integrity and design a robust solution for this data. this way they can also put some controls around the process, which really is required if you read the data quality asop closely. alternatively you can make the database read only and password protect it, that way if someone needs to make a change they need to go through you first.
The problem is we have multiple groups of technicians entering data directly through various forms and then other technicians updating fields as they complete various tasks.

On top of that we're currently going through some staff turnover at the moment for a few different reasons including the person who was up until recently in overall charge of our group and who may or may not return to the position (some health issues). I'm a bit worried about people maliciously trying to damage the database, but am also worried about inadvertent errors given that I've already identified numerous errors.

I'm not familiar with the data quality asop, but note that this isn't actuarial work. Do you have a link? It could be useful reading. If I end up getting control of the database I may look at the SQL server option. We're having some broader division wide discussions about data management and software/code migrations as our SAS users are rapidly retiring and the new hires are more R or python users. It may be that I can push to a broader shift to SQL server...
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -4. The time now is 12:01 PM.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
*PLEASE NOTE: Posts are not checked for accuracy, and do not
represent the views of the Actuarial Outpost or its sponsors.
Page generated in 0.11683 seconds with 9 queries