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

Moving a form to another database

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

    Moving a form to another database

    Hi,

    I hate to double post but my other thread did not get a satisfying answer so I will reformulate the question.

    I have read the help about file types but I still am unsure how to do this.


    Lets say I have created a complicated form with browses and button events, tested it in a test installation and now want to implement this into the production database as smooth and fast as possible.


    What files do I need to copy to avoid as much double work as possible?
    How do I link these files to the second environment?


    Is there a step to step guide somewhere how to do this?
    I cannot believe that I would have to do the whole design again.

    My other thread was more global: Where can I find instructions about best practices how to update a production database from a test environment.

    Thanks a lot !

    Eriks

    #2
    Re: Moving a form to another database

    What files do I need to copy to avoid as much double work as possible?
    If the form is based on a table (unlikely) you would copy the table data dictionary files.

    tablename.DDD, tablename.DDM, tablename.DDX
    Code:
    Data Dictionary
     .DDD
     The table's data dictionary, which contains lists of additional table objects such as Layouts (forms, browses, etc.), report designs, saved operations, field rules, and field names longer than 10 characters.
     Dictionary Methods, Reading From and Writing To the Data Dictionary
     
    .DDM
     Stores additional table objects such as Layouts (forms, browses, etc.), report designs, and saved operations in memo format.
     
    .DDX
     Contains the dictionary's index(es). Alpha Five uses the .ddx to find a specific form name or field rule or whatever is needed.
    If the form is based on a set you would copy the set data dictionary files.

    setname.set, setname.sem, setname.sex

    Code:
    Set
     .SET
     The set's data dictionary, which contains lists of additional set objects such as Layouts (forms, browses, etc.), report designs, saved and operations.
     Set Functions and Methods
     
    .SEM
     Stores additional set objects such as Layouts (forms, browses, etc.), report designs, and saved operations in memo format.
     
    .SEX
     Contains the set's index(es), used to find set components.
    How do I link these files to the second environment?
    Not necessary. When the database is next opened, the form will be read from the new dictionary files.
    There can be only one.

    Comment


      #3
      Re: Moving a form to another database

      Thank you Stan !

      Just to make sure:

      If I make a copy of the production system that contains a table or set that is called customers.* I can add forms, reports and operations that are based on this table/set and then, after testing
      I can copy the files customers.* you mentioned into the production database folder.
      With the next shadow database update, these changes go to the users.

      Now one more question: where can I learn this in a text book, help file, alpha classes.... - as opposed to getting tidbits from forum requests?

      A chapter that says: Here is how you roll out new releases.


      Don't get me wrong, forums are great.

      Eriks

      Comment


        #4
        Re: Moving a form to another database

        Stan,
        Not necessary. When the database is next opened, the form will be read from the new dictionary files.
        I have found that whenever I do this, whether for a form based on a single table or one based upon a set, that nothing shows up in the database it was added to until the table/set is either manually added (right click white space while in the tab for Tables/Sets) or using xbasic's FILE_ADD_TO_DB(). Is there a step I am missing that would make this happen automatically?
        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


          #5
          Re: Moving a form to another database

          Originally posted by MikeC View Post
          Stan,
          I have found that whenever I do this, whether for a form based on a single table or one based upon a set, that nothing shows up in the database it was added to until the table/set is either manually added (right click white space while in the tab for Tables/Sets) or using xbasic's FILE_ADD_TO_DB(). Is there a step I am missing that would make this happen automatically?
          If the table on which the form is based was already in the application and the only thing you are doing is updating the data dictionary (<table_name>.dd*) files, then a MODIFIED form should automatically appear the next time the user opens that form - and I believe this is true whether or not the application is closed and reopened first.

          If there is a NEW form for an existing table, whether or not that new form will show up depends on where the code is that opens that new form and whether it was also updated. Again, I believe that in most cases this will work even without restarting A5 BUT you must "go back" far enough to get the new code as well. If the new code is on a button on a previous form, you would have to re-open that previous form in order to refresh it. If the code is called from a previous form but the actual code is in the Code tab, then the database's .al* files must also be replaced.

          Warning: Replacing the .al* files can also affect security settings (at least it used to but I have this strange feeling it may have been changed in newer versions - I haven't checked) and it will also affect the network optimize number (this is usually a benefit) and certain user created "saved queries" (in my experience, most users don't do this) and any setting you might have created with the A5_save_settings() command. If any of those things are an issue in your application, using an aex file for your code may be a better way to go. Another recommendation: If you use A5_save_settings(), try Registry.save_settings() instead.

          DISCLAIMER: I'm 95% sure of the above but I'm 100% sure that adding the new data dictionary files then restarting A5 will automatically pick up the new forms. (So far I've not discussed shadowing. That always requires restarting A5 - or at least the application - unless you've allowed your user some method of manually running a "refresh shadow" operation.)

          Of course, if the new form is also part of a NEW table or set that was not part of the application previously, then it won't show up until you take some extra steps. You have two choices:

          1.) Add the new table/set to the development version (which you've probably already done since it's rather hard to develop if you didn't) and copy the new .adb file to the active version. If the active version is networked, ONLY copy the .adb file to the main database. NEVER, NEVER copy the main .adb file to a shadowed workstation - this will wreak havoc on your application.

          2.) Add the new table/set to the control panel using something like this in the autoexec:
          Code:
           
          IF .not. ( "new_table_name" $ a5.table_enum() )
              file_add_to_db( a5.Get_path() + "\new_table_name.dbf"
          END IF
          Note that the file_add_to_db() function requires the FULL PATH AND NAME including the .dbf or .set extension. I use the a5.Get_path() function so it will work no matter where my user put the application.

          Also note that, again, the above does not apply to a shadowed application - a "refresh_shadow" is required in that case and the server version must be restarted first in order to update the A5 Control Panel - then the workstations can be refreshed.

          In case you're wondering, I prefer method #1.
          Last edited by CALocklin; 05-26-2010, 12:11 AM.

          Comment


            #6
            Re: Moving a form to another database

            So I did not miss anything apparently. Either manually or with xbasic when adding a table to a different database. Darn! I was really hoping I was missing something! :)

            Cal,
            Correct me if I am wrong, but when you say to add the adb to the database you are assuming that you have the exact same database but have added one or more tables/sets. Otherwise, adding a completely different adb would effectively destroy another database....right?
            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


              #7
              Re: Moving a form to another database

              Originally posted by MikeC View Post
              So I did not miss anything apparently. Either manually or with xbasic when adding a table to a different database. Darn! I was really hoping I was missing something! :)

              Cal,
              Correct me if I am wrong, but when you say to add the adb to the database you are assuming that you have the exact same database but have added one or more tables/sets. Otherwise, adding a completely different adb would effectively destroy another database....right?
              If I understand your question correctly, the answer is: "Yes, sort of."

              This part is correct:
              you are assuming that you have the exact same database but have added one or more tables/sets.

              My intent was that the base file name of the .adb file would be the same - the newer MyFirstApp.adb from the development computer replaces an older version of MyFirstApp.adb on the user's computer.

              If you added MySecondApp.adb to the same folder, it wouldn't do anything unless you tried to specifically open the new .adb file and then it would only use whatever was specified in MySecondApp.adb. If you didn't include the MySecondApp.al* files, then it wouldn't have any scripts, functions, or some of the things on the Operations tab - whatever operations are saved in the MySecondApp files (actually the .al* files in this case) rather than with a table or set - switch to detail view and look at the Operations tab to see which operations this would be.

              Adding MySecondApp.adb would not destroy anything in the original MyFirstApp.adb. If you opened MyFirstApp.adb it would still work just as it worked before.

              If I were really crazy (insane?), I could put every application I have from every customer in one folder - all the .adb files, tables, sets, and data dictionaries - and every one of them would still work. The only problem would be that I obviously couldn't have 2 different files with the same name in the same folder. If one application used a "Client" table and another used a different "Client" table, obviously they couldn't both be in the same folder at the same time. (Well, that wouldn't actually be the only problem. The other problem is that there would be so much stuff in one folder that I couldn't keep track of it all.)

              In other words, I agree with what you said up to the statement that "adding a completely different adb would effectively destroy another database....right?" The statement isn't strictly correct because it wouldn't do anything to the existing .adb file.

              The more I think about this, the more complex it gets...

              If you have an icon on the desktop that starts something like this:
              C:\a5v10\Alpha5.exe C:\Data\MyFirstApp.adb
              and you don't change the icon, it will continue to start that original adb file. Any other .adb file that is added to the folder won't do anything at all.

              Of course, if you change the icon properties to:
              C:\a5v10\Alpha5.exe C:\Data\MySecondApp.adb
              then it will attempt to run the "second" app and ignore the first. In this case, you will need to have the matching .al* files as mentioned above or there won't be any code and many operations may be missing.

              In fact, you could actually change the name of the current .adb file and its associated .alb, .alm, and .alx files, change the icon to match and everything would work just as it always did.

              If you delete the original .adb file and the matching .al* files then click the existing icon, A5 will recreate the .adb and .al* files but they will all be empty. It will be as if you clicked "Create a New Database".

              I'm not sure if this diatribe answers your question or not. If not, please clarify.

              Comment


                #8
                Re: Moving a form to another database

                Awww, I see a key point I did not make...an assumption I guess on my part . Apparently you, for some odd reason, cannot see my screen and such.

                I happen to work most times in projects that have the exact same adb name called QReportBuilder.adb. So in my case if I were to take one project's adb and overwrite another project's adb this would do as I indicated. Incredible how context can change one's view of how things are!!! :D

                I guess, if I had thought about it just a little bit more, most times the adb would be different for users projects/applications and so my scenario just does not apply to most users.

                (so much for my midnight goal to be off here again--I had just looked what felt like 15 minutes ago and saw that it was only 11:45...now is 1:30am. oh well.)
                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


                  #9
                  Re: Moving a form to another database

                  So to summarize:

                  For an easy update of a project where the tables stayed the same it would be safe to copy all *.DDD, *.DDM, *.DDX*.set, *.sem, *.sex
                  files to the production version and everything should work right away.




                  What I have not understood yet is the function of the *.dbf files that contain tables and sets.
                  Let's say I have added fields to an existing table, wouldn't I have to copy the corresponding DBF file too?

                  I would think this is true also if I added a new table which in turn will yield a new DBF file, but Cal only talks about copying the ADB and possibly AL* files:

                  Originally posted by CALocklin View Post
                  Add the new table/set to the development version (which you've probably already done since it's rather hard to develop if you didn't) and copy the new .adb file to the active version.

                  May I also come back to my original question: Which book do I have to read, which class do I have to go to where a chapter is:
                  "Best practices to roll out new releases"?

                  Thanks

                  Eriks

                  Comment


                    #10
                    Re: Moving a form to another database

                    If your tables and sets are the same, and you just need to copy a new form to a database that has the EXACT same table and set structure, I would STRONGLY recommend that you use Finian Lennon's Copy Object Utility. It is posted in the code archive. I have been using it for a while now and it has saved me an awful lot of time and anguish. The biggest thing about this utility is that you can copy just one object (form, browse, script, whatever) and NOT affect the remainder of the dictionary. There have been many times where I have copied a dictionary to a "production" database and found that I had some other form or report that got copied that wasn't quite ready for prime time.

                    The utility is simple and very well documented.

                    Give it a try.

                    Tom

                    Comment


                      #11
                      Re: Moving a form to another database

                      Thanks for the tip

                      Originally posted by Tom Henkel View Post
                      I would STRONGLY recommend that you use Finian Lennon's Copy Object Utility.

                      Any experience with Alpha 10 - it looks that at that time it was done and tested for 9.

                      Thanks

                      Comment


                        #12
                        Re: Moving a form to another database

                        Definitely do not ever limit yourself to just the version you are currently using--so long as you are aware of features that you may be using that are not in prior versions is all. DBF table structure has not changed (that I know of) in Alpha and so the method Finian uses to alter the database dictionaries still hold true.

                        Also, when searching the messageboard for solutions (more here than anywhere else!!), search ALL the forums.

                        Books.....there are a few, but for sure none that I know of that specifically addresses your question....but it HAS been discussed on the messageboard many, many times so the answers you seek are here....and when they are not, most times, someone here will provide one (with a money back guarantee no less!!). :)
                        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


                          #13
                          Re: Moving a form to another database

                          Thanks for the tip

                          Originally posted by Tom Henkel View Post
                          I would STRONGLY recommend that you use Finian Lennon's Copy Object Utility.

                          Any experience with Alpha 10? - it looks that at that time it was done and tested for 9.

                          Thanks

                          Comment


                            #14
                            Re: Moving a form to another database

                            I've been using the utility with V10 (including with V10.5) since V10's release and there are no new issues that I am aware of.

                            I've been meaning to do some revisions and bug fixes and, hopefully, will do so before too long. The principal bug is that, in certain circumstances, the "Select Object" window is not refreshed properly after a second or third copy operation. You no longer see a full list of objects in the dictionary and need to shut down and restart to properly refresh the "Select Object" window.

                            The latest release (for those interested) is attached to the message at

                            http://msgboard.alphasoftware.com/al...ad.php?t=79729

                            This posting, which contained an important fix (restored the ability to copy letters) has slipped to the second page of the code archive, while the original (outdated version) posting sits at the bottom of page 1.

                            I'm glad that people still find this a useful addition to the toolbox.
                            Finian

                            Comment


                              #15
                              Re: Moving a form to another database

                              Finian


                              I downloaded and installed your tool.

                              Now I am not quite sure what it does as compared to copy the files discussed above, like
                              .DDD
                              The table's data dictionary, which contains....

                              .DDM
                              Stores additional table objects ....

                              .DDX
                              Contains the dictionary's index(es). ....


                              Does it mean that if I select a table object to be copied that these files automatically are copied, too?


                              The roll up/roll down feature, I assume is taking the history of the tool to undo/redo actions..?

                              Thanks

                              Comment

                              Working...
                              X