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

Memo field and Global Update

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

    Memo field and Global Update

    Hi,

    We just found out that there's corruption affecting the memo field of one of our tables. The memos are out of sync with the dbf.

    For example, if you look at record #1500, the memo shows what belongs really to record #1502. Just so you know, not all the memo's are off by a few records, so it varies.

    I found an old backup that has memos that appear to be correct.

    I tried creating a set with both tables and update the new table's Memo field with the contents of the old table's memo field, but I get the following message when I hit <F10> to continue on the global update:

    "Equation type must be same as field type"

    Am I hitting another limitation in Alpha4 or is there a way to update the new table's memo field with the contents of the old table's memo field?

    Please help!!!!

    Thanks!

    Alex

    #2
    Re: Memo field and Global Update

    Alex

    Memo corruption is solved by a few methods. Most are not easy..

    1. Go to a backup prior to the corruption.
    2. Get a tool to fix it. One that I've used is Dsalvage.
    3. Delete the memo field, add the memo field back in and rekey all the data...

    Hope That Helps
    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


      #3
      Re: Memo field and Global Update

      Hello,

      If you're desperate and are willing to do some hacking and you know that the memo fields are NOT being updated often, you might experiment with the following. Of course, use all proper precautions not to lose live data. Results of this technique will vary greatly depending on the manner in which the memos have been updated since the last backup--but you may get lucky.

      Copy only the afflicted database's .DBF file to a temporary folder, then copy a *backup* copy of the database's .DBT to the same folder.

      Open the database. Do not index.

      Examine the records to see if they make sense.

      If the results are satisfactory, use A4 to copy all records to a new database in the temporary folder.

      The new database .DBF/.DBF pair may then work if used to replace the afflicted database pair. You may have to reindex after such a replacement.

      Hope this helps.

      -moy

      Comment


        #4
        Re: Memo field and Global Update

        Hi Al,

        Not a lot of fun to rekey data for up to 600,000 records, so this isn't really a feasible solution. Thanks for suggesting dSalvage, though.

        Alex

        Comment


          #5
          Re: Memo field and Global Update

          Hi Moy,

          The memo fields are updated constantly (this is a very active database).

          Your idea seems sound except that if they packed the database between the time the backup was created and today (very very very likely) the memo fields will be out of sync when I open the new dbf with the old dbt.

          I have come up with another alternative that might work.

          Since I can't update the memo fields in the damaged database with those in the backup, I've decided to try to work WITH alpha4 and bend to its will.

          I will create a set relating the backup to the current table and update the backup with all the fields EXCEPT the backup (which Alpha4 doesn't allow), and then append the new records, thus creating a new table where the memo fields are all in sync.

          As soon as I get my client's blessing I'll get to it.

          Thanks!

          Alex


          Originally posted by moy View Post
          Hello,

          If you're desperate and are willing to do some hacking and you know that the memo fields are NOT being updated often, you might experiment with the following. Of course, use all proper precautions not to lose live data. Results of this technique will vary greatly depending on the manner in which the memos have been updated since the last backup--but you may get lucky.

          Copy only the afflicted database's .DBF file to a temporary folder, then copy a *backup* copy of the database's .DBT to the same folder.

          Open the database. Do not index.

          Examine the records to see if they make sense.

          If the results are satisfactory, use A4 to copy all records to a new database in the temporary folder.

          The new database .DBF/.DBF pair may then work if used to replace the afflicted database pair. You may have to reindex after such a replacement.

          Hope this helps.

          -moy

          Comment


            #6
            Re: Memo field and Global Update

            Hello Alex,

            Yes, a database that is "packed" often may goof up your data recovery efforts.

            However, if I recall correctly, "pack" simply removes records from the .DBF that are marked as "deleted," then updates the attached indexes. I can't remember WHAT, if anything, "pack" does to the .DBT portion of the .DBF/.DBT pair. Since a memo "field" is simply a pointer into the .DBT, there *still* might be the possibility that the memos themselves are largely intact.

            The challenge is then to populate the .DBF with the correct pointers into the .DBT, whether you go with the current .DBT or a .DBT restored from a backup.

            To avoid exactly this kind of corruption, I don't often use memo fields in my databases, except as a sort of dumping ground for *very* non-mission-critical text. Instead of a memo field, I tend to use (1) one really long character field, (2) a record id key to link to a second database that has several Really Long Character Fields, or (3) a script to shell to DOS and spawn a text editor that edits a text file with the record key's name.

            I had even toyed with the idea of having a script automatically insert the record key somewhere into the memo (for recovery purposes), but this just seemed too flaky and easy to break.

            On a related note, I once devised a technique for reading ALL the memo field data from a .DBT (including edited or deleted ones). Perhaps a variation of this method might prove useful for reconnecting the .DBF records to the "lost" .DBT memo data. The concept went something like this (pardon my rusty memory):

            Use A4 to create a dummy database with two, 10-character fields

            populate database with lots of records

            the first record should contain "1" in both fields, the second record contains two "2" etc.

            Close A4

            in DOS, copy .DBT file to same folder as the dummy database you just created

            rename .DBT file name to match .DBF file name

            use a hex editor to change the flag byte in the .DBF header that indicates a .DBT is attached (I can look up this info later). Edit the second character field's type to indicate memo.

            Launch A4 and open database again--you may need to reformat the browse or form to display the memo properly. You should be able to view memos in the order in which they were saved.

            Whew! That was a mouthful and I am sure I have missed something, but what I do remember is that I was able to successfully prove this concept with test databases. So something like this can be used to convert the problem to one of re-keying *pointers* instead of re-keying *memos," however impractical either method is.

            Good luck with all your efforts!

            -moy

            Comment

            Working...
            X