Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

History Table...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    History Table...

    Hi All...

    Ok History Table might not be a great name but this is what I'm looking to do and I could use some guidance please.

    I have a two tables:
    1. Inusred
    2. Brokerage

    For both of these tables I have two History tables:

    1. Insured_History
    2. Brokerage_History

    For any change that is made to any record for both of those tables I need to maintain a copy of what the original value was. For example:

    Jane Doe Company
    123 Street
    Some City, NY 11111

    Changes to

    Jane Doe Company
    ABC Street
    Some City, NY 11111

    The history table should save the original value prior to committing the change. If something changes again at a later point that change should be saved as well. Over the life of an account we should be able to see what changes were made to the insured information.

    The data will be entered and updated via a grid that I have put together. Should the history table be populated via the grid on an Update command or should it be updated at the table level using field rules?

    The same function is needed for the Brokerage table.

    I've uploaded the app if that helps. Thank you in advance for any ideas/advice you can provide.

    Thanks
    Joe
    Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

    #2
    Re: History Table...

    Search the Code Archive for "audit" to find a great utility for this. It goes in Field Rules.

    Suddenly I cannot recall if this works for Web - anyone remember?
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Re: History Table...

      Hi Steve...

      Thanks for the reply...I've tried things in the past and field rules never seem to work for me on a grid. I'm pretty new to alpha so I've always assumed it was me. Now that you say that you can't remember if field rules work on the web it makes me think that they don't. Can anyone confirm?

      Thanks
      Joe
      Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

      Comment


        #4
        Re: History Table...

        Originally posted by cavj1 View Post
        Now that you say that you can't remember if field rules work on the web it makes me think that they don't.
        In v9 and previous, only engine level field rules work. i.e. autoincrement & calculated field rules work. The rest do not.

        In v10, there is a checkbox option to use dbf field rules. But again, not all the field rules will work. Certainly anything that is UI level will not work. At the conference Selwyn said he wasn't sure which field rules worked or didn't. He said we would have to experiment.
        Peter
        AlphaBase Solutions, LLC

        [email protected]
        https://www.alphabasesolutions.com


        Comment


          #5
          Re: History Table...

          I found one of my apps with this audit code, and it does not work from the web. Thinking about it, it should not work because it is designed to take a snapshot of the FORM as it is being saved. The GUI form is not the same as the web form.
          Steve Wood
          See my profile on IADN

          Comment


            #6
            Re: History Table...

            If you are using MySQL for a backend, then you can create a "before insert" trigger to make the copy. That is a quick and easy solution.

            In dbf, I think you will have to use the canSaveRecord event to open the history table and write the code field by field to the table.

            Depending on who is doing the entry, you can also try a simpler way of asking the user to enter in a text field what the change was. Trouble with that is, unless you monitor it, users will often skip it.

            Pat
            Pat Bremkamp
            MindKicks Consulting

            Comment


              #7
              Re: History Table...

              Hi Guys...

              Thanks for the replies...sorry but no MySql...wish I was but I don't know it well enough to mount the task of learning MySql and Alpha at the same time.

              The current system is an old Access db (10+yrs. old) and is only 98mgs. Given the size and growth for 10yrs with no archiving I think dbf tables should be sufficient for the app.

              I thought about the user method but I can guarantee they will skip it. My users are reeeeaaallllly lazy to the point that they complained that they had to type 08/01/2009 for date format instead of 8/1/2009. Those extra zero's are going to give them callus's on their fingers...lol.

              I'm assuming I need to figure this out on the Events section of the Grid since I cannot use the field rules and such...

              Joe
              Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

              Comment


                #8
                Re: History Table...

                Ok...so you'll have to excuse my lack of programming knowledge, please bear with me. I've read through a bunch of help files etc. and I believe on the grid I want to use the event CanUpdateRecord as it fires before the grid updates an existing record and only fires if the record is dirty. This would prevent a record that was viewed, click save, but nothing changed from getting written to my history table. Correct?

                So here's where I admittedly know nothing...

                Since I need to reference the value of the field on the grid I did the following:

                function CanUpdateRecord as v (DataSubmitted as P, Args as p, PageVariables as p, Result as p )
                with PageVariables
                Result.Cancel = .f.
                Args.DataSubmitted.R1.Insured_company
                Args.DataSubmitted.R1.Insured_address1
                Args.DataSubmitted.R1.Insured_address2
                Args.DataSubmitted.R1.Insured_city
                Args.DataSubmitted.R1.Insured_state
                Args.DataSubmitted.R1.Insured_zip
                Args.DataSubmitted.R1.Insured_phone
                Args.DataSubmitted.R1.Insured_fax
                Args.DataSubmitted.R1.Insured_email
                Args.DataSubmitted.R1.Insured_website

                Result.ErrorHTML = ""
                end with
                end function

                I assume since I've referenced that data it committed to memory? Then need to pass it to the Insured_History table before committing it to the Insured table?

                Thx
                Joe
                Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

                Comment


                  #9
                  Re: History Table...

                  Hi Joe
                  I am also new to A5 but I think you can only do this from a dialog in the AfterValidate event with code that looks more like:

                  ts = table.open("[pathalias.adb_path]\t_students.dbf")
                  ts.enter_begin()
                  ts.Stu_id=CurrentForm.Controls.StudentID.value
                  ts.Lastname=CurrentForm.Controls.Lname.value
                  ts.enter_end(.t.)
                  ts.close()

                  Maybe in V10 it can be done from a grid but I'm not seeing how it can be done in V9.

                  Again, I'm no expert, just trying to help out. Any of the experts here, is that about right? or am I in for a nice surprise and it can be done? (Here's hoping :))

                  -John

                  Comment


                    #10
                    Re: History Table...

                    ooh good, I just learned something. I see now where the CanUpdateRecord is. I think my eyes were filtering out the words "Events". Cool. Glad I read this thread!

                    Comment


                      #11
                      Re: History Table...

                      As a general rule, I tend to favor Dialogs over Grids when the logic or processing gets thick. In a dialog you could easily capture the key value of the record they wanted to change, throw it to a history file as the BEFORE record, then save the new record to both the original table, and the history table as the AFTER value. Dialog appears to be more difficult because you have to code everything, nothing is given. The grid is married to the table and performs all of that save-update-delete code for you. But the trade off is that is a bit more confusing if you need to do anything real fancy. Doesn't mean you can't do it, but I think it is easier to comprehend and debug when it is in a dialog event.

                      <<Since I need to reference the value of the field on the grid I did the following:>>

                      That doesn't put anything in memory or allow you to reference those values outside of right where the statement is made.

                      Session.myvar= Args.DataSubmitted.R1.Insured_company would commit that value to 'memory' (not really memory) and make the value available throughout your system. But if you are saving dozens of values to memory you are probably not designing your application in the best way (IMO).
                      Steve Wood
                      See my profile on IADN

                      Comment


                        #12
                        Re: History Table...

                        Thx guys...I'll give the Dialog a shot...I have a dialog in the posted project but I ran into a problem that I haven't been able to solve with it so I sort of abandoned it for now. It gives me an error when selecting multiple values from a drop down list and I cannot figure out why. I've found other posts with the same problem but no answer. Stay tuned...we'll see if I bomb out again.

                        Joe
                        Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

                        Comment


                          #13
                          Re: History Table...

                          Ok...I created a Dialog and I modified my Grid. What I was trying to do was leave the grid for search and select(link)...the link would pop up the dialog with the fields filled for editing. On a link from grid to grid I can choose the Is linked field but from Grid to Dialog it doesn't show the Is Linked option. Am I doing something wrong or is this by default?

                          Still seems on that their is not simple way to copy the data from one table to another on the CanUpdateRecord event. The event only triggers if something was changed on the grid.

                          CanUpdateRecord:

                          This event fires before an update is made to an existing record. It allows you to abort the update if certain conditions have not been met. Note that the event only fires if the row is dirty. i.e. the user has made at least one change to a field in the row.

                          Thanks
                          Joe
                          Never take a ride to the edge of your mind unless you've got a ticket back - Jon Oliva - Savatage.

                          Comment

                          Working...
                          X