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

Field Rule: Posting

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

  • Field Rule: Posting

    Is it possible? If possible the best method?

    I have a table with every election worker that might be assigned to a position. Their assignment is based on up to 147 active location sites and the positions. There are a total of 560 positions and each has a specific code.

    I need to know whether a position is open or assigned without having to:
    a) Check another table that displays the above sites and positions in each site in order.
    b) Using a posting operation that would have to be performed every time a change is completed. From this I am able to display a form displaying status of each position at the site.

    The current posting operation first puts zeros in the post field to clear it. Then adds a 1 to every record in the same field which matches in the table with the workers.

    The election worker could be a new worker with no action on the position field. The election worker could be a previous worker with action from the previous election and accepting the same position. Or accepting a different position.

    The posting operation would need to clear the previous position and then post to the new position in the position table from the worker table.

  • #2
    Re: Field Rule: Posting

    Gary,
    There seems to be a slight contradiction in what you want....

    ..... without having to: ..... Using a posting operation that would have to be performed every time a change is completed
    AND
    The posting operation would need to clear the previous position and then post to the new position in the position table from the worker table.
    That said, I don't know if any posting operation is necessary at all or if it even is the best choice for what you want to do.

    Sure seems like a few fields could indicate what you want such as "Past Position", "Current Position" for the workers. An "Open" logical or could even just be a character field in your Position table that is used to indicate such. Each position has to assign a worker right? or is there possibly more than one worker per position? Set up a set that accommodates whichever scenario you are trying to achieve and I think it will be easier than you think.

    Unless, of course, I have mis-guessed what you are wanting and regardless this may bring out more of the information that is going to be necessary in order for myself or others to help you. :)
    Mike
    __________________________________________
    It is only when we forget all our learning that we begin to know.
    It's not what you look at that matters, it's what you see.
    Henry David Thoreau
    __________________________________________



    Comment


    • #3
      Re: Field Rule: Posting

      Gary,
      I would like a few clarifications if possible.

      1. You have a positions table with 560 records (positions). There exists a field to mark the record as open "0", or full "1". Correct.

      2. The start of your sequence is to assign a value of "0" to all records in the positions table?

      3. You then proceed through each worker in the workers table and assign them a position. In this action you need to probe the positions table to confirm whether or not a positon is open of filled. If filled, it can't be assigned to that worker and another position must be assigned because, as Mike wondered, it is a one position-one worker assigned situation?

      4. How are you imagining dealing with this situation:
      Worker 1 wants position 69.
      Worker 5 had position 69 and wants it again.
      Will worker 1 get position 69 and worker 5 looses out because worker 1 will be assigned first?
      Mike W
      __________________________
      "I rebel in at least small things to express to the world that I have not completely surrendered"

      Comment


      • #4
        Re: Field Rule: Posting

        1. Is correct

        2. This sequence is currently performed after each day's operation or more often via the Operations Tab. I want to avoid this method if possible.

        3. This operation lasts about 3 month period. And yes we need to know whether the position is open or already assigned before making the assignment. I was using another set that would show each person assigned to each site. And I want to avoid double-booking anyone.

        4. As far as who gets what is based on timing. We generally try to assign based on what they did the last time and offer it again.


        This past primary which was the first time I was involved in assisting in the operation I set up the application based on data I knew about. Then as I became more involved and saw first hand the operation involved I added and tweaked to make it run smooth as possible.

        After about a month I decided to identify positions more precisely and using a code as follows: 99999-99-9 where the first 2 digits identified the township location of the voting site. The next 3 digits identified the primary precinct assigned to the voting site. The 2nd group of digits identified the position (Judge, Asst Judge, Clerk, Asst Clerk or Greeter). The last digit identified whether it was slot 1, 2 or 3. There could be 1 or 2 Asst Clerks and 1, 2 or 3 Greeters.

        All of the positions that we were using was in one table with the unique codes. The code in the worker table was generated based on a lookup of the voting site which generated the voting site code. A drop down tree was created that had the following options: Judge, Asst Judge, Clerk, Asst Clerk 1-1, 1-2, 2-2 and Greeter 1-1, 1-2, 2-2, 1-3, 2-3, 3-3. The 1-? was created for the purpose of printing the form that would be filed in a binder and a copy sent to the Election Board. It made it much easier for the other volunteers to identify which positions were still open when making calls. It also identified in the Election Site set in the application which slots were still open.

        I have been able to create a button that displays a list of valid positions and whether they are assigned but once I make a change that would no longer be valid for that particular site.

        I also have a field that indicates the status of the worker. Scheduled, Not Available, Not Available, No Show, Refused, Resigned and Standby with Scheduled being the only option that makes the worker's status active and required to post to the Position table as being filled. I probably should rework the Status field to have just Appointed and Not Appointed and create anther field for specific issues.

        I think what MikeC is suggesting is the route I need to use but wasn't sure of all the pieces that I would need to use to ensure success.

        I could have the following situations:
        1) Person is newly assigned
        2) Person was assigned but either position or site is changed
        3) Person was assigned but now unable to work that day

        1 and 3 should be easy. 2 would require a posting to clear the old postion and a posting for the new position. Looks like I should have a field that holds the old position to clear it. And I'm thinking that once the post is completed for that record it should be posted back in the Worker table something other than the position code so that it doesn't clear it again by mistake.

        I guess this is where I need to create a variable that holds the postion code and if the position code is changed insert it into the old position code field. ??

        I can see the possibility of accidently clearing a field that was already assigned when appointing a worker to the wrong position too.

        Comment


        • #5
          Re: Field Rule: Posting

          Gary I think you can do this without a status field in the positions table.
          If you are placing the unique position code in the worker record (which would be the logical way to assign/link the two) then if the code for a position is to be found in the worker table it can be considered to be filled.

          Create an index on the position code field in the worker table and then use .NOT. exist(PositionCode,"WorkerTable", "CodeIndex") as a filter for displaying available records from the positions table.

          I could have the following situations:
          1) Person is newly assigned
          2) Person was assigned but either position or site is changed
          3) Person was assigned but now unable to work that day
          1) As soon as a position is assigned the index is updated and then the position's availability would be reflected in the exist() filter.

          2)Since each position-site combo is a unique record ultimately you are only changing one thing - the position. So changing the code in the worker record will make the newly entered position unavailable and the old one available since it no longer exists in the table.

          3)I would make the action of changing the worker status to not available clear the position code field. You could do this at the form level or field rule level. I think in this case I would go with the a field event in field rules.


          You might also want to turn on the unique field rule for the position code field in the worker table as a safety so some one doesn't manually enter an already assigned position. You could also code your own validation, again using the index, on the field's events.


          EDIT:

          If you want to keep track of positions assigned to a worker create an audit type table that gets filled when the position field gets updated. You could then not only see the last position held but maybe see a pattern of which positions they may prefer. This table could also hold who was logged into the application, if you have users set up, so you can know who was the dolt who moved Mary from her favorite spot.
          Last edited by Tim Kiebert; 05-19-2008, 08:03 PM. Reason: additional info
          Tim Kiebert
          Eagle Creek Citrus
          A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

          Comment


          • #6
            Re: Field Rule: Posting

            Thanks that looks like a different angle to attempt and looks like it would work better.

            The Position table has the unique Position_Code and the Worker table does not. BUT I'm sure for that part I can modify the Worker table so the PositionCode can only be used once in that table too. I can probably get rid of that status field in the Worker table too.

            I haven't gotten that far using Users but do want to implement that so that there is an audit and track what is done. As far as workers preference I already have a table that holds data about each election and each action. I will have to research how an audit table should be created.

            When you talk about unique field in the Position table and also the Worker table does that mean that the PositionCode in the Worker table cannot have more than one record that is not filled?

            In the Position Table there are 560 records with unique Position Codes. In the Worker Table there are currently 859 records. In the past primary election there were 557 that were finally assigned and the remaining were for various reasons not assigned. We have people that are also on are "Do Not Use" list, Not Available or other reasons in the same Worker Table.

            Again, thanks for your advice.

            Comment


            • #7
              Re: Field Rule: Posting

              When you talk about unique field in the Position table and also the Worker table does that mean that the PositionCode in the Worker table cannot have more than one record that is not filled?
              Good question.

              Instead of just using the PositionCode field use the 'Value of expression must be unique' in the Uniqueness test.

              You must aleady have either a worker id field or a combination of other fields that will uniquely identify each worker record. Use those fields if PositionCode is blank or if not use the PositionCode field as the expression. For example:
              Code:
              If(IsBlank("PositionCode"),Worker_Id,PositionCode)
              This will return either the worker_Id or the positionCode to use as the uniqueness test. This way you turn an empty PositionCode field into a value (for the purpose of the test) that you know is unique thereby allowing the actual blank value.
              Tim Kiebert
              Eagle Creek Citrus
              A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

              Comment


              • #8
                Re: Field Rule: Posting

                Thanks again Tim

                Comment

                Working...
                X