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
Devcon 2020 Goes Virtual! LEARN MORE >

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

How to protect DBF tables?

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
    #1

    How to protect DBF tables?

    Has anyone experienced the sudden corruption of dbf tables?, the field names suddenly became unreadable, it is like an ascii or wingding fonts. Even if I backup everyday, the data being saved on a sales transactions of the day will be lost prior to being corrupted. I followed every precaution about the how to keep the database healthy but still I experience something that is a nightmare to business owners or my customers.
    Tags: None
    #2
    Re: How to protect DBF tables?

    "... lost prior to corruption" ?

    Not sure what you mean. Is the corruption causing the data to be lost, or is it being lost first, and then somehow corrupted?

    Have you been experimenting with encrypted tables?

    Comment

      #3
      Re: How to protect DBF tables?

      Jet,

      Must be something on your machine. Not only is that not normal; I have never heard of anyone having a problem like that.
      Peter
      AlphaBase Solutions, LLC

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

      Comment

        #4
        Re: How to protect DBF tables?

        I have seen this. Packing the tables and compacting the database has always returned the table (s) to original integrity.
        Mike W
        __________________________
        "I rebel in at least small things to express to the world that I have not completely surrendered"

        Comment

          #5
          Re: How to protect DBF tables?

          I have over the years seen the situation (usually from power loss), where dbf tables lost one or two bytes at a random mid point.
          This would apparently trash everything after that point. In that event a pack would be unpredicatable and permanent.
          Browsing the table from the bottom up is recoverable to the corruption, and then top down. export and rejoin, losing one or max two records.

          In this case, it sounds like the header as well is corrupted since "field names suddenly became unreadable, it is like an ascii or wingding "
          Nothing in standard operation could cause any of this - so how often does this occur Jet? More than once?
          Then I would definitely look for hardware, faulty net card or so.
          Only once? try any advice given, Mikes sounds logical, otherwise inevitably a backup recovery.

          Comment

            #6
            Re: How to protect DBF tables?

            Originally posted by JetLi View Post
            Has anyone experienced the sudden corruption of dbf tables?, the field names suddenly became unreadable, it is like an ascii or wingding fonts. Even if I backup everyday, the data being saved on a sales transactions of the day will be lost prior to being corrupted. I followed every precaution about the how to keep the database healthy but still I experience something that is a nightmare to business owners or my customers.
            Corruption (of all sorts) is the enemy of all database environments. Hence, the more important your data becomes, the more obvious it is to spend more time on your backup procedures or development process. The situation where most developers begin is developing on the same machine as the actual production database is on, but then after working hours, which is the most dangerous one as you can imagine. Any damage then automatically leads to data loss or the need for recovery. If you are working on important databases, development should never be done on the production environment. Just running the production already provides enough risks as it is. Really no need to increase on the risk profile by developing on it. Working on important data is all about minimizing risks. The countermeasures to those risks vary in intensity and expense up to full off-site mirroring by means of metro-clustering and snap-mirroring. This is solution-continuity. Whatever goes wrong, your customer can snap-back within seconds, sometimes full automatically.
            The question is then, how much is your data loss costing the client, and how much will the investment to protect your customer from it cost and throw a healthy profit on investment.

            I have seen countless forms of data corruption. Also in Alpha Five databases. In forms, in tables. The question mostly is: how fast can we get back in business, with as less damage as possible. Data corruption is a fact of life. It belongs to automation as daylight to night. You can not hold against Alpha Five that it can suffer from corruption, since this does not even have to be the fault of the software. It can also be caused by a bunch of other things like instant loss of power, magnetic influences, heat or whatever. The question is not "How on earth could this data get corrupted" but "how could I have prevented the damage that resulted from the data corruption". And that takes good organisation, planning, investments and sound thinking. Snapshot technology is nowadays not to expensive and can provide series of backups to fall back to. Keeping your environments separated (development, testing, production) is good thinking.

            Comment

              #7
              Re: How to protect DBF tables?

              Originally posted by Ray in Capetown View Post
              I have over the years seen the situation (usually from power loss), where dbf tables lost one or two bytes at a random mid point.
              This would apparently trash everything after that point. In that event a pack would be unpredicatable and permanent.
              Browsing the table from the bottom up is recoverable to the corruption, and then top down. export and rejoin, losing one or max two records.

              In this case, it sounds like the header as well is corrupted since "field names suddenly became unreadable, it is like an ascii or wingding "
              Nothing in standard operation could cause any of this - so how often does this occur Jet? More than once?
              Then I would definitely look for hardware, faulty net card or so.
              Only once? try any advice given, Mikes sounds logical, otherwise inevitably a backup recovery.
              Thanks,I think you know and experienced what I mean Ray.Definitely no network problem and no power loss because I am using a UPS 30 min, I am running the database on my development machine,and it is freshly installed with windows 7 prof.I am very much worried now.What could be the necessary precaution for us to protect our DBF's. I have encrypted the tables BTW.

              Comment

                #8
                Re: How to protect DBF tables?

                Could be hardware issue, however I would recommend using Cobian Backup version 11, it has the option to use Volume Shadow Copy to backup while working. Backing up while working without VSC may cause some problems, hiberating on windows 7 Pro 64 bits also have given me some problems. Another long term solution is Planning an upgrade to any SQL database should fix any concern about data corruption and frequent re-index issues. I whish A5v11 supported SQLite directly that would be a good DBF replacement without the other SQL server's requierements.

                Comment

                  #9
                  Re: How to protect DBF tables?

                  I second your thoughts on SQLite. That would indeed make for a very good and stable replacement. Re-Indexing in fact can be a much larger problem then the occasional data corruption. I specifically recall one situation in which re-indexing on a super large, high traffic application would be needed almost every day and would cost everyone to sit around for 15-30 minutes. On a daily basis..... that really can be a frustrating and costly issue.

                  Comment

                    #10
                    Re: How to protect DBF tables?

                    I don't think this is the problem, but just to mention there are several files that make up a "DBF Table". One of those files contains the full field name IF the field name is longer than 10 characters. If that file is missing, all field names are truncated to 10 characters. Again, don't think it would 'corrupt', just truncate.
                    Attached Files
                    Steve Wood
                    See my profile on IADN

                    Comment

                      #11
                      Re: How to protect DBF tables?

                      do you have memo fields in any of these files?
                      Cole Custom Programming - Terrell, Texas
                      972 524 8714
                      [email protected]

                      ____________________
                      "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

                      Comment

                        #12
                        Re: How to protect DBF tables?

                        No memo fields. Aside from cobian backup, what are other good live backup of data? will it interfere with network performance when the back up is done on a live basis? as data is added on tables, the backup software is also making increment backups.

                        Comment

                          #13
                          Re: How to protect DBF tables?

                          Hmmmmmmmm - I would turn off the live update for a few days and see how it affects things
                          It is a personal prejudice, but I don't trust incremental backups; and I don't like tape drive backups (they are horribly slow)

                          On my client's servers, we have simple raid, and a box with 7 external drives, one for each day of the week
                          at night an update is made to the appropriate external drive in the box
                          Cole Custom Programming - Terrell, Texas
                          972 524 8714
                          [email protected]

                          ____________________
                          "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

                          Comment

                            #14
                            Re: How to protect DBF tables?

                            Originally posted by JetLi View Post
                            as data is added on tables, the backup software is also making increment backups.
                            I never combine a backup process of data files with any type of data maintenance either process or user oriented. Much too messy.

                            Mostly likely the root of your data corruption.
                            Al Buchholz
                            Bookwood Systems, LTD
                            Weekly QReportBuilder Webinars Thursday 1 pm CST

                            Occam's Razor - KISS
                            Normalize till it hurts - De-normalize till it works.
                            Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                            When we triage a problem it is much easier to read sample systems than to read a mind.
                            "Make it as simple as possible, but not simpler."
                            Albert Einstein

                            http://www.iadn.com/images/media/iadn_member.png

                            Comment

                              #15
                              Re: How to protect DBF tables?

                              All possibilities seem to have been covered here. It could be any of them or indeed a combination. Personally I think it is a data conflict with your backup. I use https://www.livedrive.com "Pro Suite" option for all my PCs - I schedule it to run after 11:00pm on my development PC as I don't feel comfortable with multiple software clients possibly accessing the same files at the same time..,

                              Comment

                              Previous 1 2 template Next
                              Working...
                              X