Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / March 2005

Tip: Looking for answers? Try searching our database.

Storing updates?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
dd_bdlm@yahoo.co.uk - 31 Mar 2005 14:20 GMT
Hi all

I have a database that stores customer records and their associated
insurance details. I need to be able to track any changes made to that
record within a set time period ie if details are changed fine it is
reported next time report is run. But if details are changed more than
once in between reports then first detail change is lost.

I would like to work out a way that changes can be written to a
??seperate version of the table?? and stored in there to be reported
seperately and not just the final change as is the snapshot nature of a
report? Is this possible? Could I possible make another version of the
main table appended onto it? I feel I 'know' what I need to do but not
how to even begin it! Any help would be appreciated.

DDiver
Alan Webb - 31 Mar 2005 15:19 GMT
One of Ralph Kimball's books, The Data Warehouse Toolkit, has a reference
design for a data warehouse for an insurance company.  The schema given in
this book will do exactly what you want.  The book is $30.00 US or so and
well worth the money.  The schema may have been published by Kimball in an
article on the web but I don't have a URL for you.

Signature

Alan Webb
knoNOgeek@SPAMhotmail.com
"It's not IT, it's IS

> Hi all
>
[quoted text clipped - 12 lines]
>
> DDiver
pietlinden@hotmail.com - 31 Mar 2005 17:15 GMT
There's even a new version out... I have the old one... trudging my way
through it...  was supposed to take a class in it for my duhgree, but
I'm told the class was "probably the worst one I've had here" by one of
my classmates.  (And why do we pay tuition again?)
Alan Webb - 31 Mar 2005 19:47 GMT
Peit Linden,
We pay tuition so we can get the books and hear from the professors the
orthodox way to do things.  The demands of our clients and the realities of
business requirements often mean that the orthodox way isn't what we end up
doing.  But it's a lot worse to flounder through a project thinking our
problems are new and unique than to study what is already known and decide
to flounder through anyway.
Signature

Alan Webb
knoNOgeek@SPAMhotmail.com
"It's not IT, it's IS

> (And why do we pay tuition again?)
MGFoster - 31 Mar 2005 18:21 GMT
How is your db set up?  Do you have more than one table?  It sounds like
you'd, at least, need a Personnel table to hold the demographic info
about customers (name, address, DOB, etc.), and a table of their
insurance contracts.  E.g.:

CREATE TABLE Contracts (
  person_id int not null references Personnel ,
  contract_type int not null references ContractTypes ,
  start_date datetime not null ,
  end_date datetime null , -- null means still active
  -- other columns
  CONSTRAINT PK_Contracts
    PRIMARY KEY (person_id, contract_type, start_date)
)

The Contracts table has a start_date & end_date, this will allow you to
make a history of the person's contracts.  If you need to track
something else about a specific contract you can create another table
that has that info w/ start/end dates.  That table would be a history of
changes to contracts.

Obviously, you can keep on creating tables as your specifications become
more particular.  Read a good book on database design.  I usually
recommend _Database Design for Mere Mortals_, by Hernandez.

Signature

MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

> Hi all
>
[quoted text clipped - 10 lines]
> main table appended onto it? I feel I 'know' what I need to do but not
> how to even begin it! Any help would be appreciated.
Jerry Porter - 31 Mar 2005 19:01 GMT
Here's what I did in one of my applications:

1. I created a copy of each table that I wanted to track, with an extra
date/time field called DateModified. I prefixed these tables' names
with hst, so the archive table for tblClients would be hstClients. You
do need a system to make sure the table definitions say up-to-date.

2. I created a procedure like the following to archive the new version
of a changed record in a form:

 Public Sub ArchiveRecord(fForm As Form, HistTable as string)
   Dim rForm As Recordset, rHist As DAO.Recordset
   Dim fld As Field
 On Error GoTo ErrHandler

   '   Copy new data to history table
   Set rForm = fForm.RecordsetClone
   If rForm.RecordCount <> 0 Then
      rForm.Bookmark = fForm.Bookmark    'find record shown in form
      Set rHist = AdminDB.OpenRecordset(HistTable)

      rHist.AddNew
      '   Use history table for reference of which fields to use,
      '   since form might be based on query
      For Each fld In rHist.Fields
          fld = rForm.Fields(fld.Name)
      Next
      rHist.Update
   End If
 ExitLabel:
 On Error Resume Next
   rHist.Close
   rForm.Close
   Set rHist = Nothing
   Set rForm = Nothing

   Exit Sub

ErrHandler:
'    <error handling code here>
   Resume ExitLabel
End Sub

3. In the after update of the form (e.g. for the table tblClients):
   ArchiveRecord Me, "hstRatesGeneral"

If I were to write this today, I might generate and execute a SQL
statement, instead of using the AddNew method. But this works fine.

Jerry
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.