Results 1 to 3 of 3
  1. #1
    Join Date
    Mar 2010

    Unanswered: Audit Table: Runtime 13 Mismatch

    I'm working to add code I found at A simple solution for tracking changes to Access data to add an audit table to our existing dB. We're trying to add a table or qry that will help us see when data has been changed on any of our tables. I'm new to coding so I'm trying to work though this as best I know how. I followed the example in the sample that comes with Access and it worked fine, but as I followed the instructions adding it to my existing dBase I keep getting a Runtime 13: Mismatch error. I think it has to do with the primary keys but I'm not sure. Can I use multiple Primary Keys as I'm trying to do? My form is built from muliple tables so this audit table may not work as such. Am I wasting my time? Should I look at something else? Any help would be appreciated.

    Private Sub Form_BeforeUpdate(Cancel As Integer)
    Call AuditTrail(Me, TagNoID And CalID And EmplID And ProcedureID And ActualItemID)
    End Sub

  2. #2
    Join Date
    Nov 2004
    out on a limb
    Provided Answers: 59
    well as you haven't supplied the code you've used, I'd suggest you go aback to techrepublic and ask them for support.

    however a type mismatch usually means that you are supplying the incorrect datatype to the query, often it means you are supplying alpha to a numeric column, or haven't enclosed text with a ' or ", or possibly there is a ' or " in your text values that is causing the problem.

    for an audit trail usually all you need to know is the data that has changed and soemething that uniquely identifies that row and that means the primary key
    trying to record changes to multiple tables at the same time is asking for trouble in my books.

    histroically I've used a 3 column table for an audit trail
    EventID - system generated ID
    computerID -using Dev Ashish's API call, replciated in the code bank as PKStormy's
    userid -using Dev Ashish's API call, replciated in the code bank as PKStormy's
    EventTime - the timestamp the event took place
    SQL - the SQL that encapsulates the audit event. eg update mytable set thiscolumn=99901, thatcoolumn="blah di blah" where aprimarykey=1234 .......and so on

    this means I not only have an audit trail that is machine and human readable, its searchable and if needs be we can roll back/forward changes as required should the db get corrupted

    the comptuerID, userID and event time are all important as it allows you to use this sort of data as a disciplinary if required, or better yet actaully know who is doing the dirty deed. its a bit like playing Cluedo but you know the cards in the envelope from day one, there's no more "I think it was Professor Plum with the lead piping..." its I know it was sGordon, on compuyer xyz on dd/mmm/yyyy at hh:mm:ss" that did the dirty deed.

    if you do use your audit file as a tool for disciplinary then you need to think about security of that file, who can make changes (if any) who can delete, who can access and so on.we have used the audit filr to successfully track down mysterious system faults changes that everyone denied they did.
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Mar 2010
    Thanks healdem, I appoligize for not including the code, I'm rather new to forums so I wasn't sure how much to post. I have contacted techrepublic but they have yet to get back with me, a buddy said this site was much better about getting answers. I'll take your advise and see what we can do. Thanks -SG

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts