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

File Update Problem

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

    File Update Problem

    I recently went out an app update which contained several *.ddd, *.ddm, *.ddx, *.sem, *.sex, *.sex files (no *.dbf, *.cdx, *.fpt files). The new files were copied directly over the old ones in the user's "application" directory (all use Runtime version).

    After the updates were installed and database compacted, some users had trouble with auto-increment fields resetting back to a previous number instead of going on in consecutive order. For example, if a user was ready for salesform #545 before the update, a new salesform came up with #530 (an existing salesform number) after the update was installed. Of couse, this has caused a lot of reporting and lookup problems.

    These were all character fields defined in field rules as auto-increment.

    Has anyone else had this happen? If so, WHY does it occur? How can I handle future updates to avoid this problem?? Thanks.

    #2
    RE: File Update Problem

    Becky, the term 'application directory' is not clear to me.

    When I do an update such as you describe, I store the new files in the 'database' directory on the server, and then refresh the shadow files on each workstation, or network optimize each workstation to bring them up to date. Shadowed copies of the files you updated will not automatically be updated just by copying new 'originals' into the database folder on the server.

    The autoincrement field rule is not bulletproof. If two data entry people start a new record in quick succession, they can wind up with the same number, since the field rule calculates it at the beginning of data entry for each pending record. The second user's system has no way to know whether others are also working on a new record which has not yet been saved.

    If the 'wrong' autoincrement value is significantly different from the actual value in the last record of the table, I'd check to make sure that the runtime version is not working with an incorrect copy of the database. I've heard of situations where the runtime user thought they were working with data on the server, but were in reality working with a duplicate set of tables inadvertantly copied to the local workstation. Such a bizarre thing could account for different values in the 'last' physical record of the table. Remember, it's the value in the last 'physical' record that is used by the autoincrmeent field rule.

    -- tom

    Comment


      #3
      RE: File Update Problem

      I have a very similar situation, and I just found out about it today.

      I had a problem with autoincrement about 4 months ago and with help from the message board, I tracked this first one down: I had 'shut off' the auto-increment field rule to fix some problems. When I turned it back on, I wasn't at the end.

      At that time I stored away the 'use an algorithm' thought, but hadn't touched it. Well today, the client called and let me know they have duplicate #'s again.

      But my problem this time seems similar to yours. I sent some updates last week, and now this autoincrement thing cropped up again. My whole app resides on the server, and for almost a year, when I change or add forms, I send all the changed files except the *.fpt, *.dbf, *.cdx. They overwrite the other stuff, and upgrades occur. But now, I have this other problem creeping up.

      Any ideas?

      Comment


        #4
        RE: File Update Problem

        One more note -- the dups didn't occur in two 'new' accounts, but a new account duped a number that was 6 months old.

        Comment


          #5
          RE: File Update Problem

          Valerie, I'm alarmed at your report (and Becky's) since your approach is what I do, too, except I don't routinely compact the database. I suggest you have the client send you the data files so you can test them completely. Is it possible they've somehow truncated the file, or corrupted it somehow?

          --tom

          Comment


            #6
            RE: File Update Problem

            I use Wyse Installmaker which was packaged with my Professional Version of Alpha5 Runtime. When my app is installed on another computer, it puts my program name ("weedwyse") under Program Files and creates 2 subdirectories: runtime (contains runtime files) and application (contains the app files). This is what I mean by "application directory".

            All of the people using this are on standalone PC's - no networks. They have a utility built into the app where they can compact the database themselves after new files have been added or formats changed.

            Comment


              #7
              RE: File Update Problem

              i suspect the problem occurred, not from the update, but
              from the compaction of the database. possibly for some
              reason the compaction of some of the tables failed. how
              do your clients perform compaction? do they have access
              to the control panel? did they see any errors during
              the database compacting? have they ever compacted before?

              Comment


                #8
                RE: File Update Problem

                Today, my thoughts are even fuzzier, but if the dups are all new accounts since Thursday, I may have a clue. I created a new set at my machine, and then loaded parts. When I got to their network to test it, it didn't work. After some head scratching, I realized that my new set had created a new index, an index on one of the tables. But I don't copy *.cdx. So I created that index at their machine. Could that have caused an auto-increment problem?

                It was on a different table than the one with the auto-increment problem, but the auto field is on the parent table, and the new index was on the grandchild.

                I'm testing at their site later today.

                Comment


                  #9
                  RE: File Update Problem

                  Tom,

                  The autoincrement field rule is not bulletproof. If two data entry people start a new record in quick succession, they can wind up with the same number, since the field rule calculates it at the beginning of data entry for each pending record. The second user's system has no way to know whether others are also working on a new record which has not yet been saved.

                  That's only partially correct. Add the time of the save, the autoincrement rule rechecks to see if that value has already been saved and then increments the number by one if it does. Any fields based upon the autoincrement field are also updated. It is possible to have rules that the autoincrement can not update though.

                  Regards,

                  Ira J. Perlow
                  Computer Systems Design & Associates
                  [email protected]
                  Regards,

                  Ira J. Perlow
                  Computer Systems Design


                  CSDA A5 Products
                  New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                  CSDA Barcode Functions

                  CSDA Code Utility
                  CSDA Screen Capture


                  Comment


                    #10
                    RE: File Update Problem

                    Valerie et al,

                    When you copy just the data dictionaries, the assumption is that you have not changed the structure or index names. If you have changed the structure (e.g. deleted fields, moved them around, renamed them) some layouts may fail due to referenced fields. The index part of the data dictionary may also have problems.

                    Index definitions are stored primarily in the index, but another part is stored in the dictionaries. Having index names 10 or less in length are safer as the longer versions are stored in the data dictionaries. Shorter ones can be stored in the index and are the ones A5 defaults to if the data dictionaries have a problem. If the index file definitions is changed in any way, it behooves you to send the cdx file as well. This can be based upon an empty table (which makes it a lot smaller). After you have copied your updated dictionaries and cdx files, then do a reindex (or a compact that will also do a reindex) before using the new ones.

                    Regards,

                    Ira J. Perlow
                    Computer Systems Design & Associates
                    [email protected]
                    Regards,

                    Ira J. Perlow
                    Computer Systems Design


                    CSDA A5 Products
                    New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                    CSDA Barcode Functions

                    CSDA Code Utility
                    CSDA Screen Capture


                    Comment


                      #11
                      RE: File Update Problem

                      The users do not have access to the control panel. I have a button in a utility menu with a system maintenance script attached. This script was provided to me by Finian Lennon ("DBCompact" -I think I've seen it elsewhere on this site). After compacting, it allows the user to run a file maintenance report to see if any tables failed. To my knowledge, none failed.

                      Comment


                        #12
                        RE: File Update Problem

                        Ira, thanks. I didn't know that. -- tom

                        Comment

                        Working...
                        X