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

Strange problem with posted data

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

    Strange problem with posted data

    An application that has been running for years has recently begun to exhibit a weird behavior. Information from a transaction table is posted to master table, but after a period of time the fields in the records that received the posted data in the master table revert to their previous state.

    The fields in question are logical fields and the default value is �F�. The posted changes replace the value with �T�. How can those fields revert to their previous state without having been opened and changed?

    Additional info: the data files are on a file server and are accessed by only two client PCs. The application does not use a shadow database on the clients. The clients load the database directly from the server. Client PCs were upgraded to A5V11 runtime last year.

    Although several tables receive posted data, only one table has been affected. I copied all application and data files to a new folder in order to run tests with a new client PC. I have not been able to replicate this behavior on the test application with the new client or on a local version of the application on my laptop.
    I�ve never seen anything like this. Any suggestions about how to correct the problem will be very much appreciated!

    #2
    Re: Strange problem with posted data

    No matter how it is originally changed or added to. A record will remain the same until one of 3 things happens.

    Record is deleted
    Record is change by somebody
    Record is changed programmatically.

    Obviously deleted did not happen
    leaves the other 2. If you can rule out programming, the check who could benefit is some way by modifying the record.
    Dave Mason
    [email protected]
    Skype is dave.mason46

    Comment


      #3
      Re: Strange problem with posted data

      Jeff, you might look for batch operations that manipulate field values in the table targeted by your post field rule. Do any of them touch the fields you're talking about?

      Worst case, you might abandon the post rule and code a replacement that includes an audit trail feature. This could give you the date, time, before value and after value each time a "post" occurs.

      Comment


        #4
        Re: Strange problem with posted data

        Also look at UNDO ON DELETE in the post rule.
        Also check that the index is correct. If the Index has become corrupt, posting might be going to the wrong record.
        Edit.
        Been thinking about this over breakfast. Are you sure the source data is correct? We had a situation on the Forum and were seeking solutions when it turned out the data was crapola.
        Last edited by Ted Giles; 09-14-2014, 07:19 AM.
        See our Hybrid Option here;
        https://hybridapps.example-software.com/


        Apologies to anyone I haven't managed to upset yet.
        You are held in a queue and I will get to you soon.

        Comment


          #5
          Re: Strange problem with posted data

          Thanks to all for the reply. When this behavior was first reported I didn't really believe it. But, then I observed it myself. We ran a batch operation as part of normal business. We checked the updated records and the data posted as expected. An hour or so later, the logical fields reverted to their prior state. Data was definitely posted to the right records and was correct in the source table. The same source data correctly updated a second table.

          It's pretty clear that the records are not being changed by an operator. Operators only have the runtime application and lack the knowledge to create batch operations in any event. Also, no real motive change the records.

          Ted: I'll check the UNDO ON Delete in the post rule. That's a possibility. However, the the application has been running for ten years and only recently displayed this problem. I don't know why this should have become an issue now.

          Comment


            #6
            Re: Strange problem with posted data

            Update: I wasn't clear in the OP. The post is done as a batch operation and there is no posting rule in the field rules, so UNDO ON DELETE is not a factor.

            Comment


              #7
              Re: Strange problem with posted data

              OK>
              Ruled out users so it has to do with programming in some way.
              1. It is possible that something that worked in another version is not the same as a newer version.
              2. Is the posting being done in field rules?
              3. is it a possibility we could see the code for the batch operation(s) you run?
              4. Way out there, but since you can't duplicate on other machines: there is remote possibility there is a bad spot on the server unit hard drive that the affected table sits. Remedy is to run a disk checker on that server or copy the whole app to a different folder on the server before deleting the first(I know it is some mapping work).

              Also, when I mentioned users changing stuff, I did not mean for just personal gain. They could also be just trying to help. Uneducated users can be just as dangerous as full blown developers.
              Dave Mason
              [email protected]
              Skype is dave.mason46

              Comment


                #8
                Re: Strange problem with posted data

                This is a V11 section. What version did you move from, when, and how.
                What version of V11 are you using, as the current one is not 10 years old.
                See our Hybrid Option here;
                https://hybridapps.example-software.com/


                Apologies to anyone I haven't managed to upset yet.
                You are held in a queue and I will get to you soon.

                Comment


                  #9
                  Re: Strange problem with posted data

                  DaveM: The posting is done with a batch operation, not filed rules. The upgrade to A5V11 was made last year, so I don't know why it would only affect the operation in the last couple of weeks.

                  I'm actually thinking that the issue may be something like #4. The server is old and in the process of being replaced due to failing components. I'll mention it to the network guy. Thanks for the response. I'll see if I can put the code.

                  Comment


                    #10
                    Re: Strange problem with posted data

                    Got it!
                    I had this problem years ago with record locking.
                    If you are not using shadowed databases, there is a possibility that one user has a record set open when the batch is run. Then on release, the records go back to the original. See what happens with just one user and with the users actually logged off and out of Alpha.
                    See our Hybrid Option here;
                    https://hybridapps.example-software.com/


                    Apologies to anyone I haven't managed to upset yet.
                    You are held in a queue and I will get to you soon.

                    Comment


                      #11
                      Re: Strange problem with posted data

                      Ted may have hit this if it is only one record at a time??
                      Another vote for shadowed. LOL
                      Dave Mason
                      [email protected]
                      Skype is dave.mason46

                      Comment


                        #12
                        Re: Strange problem with posted data

                        Originally posted by DaveM View Post
                        Ted may have hit this if it is only one record at a time??
                        Another vote for shadowed. LOL
                        You're up early Dave.
                        See our Hybrid Option here;
                        https://hybridapps.example-software.com/


                        Apologies to anyone I haven't managed to upset yet.
                        You are held in a queue and I will get to you soon.

                        Comment


                          #13
                          Re: Strange problem with posted data

                          As we're still having this problem, I'll post the code for the script calling the operation and for the operation itself. All of this was produced using action scripting as I'm not a programmer. As you can see this is a batch operation and the issue occurs with batches of records. For this reason I don't think that record locking is the problem as that should only affect a single record and the records in question are only in use for this operation.

                          I can't see an idea why this should not work as it always has and I'm at the point where I think we have an issue with flaky hardware. I am migrating the application to a new server shortly. We also have a client PC that is performing badly that will be replaced at the same time.

                          'Run PostCartonsShipdtoCarton.
                          query.filter = ""
                          query.order = ""

                          DIM operation_name as c
                          operation_name = "PostCartonShipdtoCarton"
                          If operation_name <> "" then
                          post.run_silent(operation_name,"",query.filter)
                          End if

                          Operation:

                          a_tbl = table.open("cartons")
                          ON ERROR GOTO ERROR17092014184717465


                          post.t_db = "cartonshipped"
                          post.m_key = "Acct_Num+Item_Num+Pallet_Num+carton_num"
                          post.t_key = "Acct_Num+Item_Num+Pallet_Num+carton_num"
                          post.m_filter = ""
                          post.t_filter = ""
                          post.m_count = 3
                          post.m_field1 = "OUT_OF_INV"
                          post.m_exp1 = "@CARTONSHIPPED->Posted"
                          post.m_field2 = "SHIPPED"
                          post.m_exp2 = "@CARTONSHIPPED->Posted"
                          post.m_field3 = "DATE_OUT"
                          post.m_exp3 = "@CARTONSHIPPED->Date_Out"
                          post.t_count = 0

                          'Prompt for confirmation before running the Operation.......
                          dim rec_count as n

                          rec_count = a5_get_records_in_query("cartonshipped",post.t_filter,-1,.f.)


                          message_text = "A maximum of "+rec_count + " record(s) will be Posted from 'cartonshipped' to 'cartons'."+crlf(2)+ "OK to proceed?"
                          operation_result=ui_msg_box("Post Operation",message_text,UI_OK_CANCEL+ UI_FIRST_BUTTON_DEFAULT+ UI_INFORMATION_SYMBOL)
                          If operation_result <> ui_ok_selected then
                          end
                          end if



                          a_tbl.post()


                          GOTO CONTINUE17092014184717465
                          ERROR17092014184717465:
                          ON ERROR GOTO 0
                          ui_msg_box("Error","Error running Post Operation"+crlf()+error_text_get())
                          END
                          CONTINUE17092014184717465:
                          a_tbl.close()
                          'Display a dialog box showing the results of the Operation

                          dim args as sql::arguments
                          if eval_valid("arguments") then
                          if typeof(arguments) = "P" then
                          args = arguments
                          end if
                          end if


                          a5_post_op_result(a_records_processed,a_records_total,a_records_violated,"cartons", args)
                          'If the Operation is run from within a Form or Browse, then refresh the window
                          if is_object(topparent.this) then
                          if topparent.Class() = "form" .or. topparent.class() = "browse" then
                          topparent.Refresh_layout()
                          end if
                          end if

                          Comment


                            #14
                            Re: Strange problem with posted data

                            What is the length of the result of this expression?

                            Acct_Num+Item_Num+Pallet_Num+carton_num

                            ie how many characters when you add the length of all of those fields?

                            240 is the max allowed.

                            No error will be shown, but it's only using 240 characters to determine a key match.
                            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


                              #15
                              Re: Strange problem with posted data

                              Acct_Num+Item_Num+Pallet_Num+carton_num generates a 22 character string.

                              Comment

                              Working...
                              X