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

Unique test

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

    Unique test

    I have a field that is set to auto increment in field rules.
    By using this I can not enter a test to make sure that the number is unique.
    Is there another place I can check that the autoincrement value is unique. Possibly in xbasic?
    Thanks.

    #2
    RE: Unique test

    What about the Validations tab in the Field Rules?

    kenn
    TYVM :) kenn

    Knowing what you can achieve will not become reality until you imagine and explore.

    Comment


      #3
      RE: Unique test

      Once you choose Auto increment, the Validations tab is grayed out.

      Comment


        #4
        RE: Unique test

        If you display the auto-increment field on a form it will show the next number when you go into add mode.When you save the record, if that number has been used by another user during the time it took you to populate the fields, it will re-increment it before saving.Alpha is basically doing its own unique test behind the scenes.My guess is that the only time it has a problem is if the table's indexes are corrupted.
        That being said, there are many, including myself, that use there own routines to autouncrement with there own tests on uniqueness.The next number is retrived from another file, incremented and saved back to that file in the on enter event.There is much out there on the board on this matter. You might do a search on this board and the Alpha Four board to see other's thoughts.I think Peter Wayne has an article on this on his website.

        Comment


          #5
          RE: Unique test

          Do I understand you right.
          Once a field is set to autoincrement, it will never use the same number twice. Is this correct?

          Comment


            #6
            RE: Unique test

            If you are not allowing record deletions from the table it is not supposed to.If you had records numbered from 1 to 100 and you deleted the record with the 100,I believe the auto-increment function would return a 100 again.
            Once again. Take a look at some of the prior threads on this.There's a lot of them.

            Comment


              #7
              RE: Unique test

              Thanks John.

              Comment


                #8
                RE: Unique test

                Also if you append current records to a history transaction table and then delete and pack the current the autoincrement will be a duplicate. As long as you dont anticipate the files becomming to large or getting rid of old or completed records you will probably be ok.

                charlie crimmel

                Comment


                  #9
                  RE: Unique test

                  I will be deleting records.
                  I have 3 tables are am concered with.
                  Customers- I don't think I will ever have more than 500 customers.
                  Vendors- never more than 100
                  Orders- this is the one that I am concered about.
                  I don't know how many Purchase orders I can have over the life of the program. I do have an autoincrement on this one.
                  If I set the field lenght for 8. I guess I could have more than a million records. Right?

                  Which brings me back to my original question.
                  When I set the feild value for order ID as an increment, the uniqueness tab is grayed out. Is there a way to use xbasic to make sure that a duplicate number is never used?
                  Thanks.

                  Comment


                    #10
                    RE: Unique test

                    Is there a way to use xbasic to make sure that a duplicate number is never used?


                    Yes, there is. As John pointed out, there are several past threads, especially in the A5v4 message board with code to account for most any scenario. Try a search usisng Autoincrement.

                    kenn
                    TYVM :) kenn

                    Knowing what you can achieve will not become reality until you imagine and explore.

                    Comment


                      #11
                      RE: Unique test

                      If there isn't auto-incrementing on in every table/set field rule, then possibly the Exists() or Key_Exists() function is the easy way.. ? sometimes in a CanSave on a form or the similar FieldRules function?

                      Hmm, there should be a semi-standard
                      ControlPanel-Table/Set-->FieldRules->Events-->RecordEvents--->CanSaveRecord
                      Exists() function and dialog box you could make up and use in various primary keys.. (thinking for myself, also :-)

                      There is an issue of making sure that you don't use a function that will consider your very record as the "hit", I saw a discussion of using one function over another for that.. (advanced folks, please step in)

                      Of course, one purpose of auto-incrementing is to avoid all that

                      Comment


                        #12
                        RE: Unique test

                        ====================
                        John
                        If you had records numbered from 1 to 100 and you deleted the record with the 100,I believe the auto-increment function would return a 100 again.

                        Steven
                        That sounds like it is a questionable default, say someone prints out an order and then deletes it, but keeps the deletion order printed out as part of the audit and record trail, often you really don't want to have two Order #153's even if one is deleted.

                        The field rules behaviour on "last-number" deletes would best be an option to reuse or jump over..

                        Granted, generally a minor issue...

                        Actually one of the problems of the .dbf delete functions is that they tend to be inflexible..

                        Keep in mind that in many cases you want to instead create your own activity code, such as
                        A=Active
                        O=Out-of-business
                        I=Inactive
                        N=No Longer Used
                        D=Deleted
                        And not allow D for any one who has historical data

                        Then you would filter a lot on Code=A

                        Just some thoughts..
                        =================================================

                        Comment


                          #13
                          RE: Unique test

                          Also look at the little discussion in the Code Archives

                          http://msgboard.alphasoftware.com/alphaphorum/read.php3?sortby=lastreply&direction=desc&num=7&id=235&thread=172

                          Especially
                          Msg ID:174 Subject:Auto-increment script Author:Bill Warner Date:11-30-2000 11:16 AM File:

                          And the next post..

                          He points out some of the advantages of using your own control file for the number rather than auto-increment ...

                          Comment

                          Working...
                          X