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

Field Rules - Uniqueness Test

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

    Field Rules - Uniqueness Test

    Hi
    I have a table connecting to MSSQL database using ActiveLink. I have an autoincrementing primary key which is not accessible by the user and then a 10 char Code field. At the database end this has a unique constraint and in the field rules within the table I specified in the Uniqueness Test that the value must be unique. The problem I have found though is that this only lets me enter one record in the table! My first code (ACE001) created OK. When I tried to add a second record (code AMA001) the form immediately picked up ACE001. If I cancel or try to close the window, after confirming that I want to lose my changes I get an error message 'Memory Corrupt - terminate operations'. If I then cancel again everything is fine. I got the same behaviour with the default browse and default form as well. However once I remove that unique requirement from the field rules it all works as I would expect (except that I now need to check for the duplicate).
    This is the first time I've tried doing anything with field rules but it seems such an easy way to prevent duplicates. Am I missing something or doing something wrong?
    Thanks

    David
    Tags: None
    #2
    Re: Field Rules - Uniqueness Test

    Hi David,

    It seems that many people make the same mistake of setting both autoincrement and uniqueness test.

    By definition, autoincrement will be unique, therefore the uniqueness test is not required.

    Try it and see.
    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: Field Rules - Uniqueness Test

      Keith,

      If I have read David's post correctly the uniqueness test is flagging AMA001 and ACE001 as the same. Surely this isn't right. I haven't really used the uniqueness field rule but I'm interested to know why AMA001 and ACE001 would be classed as the same.

      Geoff

      Comment

        #4
        Re: Field Rules - Uniqueness Test

        That's right Geoff, the uniqueness test is on the code, not the auto incrementing key.

        David

        Comment

          #5
          Re: Field Rules - Uniqueness Test

          Hi,

          I did not pick up on the difference between AMA001 and ACE001 as the same, must get new specs.

          I still say that you dont need to have both the unique test and autoincrement as two field rules for the same field.
          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

            #6
            Re: Field Rules - Uniqueness Test

            Hi Keith
            The tests are not on the same field. I may have confused the issue by mentioning the autoincrement field, which I did in case it had any bearing on the problem.
            My file has 2 fields, ClientID and Code. Realistically for this file I don't need both but I always set my files to have a unique ID number as the primary key, which users cannot access. The ClientID field is an auto incrementing integer and there are no validation rules set on this. The code field is 10 character string and it is on this field that I have the uniqueness test. This is also set to Required and Uppercase.
            Is this a bug or is it me? I've been programming for almost 30 years so I have a lot of experience but this is my first attempt with Alpha so I'm quite happy to accept that it could be something stupid I've done but what? Have others had a similar issue with the uniqueness test or, if you are not using it, how do you enforce the data integrity? Do you check it in the OnExit event or is there another way? It seems to me that field rules should be the ideal way to do this, set once and forget about it but of course it needs to work!

            David

            Comment

              #7
              Re: Field Rules - Uniqueness Test

              I've just done a bit more testing and found that it works correctly with a native dbf file. I created a standard file using the same details, field rules etc as my ActiveLink table and it works, so it seems to be something to do with the ActiveLink setup. Any ideas?

              David

              Comment

                #8
                Re: Field Rules - Uniqueness Test

                For the benefit of anyone who may be interested, I posted this as a bug and have received the following reply from Selwyn
                Thanks. I think that the bug is that the user interface allows you to define the rule in the first place for an active link table.

                It should not.

                This rule should really be enforced on the server side (in your MySQL database) and not on the client side (i.e. by Alpha Five).

                You would enforce it on the server side either by making the field the table's primary index, or by defining a trigger.

                The reason it makes no sense to do this on the client side for an active link table, is that in order to enforce the rule for native tables, a5 ensures that there is an index on the column. But for active-link tables there are no indexes on the client side.
                Unfortunately that is not the answer I was hoping for! We are enforcing the rule on the server side but that only occurs when we try saving the record. The effect I wanted and which happens with DBF files is that as soon as you try & leave the field, the duplicate record is flagged and the operator is prevented from leaving. I am not sufficiently conversant with A5 yet to know if the following would work in it but in other languages I would create an SQL query of something like SELECT COUNT(CODE) FROM CLIENT WHERE CODE= EnteredValue. If that returns anything other than zero we would flag the duplicate. I assume something like this would work in A5 but I was hoping to be able to avoid having to code this for every unique field that an operator can enter.
                The fact that I can't do this with Field Rules seems a fairly major limitation to me. Does anyone have any ideas/suggestions on how this could be reasonably automated to work 'on the fly' in a similar manner to DBF Field Rules?

                David

                Comment

                Previous template Next
                Working...
                X