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

Sporatic, eratic data behavior.

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

    Sporatic, eratic data behavior.

    Attached is a sample zip file with instructions. Data doesn't appear, reappears, appears in different format. It's insane.

    Hopefully, someone can bring some sanity to this.

    Thanks,

    kenn
    TYVM :) kenn

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

    #2
    Re: Sporatic, eratic data behavior.

    Sorry, I started to look but kept getting errors. As my date format is dd/mm/yyyy, this will not work for me to test unless I change my system. So I edited your set defaults to

    dim myd as d
    myd = DATE_VALUE( 1999,12,31)
    parentform:Browse6:Crf_date.value = myd
    'Set 'Value' property of 'Browse6:Crf_date' in Form 'f_Crim_Complaint' .
    parentform:Browse6:Crf_date.value = myd
    'Set 'Value' property of 'Browse7:Hrf_date' in Form 'f_Crim_Complaint' .
    parentform:Browse7:Hrf_date.value = myd
    'Set 'Value' property of 'Browse8:Med_date' in Form 'f_Crim_Complaint' .
    parentform:Browse8:Med_date.value = myd
    'Set 'Value' property of 'Browse9:Otr_date' in Form 'f_Crim_Complaint' .
    parentform:Browse9:Otr_date.value = myd
    'Set 'Value' property of 'Browse2:Asset' in Form 'f_Crim_Complaint' .
    parentform:Browse2:Asset.value = " N/A"
    'Set 'Value' property of 'Browse3:Name' in Form 'f_Crim_Complaint' .
    parentform:Browse3:Name.value = " N/A"

    This then set the dates in the field based on my system regional settings. Not sure if your issues are related to this, but this might help for future use of dates
    -----------------------------------------------
    Regards
    Mark Pearson
    [email protected]
    Youtube channel
    Website

    Comment


      #3
      Re: Sporatic, eratic data behavior.

      I didn't try other date formats but I suspect that is not the culprit. It should put the default values into every browse right from the gitgo, not hit and miss as it is now. And, it should put them in the default format.

      I would think that no mater what date format your preferences are set to, the field format would or at least should, take preference. The are times when more than one date format is needed.

      Do you see the behavior that I described on the form?

      Thanks,

      kenn
      TYVM :) kenn

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

      Comment


        #4
        Re: Sporatic, eratic data behavior.

        For some reason the system is not saving the record in the t_caf.dbf table until one of two conditions occur. The first condition is you change the default date. The second condition is you enter data into another field in the T_caf.dbf table along with leaving the date field unmodified.

        Bug or not I do not know. I however have developed a workaround that may do what you are wanting.

        I first removed your field rule setting the default in the t_caf.dbf table.

        Then using action scripting I set the default date in the browse based on the t_caf.dbf table on your form. I used the OnRowChange event of the browse and tested if the browse was in enter mode before setting the default date.
        Andrew

        Comment


          #5
          Re: Sporatic, eratic data behavior.

          Kenn,

          Good morning.

          Your sequence specifies that the user should push the "Set Defaults" button after beginning a new parent table record. This means the "set defaults" script is assigning field values to new records in multiple child tables regardless of whether or not the parent table record is saved or not. A dangerous business.

          When working with data entry using a complex set you must remember that Alpha stores records in tables, not in sets. Your "set defaults" script has the effect of beginning new records in the child tables it touches, even when the record you have just started in the parent table has not been commited to disk first. This sequence is a good way to prevent Alpha Five from creating the necessary link field values that will connect your child table records to the parent.

          If this were mine I'd commit the pending parent table record before beginning any child record. I'd also commit each child table record before beginning any other child table record.

          And, given the complexitites of your set design, I'd rethink simplifying it. As recommended by Dr. Wayne in "Simplifying your Applications for Better Performance" at www.learn alpha.com.

          -- tom

          Comment


            #6
            Re: Sporatic, eratic data behavior.

            Originally posted by aws View Post
            For some reason the system is not saving the record in the t_caf.dbf table until one of two conditions occur. The first condition is you change the default date. The second condition is you enter data into another field in the T_caf.dbf table along with leaving the date field unmodified.

            Bug or not I do not know. I however have developed a workaround that may do what you are wanting.

            I first removed your field rule setting the default in the t_caf.dbf table.

            Then using action scripting I set the default date in the browse based on the t_caf.dbf table on your form. I used the OnRowChange event of the browse and tested if the browse was in enter mode before setting the default date.
            Hi Andy,

            Thank you for taking the time to review and the suggested changes. I will be taking this under consideration.

            kenn
            TYVM :) kenn

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

            Comment


              #7
              Re: Sporatic, eratic data behavior.

              Originally posted by Tom Cone Jr View Post
              Kenn,

              Good morning.

              Your sequence specifies that the user should push the "Set Defaults" button after beginning a new parent table record. This means the "set defaults" script is assigning field values to new records in multiple child tables regardless of whether or not the parent table record is saved or not. A dangerous business.

              When working with data entry using a complex set you must remember that Alpha stores records in tables, not in sets. Your "set defaults" script has the effect of beginning new records in the child tables it touches, even when the record you have just started in the parent table has not been commited to disk first. This sequence is a good way to prevent Alpha Five from creating the necessary link field values that will connect your child table records to the parent.

              If this were mine I'd commit the pending parent table record before beginning any child record. I'd also commit each child table record before beginning any other child table record.

              And, given the complexitites of your set design, I'd rethink simplifying it. As recommended by Dr. Wayne in "Simplifying your Applications for Better Performance" at www.learn alpha.com.

              -- tom
              Good Morning Tom,

              What differentiates a simple set from a complex set. This set only has child tables and all same linking. There is not a mixture of links nor and links below the child level.

              I did not realize I was not saving the parent record first and I agree, that should be done before entering child records.

              What is your suggestion to simply the set design? I looked at Peter Wayne's suggestion but that appears to be a quite different situation than what I have.

              Thank you for your comments.

              kenn
              TYVM :) kenn

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

              Comment


                #8
                Re: Sporatic, eratic data behavior.

                Kenn

                Have you compared the results from running this in v9 with v10?
                Al Buchholz
                Bookwood Systems, LTD
                Weekly QReportBuilder Webinars Thursday 1 pm CST

                Occam's Razor - KISS
                Normalize till it hurts - De-normalize till it works.
                Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                When we triage a problem it is much easier to read sample systems than to read a mind.
                "Make it as simple as possible, but not simpler."
                Albert Einstein

                http://www.iadn.com/images/media/iadn_member.png

                Comment


                  #9
                  Re: Sporatic, eratic data behavior.

                  Hello, Kenn.

                  Simple vs Complex is a judgment call for the designer. As mentioned in the article I referenced, sets with lots of tables require Alpha Five to move a lot of data over the network. Whether that will be an issue for you is dependent upon your hardware and the size of your record structures. In my own work I would use a set such as yours only for displaying data, or for reports. It would never be used for data entry. The issues you were experiencing are typical of the problems I bump into when I try to handle a multi-table sequence through a single set based form. I find it much easier and reliable to do data entry through single table forms or xdialogs.

                  Originally posted by forskare View Post
                  Good Morning Tom,

                  What differentiates a simple set from a complex set. This set only has child tables and all same linking. There is not a mixture of links nor and links below the child level.

                  I did not realize I was not saving the parent record first and I agree, that should be done before entering child records.

                  What is your suggestion to simply the set design? I looked at Peter Wayne's suggestion but that appears to be a quite different situation than what I have.

                  Thank you for your comments.

                  kenn

                  Comment

                  Working...
                  X