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

Why do records get lost or changed?

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

    Why do records get lost or changed?

    I have designed an Alpha 4.5 database for a camp. The main table of the database is where the camp intake dept. enters all of the camper information from their application. Once the camper has been accepted, they use a set I developed to bring in the camper's information, then assign them a camp session. There are three tables involved... 1)Camper data... 2)Session Data.... and 3)Session Dates. In the set, SESSION DATA is the parent table. CAMPER DATA is a one-to-many link child table with "prevent changes" that links on a camper ID number which is auto-increment and unique. SESSIONS DATES is a one-to-one link.

    Here's the problem. The client is calling me often with small problems. 1) A camper will just disappear from the session data after being entered. Usually when I follow up the camper's number will have been replaced by another's. This was happening before and someone suggested changing my one-to-one link to a one-to-many link and still the same result.

    Second, Sometimes the auto-increment feature on the CAMPER DATA table for the camper ID does not work. One day it got stuck on a certain number and would not continue til they shut everything down and restarted.

    As a final note, you should know that it is running on a network with an NT Server and Win98 workstations. They have as many as three people at a time entering data into the CAMPER DATA section. Could there be issues here?

    Any help you could offer would be very much appreciated. I have tried to resolve this problem and seem to get nowhere. Thanks in advance for any help you can offer.

    #2
    RE: Why do records get lost or changed?

    I have a POS Application where my primary Link field is an Auto increment field. Remember when you press "New Record", Alpha assigns the number from the latest record that is in the table + 1 as the "Potential new Auto increm. Value", when you save the record, it then becomes the "Actual new Auto. Increm. Value". On a network, you have to be smarter than the average Bear when multiple work stations can be entering new records.

    Here is a suggestion you can try. On your Main Menu you probably have a selection "Create new Happy Camper". When you press this button, immediately, create the new record which will contain the Auto. Increm field (plus anything else needed, such as Curr. Date, etc. Then save the record number and call in the "New Happy Camper" form displaying the information from the record you just created (probably the Auto. increm number and "date entered") and the operator can then fill in the remaining data.

    Otherwise it is very likely if you and I both press new record at the (almost) same time, we could both see the exact same "Potential new Auto. Increm. Value". Whoever saves the record first is the winner. The loser gets the next number.

    You can test this yourself by calling in the "New Happy Camper" form -press new record and look at the auto increm number, then minimize that form and call in another instance of the form, press new record and see what auto. increm number it shows.

    -Barry

    Comment


      #3
      RE: Why do records get lost or changed?

      Brett, it's not possible to offer specific advice without being able to see the application.

      If data entry is occuring within the context of a set, only the parent table should be assigning unique camper numbers using the autoincrement field rule. In all probability that field should be used to link to the child table records.

      If you also have an autoincrement field rule active in a related child table that rule will determine the next camper number based on the last record added to the child table, instead of the last number added to the parent table. It's better to let the set assign the parent's camper number to each new child record. Otherwise, as new child records are added, they get different camper numbers and the link to the parent record is lost immediately. In my work here for the link field in related child tables I set 'skip' true so the user can't edit it, also. However, I'm careful not to have two separate autoincrement field rules active (one for parent table of the set, and a second for the child table of the set)... that way leads to madness.

      Comment


        #4
        RE: Why do records get lost or changed?

        To expand on Tom and Barry's comments, another approach is to develop your own autoincrement rule. I have a set where both the parent and child records need ID numbers assigned using some form of autoincrement. Since the parent ID links the child records, that ID is more critical. What I do is assign the ID when the parent is saved. In the CanSaveRecord event in field rules, I fist determine if the record is in enter or change mode using mode_get(). Then I find the next possible number using the tablemax() function and add 1. This becomes the new link field and reduces the possibility of conflicts.

        Another approach is to create a table which saved the last number used. When you need the next number, open the table, add 1 to the existing value and save the new number to both the parent table and the table holding the last value. I have used this approach too, but find the first method easier.

        Jerry

        Comment

        Working...
        X