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

BAD LINKS

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

    BAD LINKS

    I have used alpha 4 over the years to run a small database for my optometry practice. I had a patient information screen that linked to a child database for my ledger transactions. I recently switched to alpha5 v4 and started to lose my links between my parent and child database. My patients would show up for a receipt and I had no record of them on the ledger. After some time I assumed that I had a poor link design. I tried and tested some different link designs but kept losing ledger records. I knew the records were there because I checked the child database.

    My current link design utilizes the "patient ID" field which is the result of a calculated formula that takes the first 3 letters of the patients last name with the first 2 of the first and then their date of birth. I did this so if I lose my link I will still be able to hunt down the transaction. I have also set referential integrity to cascade changes.

    My problem now is that when I go to my master database of the set and enter any new information in a previous patient's records, the ID field is changed from the old calculated formula of RECNO() to my new formula, but this does not cascade to the ledger record. If I pull up that patients record again, the previous ledger record entries for that patient are no longer linked to that patient.

    My assumption was that when the new patient ID in the parent database was calculated, that this would cascade to the child database, and my link would be maintained. What is going on?, why is this not happening, and what can I do to fix it. My link is one to many, with cascading. My linking fields are both character, and of the same length

    I tried to update the ID field on all of my records to maintain consistency, assuming that the new ID value would cascade to the child database. That only worked on some of the records.

    If I cannot solve this problem with the links I will have to consider a lookup database for transactions. I believe that this however does not take full advantage of the power of this database.

    I would also appreciate some, (other that those in the book) more aggressive and detailed strategies to maintain links in general. There has to be a better way to insure the integrity of my database links.

    #2
    RE: BAD LINKS

    I think the easiest thing to do would be to give every patient a unique account number. The account number should be required, unique and no changes allowed. The account number could default to the formula you described, but I would not make it a calculated field. Obviously this would link to a single field on your ledger detail table. You could have a field rule that verified this field against an existing patient. I am not nuts about referential integrity. If you are never going to change the account number why use it. If you've follwed the board on indexes and delete issues, you might see that it would be better to create a batch process for deleting ledger detail.

    Comment


      #3
      RE: BAD LINKS

      If you have multiple links i.e. customer+birthdate A5V4 doesn't do to well. There was a post earlier in the year where you add the two fields (padded) into a field called link. This link field transfers to the child data base and then you split the field in the child database into the two original fields. This will also help with referential integrity.

      Bob Sullivan

      Comment


        #4
        RE: BAD LINKS

        Nice to know there's a fellow optometrist using A5 for the office.

        Referential integrity only works while in the set. It does not work if the parent table is updated independently. If you updated the patient id in the patient table but not in the set then the referential integrity will not work. BUT, I'm not sure it works anyway when you recreate the linking field with an update operation.

        Comment


          #5
          RE: BAD LINKS

          Thanks for your help. With the responses I received I have more confidence in my links.

          Being a fellow optometrist Ohlen, maybe you have some insight into electronic medical claims. I would like to continue to use Alpha Five to do this but I am not sure how to take my records from my claims database and make the acceptable to clearinghouses for transmission. Do you have any ideas. I am sure there must be a way to do.


          Thanks,

          Rick

          Comment

          Working...
          X