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

Losing records VERY WORRYING

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

  • Losing records VERY WORRYING

    Hello all

    Searched the board but can't find much on this.

    What's the chances of alpha saving a record and then losing it

    Recently 3 records that my staff assure me were saved have disappeared.

    At first I put it down to human error, now I'm having doubts.

    All records are saved when a receipt gets printed to give to a customer.

    All forms have the delete function disabled.

    When I performed an undelete records, there were no records undeleted

    Any input welcome

    Regards

    John
    Failure makes improvements

  • #2
    Re: Losing records VERY WORRYING

    Hi John,

    Get your staff to show you exactly what they did. Could there be a fiddle going on?

    Check the tables in a default browse to see if the data is really there. Also, check if it is a child table the link has become corrupted.

    And there is always database compact!!
    Regards
    Keith Hubert
    Alpha Guild Member
    London.
    KHDB Management Systems
    Skype = keith.hubert


    For your day-to-day Needs, you Need an Alpha Database!

    Comment


    • #3
      Re: Losing records VERY WORRYING

      John, I agree with Keith. You should carefully study your table to see if the missing records have been saved with an incorrect link field value. Explore the table. Don't use your data entry form.

      Do the missing records involve memo field text?

      Have you considered implementing an audit trail system to automatically and silently track changes to your table?

      -- tom

      Comment


      • #4
        Re: Losing records VERY WORRYING

        Thanks for the responses

        I'll do as you both suggest.

        I don't think its a fiddle because the staff brought it to my attention.

        At first I was convinced that they were not doing things properly (being lazy), they assure me they are going through the proper methods.

        I thought that if alpha saved it it should always be there.

        Tom, no memo fields, I know they can be troublesome so I avoid them.

        John
        Failure makes improvements

        Comment


        • #5
          Re: Losing records VERY WORRYING

          Tom and Keith

          Quick update. Can't find the records in the default browse, however, every record has an auto incremented number and the difference between the last record and a new record is 7 not 1 as I would have expected.

          This makes me wonder are there more records missing?

          Your opinions would be valued.

          John
          Failure makes improvements

          Comment


          • #6
            Re: Losing records VERY WORRYING

            I haven't had alpha lose a record in years and am sure it was my fault then.

            a quick record check back up through the records should tell you if it has been happening in the past with the default browse.

            If the ai is skipping 7 numbers, it means the records were entered and deleted somehow, then packed. My opinion. The Packed part is a sign of fiddling if it really happened.

            My main form has a delete button on it that just hides the record. Anyone deleteing the record, just hides it from themselves. If they later pack the table, nothing gets gone. Just a thought.

            Tom had a great idea to log the moves an employee makes in a record on a save. I have a secured log file and my main tables are also secure by encrytption so another program cannot see what they are and possibly change them.

            Onsave form event:
            Code:
            tbl=table.open("logs",FILE_RW_SHARED)
            tbl.enter_begin()
            tbl.date = date()
            tbl.acct = var->theacct
            tbl.Timing = time("0h:0m:sA")
            tbl.user = var->scode
            tbl.action = "Saved Record "
            tbl.enter_end(.t.)
            table.close()
            Note: If I were fiddling and expected a possible catch could be coming, I would report an error of some kind to cover myself. I sincerely hope this is not the case.

            also, not sure if opening the table with something like access then deleting a record, it would just mark it or totally delete it. Encryption would stop that though.
            Last edited by DaveM; 07-22-2010, 11:36 AM.
            Dave Mason
            dave@aldadesktop.com
            Skype is dave.mason46

            Comment


            • #7
              Re: Losing records VERY WORRYING

              I had a problem like this once and it depended on how the browse was indexed. Indexed one way, some records wouldn't show up. Indexed another, they were all there. Unlike V9, a default browse in V8 can be indexed and stay that way. Just another possible thing to look at.

              Comment


              • #8
                Re: Losing records VERY WORRYING

                I know this is an old thread, but I have this problem in one of my databases too (using version 10.5).
                The users can't show me what they did because this only happens once every few months, apparently at random.
                One record in the main table disappears, but all the child records are still there. I have daily backups so we never really lost a record, but it is worrying.
                When I try undelete, they are not there, but the table has an empty record at the index where the original record should have been - even the auto-incremented ID disappears.
                Delete is disabled in all my forms and browses.
                Last edited by mariusm; 08-29-2013, 07:09 AM. Reason: to add more info
                It is easier to get older than wiser

                Comment


                • #9
                  Re: Losing records VERY WORRYING

                  Marius, perhaps its time to implement an audit trail to capture and store information about all transactions including the unexplained blanking of an existing record. If you are using the available security module you can even record the user's name in the audit trail table. If this is too ambitious for you, consider adding hidden fields that record the user's name and date for any saved changes to a record.

                  By the way, your description suggests that the main table record was not "deleted", just "emptied". If this is being done by disgruntled staff you could block "saves" if certain key fields are blank. Disabling "deletes" does not prevent a person from overwriting field values with blank spaces. Obviously, you'd want to protect the user name and date_changed fields if you choose to add them to your table structure.

                  Other possibilities would revolve around batch update, batch post, or table restore operations. When this next occurs you might want to review any recent batch changes that have occurred preceding the discovery.

                  -- tom

                  Comment


                  • #10
                    Re: Losing records VERY WORRYING

                    An audit trail is a bit of work but I think I'll have to do it. This is a customer with not much money (a charity), so I'm trying to do everything on the cheap.
                    My question is how a user can empty the auto-increment field - it's not editable. Although, that only happened once or twice, usually all other fields are empty except the AI.
                    I think blocking 'saves' if some fields are blank might be the quickest patch-up for now, and then I'll look at an audit trail. Thanks.
                    It is easier to get older than wiser

                    Comment


                    • #11
                      Re: Losing records VERY WORRYING

                      you may also check any sets where the set is based on what would be a child record in the "main" set.

                      In other words, user enters a record from a side form(not the main form) that is based on a different set, then goes back and deletes the child record he put in and the set is built so it deletes the parent which at that point is the child. That would be a form built on a reverse set.

                      There would be no deletion of other child records just the one affected and the child which should be a parent.

                      Make sense?

                      Comment


                      • #12
                        Re: Losing records VERY WORRYING

                        I hate to mention this because I'm such a fan of A5. But yes, it happens. I think it might be a network issue. Something is not being committed or saved properly. Poof--no record. I can't give you much more advice other than watch it very carefully. And backup like there's no tomorrow.

                        Comment


                        • #13
                          Re: Losing records VERY WORRYING

                          Yes, Dennis, that's what I think too. This customer has a mix of older Windows XP computers, and newer ones, and the network is wired through the walls - it's been done many years ago. I suspect some of the wiring may be getting old, or maybe some old NIC is playing up, or something like that.
                          Because the last record we lost was, again, emptied - including the autoincrement ID which users simply can't delete or change. I have delete disabled throughout the database, only me and an administrator can delete records, and there is only one administrator - the business manager. But even he could not empty an autoincrement field and leave a blank record - you need to change the field rules for that. The control panel is hidden, so I can't see how a user could possibly do this. There is no referential integrity in sets, so when a record is lost, at least I still have all the child records.

                          I wonder if switching to mySQL tables would sort this problem, since it uses a different mechanism for comitting / saving / editing.
                          It is easier to get older than wiser

                          Comment


                          • #14
                            Re: Losing records VERY WORRYING

                            I'm using the native DBF structure and not SQL. But still you would think that the app would be robust enough to detect a network error if that's what causing. You be damn sure if you find anything that you let me know. :-)

                            Comment


                            • #15
                              Re: Losing records VERY WORRYING

                              This just a long shot but other programs such as excel can open dbf. In that case the field rules don't apply and the auto increment can be erased. Any chance some other program is interacting with your data?
                              Tim Kiebert
                              Eagle Creek Citrus
                              A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                              Comment

                              Working...
                              X