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

Database record Locking - to avoid overwriting changes

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

    Database record Locking - to avoid overwriting changes

    I may be doing something wrong in my design, as I found the following issue.
    I created an UX application using Alpha Anywhere, the database is SQL Server.
    Opened a session (session 1) and queried a record (Example: Employee: 1234)
    Opened another session (session 2) on another tablet and queried the same employee (Employee: 1234).
    Updated the session 1 name from 'John' to 'John1'
    Saved session 1.
    Queried the data in database name is John1.
    Session 2 is still open with the old data on another machine (tablet) (name display is John)
    Updated the session 2 name to 'John2'
    Saved session 2.
    It saved session 2 and updated the database to John2. This is a issue of overwriting. How do I fix this issue.
    Expected error was 'Another user has updated the record - please requery and make changes' (something along these lines)
    How do I handle this issue?
    Thanks.

    #2
    Re: Database record Locking - to avoid overwriting changes

    Any help - Please?
    As you see the application is updating the values in the database without looking to see if someone else has already updated the same value in the database using another session, therefore can cause data inconsistencies.

    Comment


      #3
      Re: Database record Locking - to avoid overwriting changes

      I'd be interested in this too ... perhaps a method of preventing the record from opening in the first place if another session opened it already.
      Mike Brown - Contact Me
      Programmatic Technologies, LLC
      Programmatic-Technologies.com
      Independent Developer & Consultant​​

      Comment


        #4
        Re: Database record Locking - to avoid overwriting changes

        One way is to compare the old values of the fields (old - meaning at the time when the fields were retrieved in the UX/Grid) and the latest value in the database (by issue a fresh select/SQL, before the commit) - if they match we are good to update database with the new values on the UX/Grid. We need to lock the particular row(s) on the table in the database using the database command before we start the compare mentioned above.
        But this is more like a manual process - can be done only as the last option if Alpha is already not handling this automatically!
        Last edited by JPMPA; 11-13-2013, 12:59 PM.

        Comment


          #5
          Re: Database record Locking - to avoid overwriting changes

          I think I have this problem too. A5V11 is using optimistic locking and this is not working out for me. How do I turn pessimistic locking on?

          Comment


            #6
            Re: Database record Locking - to avoid overwriting changes

            To follow up, there must my some sort of race condition in my app since it is possible for two sessions to enter the same unique value..or what's supposed to be unique. I think record locking is server side which unfortunately I don't have any control over. In fact, I wouldn't know if it's pessimistic or optimistic in the key..which is where I think it resides. This is all a recent occurance--going to windows 7, installing A5V11 and upgrading server software. And it seems I'm rebuilding indexes all the time.

            Comment


              #7
              Re: Database record Locking - to avoid overwriting changes

              This video illustrates the multi-user functionality of data entry through grids. It was prepared using A5v10.

              Question: Does this no longer work in v11 or AA ?

              Question: Is this functionality limited to data entry through grids?

              Question: Has anyone asked Alpha?

              These questions do not seem to be addressed in the help file documentation or video list, using searches for "multi-user".
              Last edited by Tom Cone Jr; 11-13-2013, 06:42 PM.

              Comment


                #8
                Re: Database record Locking - to avoid overwriting changes

                Do you have to use the UX?
                What about using the Grid component which has the "Check for write conflicts" property built-in?

                To see how Alpha implements the "check for write conflict", try turning that option on for a Grid and also turn on the "Debugging / Show update commands" option. You'll see alpha adjusts the WHERE clause to take care of checking for write conflicts. To get a UX to do the same thing you'd need to find out what functions Alpha exposes that you could use to build the SQL update command from a UX so it operates like it does from a Grid.

                Comment


                  #9
                  Re: Database record Locking - to avoid overwriting changes

                  Thanks Rich. (sorry for the delay - I had issues posting to the forum around the 3rd week of November)
                  Since this is a mobile application - UX is more appropriate in this case.
                  To overcome the issue, before doing the database update I am going to do a quick select to the database to see if the values changed before updating as shown below.
                  The following steps will work for my simple application.
                  1. When record are retrieved by the user, I will have code to save the values of the updatable fields to temporary non database fields on the UX component (call the values originally retrieved values).
                  2. Before updating the records, I will quickly lock it using the ROWLOCK, UPDLOCK commands for SQL server or 'for update of' for Oracle.
                  SELECT values From thetablename with (ROWLOCK, UPDLOCK) where key = value; --> SQL Server
                  SELECT values From thetablename where key = value for update of values; --> Oracle
                  3. Compare the originally retrieved values in step 1 to the values retrieved in step 2.
                  4. If the values match exactly - then the values were not updated - so update and commit (submit).
                  5. If the values do not match - then the values were updated by a different user - so do not update - the error message displayed can be 'Issue with database update - values were updated by a different user - please requery, make changes and submit again.
                  6. The commit (submit) will removed the lock.

                  If Alpha has better solution for UX components - I will use it for future apps. Meanwhile, I think the above will work for me.

                  Thanks.

                  Comment

                  Working...
                  X