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

Updating the master database

  • Filter
  • Time
  • Show
Clear All
new posts

  • Updating the master database

    My question is probably a simple one, but Iím a newbie. I built a database that Iím serving over a network. I used ďCreate Install PackageĒ to build my ďsetup.exeĒ (application files only) and ran the executable on my server. I placed the files in a shared folder. I then installed the Runtime software on a workstation, opened it up, and connected to the application files in the shared folder. Whew!!! Felt great.

    My question is about what I should do when I want to update the master copy on the server. From what Iíve read, I think I have an idea, but want to confirm before I do it. I think Iím supposed to
    1) Add any edits to the original database application using the developer software.
    2) Get the data from the server folder into my latest version of my application.
    3) Use ďCreate Install PackageĒ again to make a new setup.exe (application files only).
    4) Hereís where Iím asking for help: I think Iím supposed to delete ALL the files in the shared folder on the server, then run the setup.exe again on the server and select the shared folder again.
    5) Update shadow databases

    Is that correct? From what Iíve read on the message boards there are many A5 geniuses doing all kinds of sophisticated procedures with variables, automated tasks, and rocket launching codes, and unfortunately, itís way beyond my present skills. For now, Iím just looking for a basic way of doing things so that I can make my application available to my coworkers ASAP. I figure Iíll learn the other stuff later when Iím not under the gun for time.

  • #2
    Re: Updating the master database


    What I do is:
    1) Do full backup of your server using A5 backup/restore off the Tools menu
    2) Backup just the application files on my development machine using A5 backup/restore under Tools menu
    3) Restore these application files only from my development machine to the server, again using A5 backup/restore under the Tools menu
    4) Under Tools on the server, Network Optimize, increase the version number, then the network user's PCs will automatically refresh their shadow database the next time A5 is started

    Hope this helps



    • #3
      Re: Updating the master database

      Thank You! That gave me a whole new way of thinking about how to work with the application files on my developer machine and server. I didn't know I could open up (and apparently edit?) the database files on the server using the software on my developer machine. So, does that mean I can make changes directly to the server files? I ask this because I'm anticipating having to make small changes to my tables periodically (e.g., add a field) and this would save some steps.

      Also, when i use the "Create Install Package" (application files only) and run the setup.exe on my server, what is the setup.exe doing? From what I've read, it sounds like it's extracting a copy of my data and application files into the folder i choose. Is there anything else going on? The IT guy at work (who protects the server with his life ... and I'm glad he does because all my other stuff is on there!) wants to know. :)


      • #4
        Re: Updating the master database

        Ray, the "install maker" in A5 do not do "alot" more than copying the files. Your IT guy can relax. :)

        If you select the "app only" it will not copy your data files (dbf etc).



        • #5
          Re: Updating the master database

          That setup.exe made by alpha is a zip file made into an exe thus self extracting. If you purchase a zip utility, you can make your own. Alpha add a couple other files into it to keep things straight. If you do choose to use alphas utility, it will copy your dbf's into that exe. be careful!

          I do server every day. When I redo my app on my computer(not changing table structure), I simply copy the support files(everything but the dbf and fpt files) to the server copy. The adb sent over has a newer optimize number so the shadows get updated. If I change a tables structure, there are more steps.

          I prefer to copy these files manually if possible. It just makes me feel better.

          If you are allowed, you can run the server app from your own computer and you should have access to the folder to do as you have to. If not, the IT guy should be able to set you up for a day or so where you only have access to that one folder.
          Dave Mason

          Skype is dave.mason46


          • #6
            Re: Updating the master database

            Thank you. This clears things up a lot.


            • #7
              Re: Updating the master database


              You will notice that alot of the "forum crawlers" :) use Astrum to create their installers. Now I am not saying that you have to, but it certainly makes things easier for me. It also forces you to research and understand the A5 file type etc better.



              • #8
                Re: Updating the master database

                If you are going to install or update to another location somewhere, astrum is a BIG plus. If you are doing this in-house, there should be no need for it.
                Dave Mason
                Skype is dave.mason46


                • #9
                  Re: Updating the master database

                  I noticed that but didn't know how cool it was. Ok, I'm working in-house now but definitely will look at Astrum when i reach the next level. Thanks.


                  • #10
                    Re: Updating the master database

                    Another popular installer is Install Creator Pro. I do believe it can do everything Astrum does but in addition the makers have a companion software called PatchMaker which works well too.
                    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


                    • #11
                      Re: Updating the master database


                      Read up on file types in the Help file under Alpha Five File Types.

                      Read it carefully and understand what each file type does and how that applies to updates. In particular, understand that the DBF and FPT files contain actual data, the CDX files contain the indexes for the DBF and FPT files, and the .DD* and .SE* files contain your "application" (forms, reports, code, etc.)

                      Also, the .AL* files contain any global scripts and functions AND security settings plus a few other "A5 settings" (and saved queries?) which may or may not affect any given application. If you are using A5's user security and copy the .AL* files from one system to another, all those settings will go with that copy. For a local application where security settings and other settings seldom change, this may not be an issue. For a generic application sold to many different users, this can be a huge issue. (Which is why I "roll my own" rather than using A5's security. I also save my "settings" in text files.)

                      Note that CDX files should almost always be considered part of the data and NOT changed when an update is copied from one system to another. HOWEVER, one method* of adding new indexes would be to copy the new CDX file(s) to the production system AND immediately run an 'Index Update' routine to rebuild them to match the actual data. If you copy the CDX files from the development system to the production system and don't update them immediately, the data will appear to be completely scrambled on the production system. The CDX files don't just contain the definition of how the indexes are generated - they actually contain a "list" of where each record is found.

                      Whenever you change indexes or edit table structures as part of an update, there are "a lot" more things to consider. (George, look up "alot" in your dictionary. It doesn't exist in my US dictionary. It is always two words.:)) This is especially true if you are copying the updated files from your development machine to the server. If you edit these things directly on your server, it's less of an issue but you still need to be careful. In most cases you will be OK changing these things directly on the server IF you never re-arrange the fields in your table but only add new fields at the end or change the size/type of existing fields. If an existing field is no longer needed, I recommend leaving it as-is and ignoring it. Hard drive space is cheap.

                      *Re: Changing index definitions:
                      There are a few ways to do this and some prefer one method while others prefer something different - it's mostly a matter of personal preference. I prefer never to copy CDX files. I use an Index_rebuild_auto() function that doesn't just update indexes but actually rebuilds them to their original definition. If the definitions change, I have a routine that actually reads the definitions on my development machine and rewrites the "rebuild" function to the new definitions. (takes 9 seconds on my system to rewrite the function for about 55 tables with 100 separate index definitions which results in about 1800 lines of code) I can then add a routine into my Autoexec script that forces this routine to run the first time the app is started on the production system - based on a date in a text file that is updated once the index update runs. Or, in some cases where I have confidence in the user, I just tell the user to run the index rebuild routine (which is always added to the Utilities menu of every app I build) immediately after installing the update.

                      The other common method is to keep a copy of the original CDX files and create a routine that copies them to the production folder then runs an Index Update to get them up to date with the current data. If the index definitions are changed, a new set of "original" CDX files are created.


                      • #12
                        Re: Updating the master database

                        Hmmm, I see I have much reading to do. As a newbie, managing indexes is uncharted territory for me. Thank you loads for making me aware of it, because it looks like it's critical. Also, thanks for the suggestions of installers.


                        • #13
                          Re: Updating the master database


                          Everything here is for setting within the lan. When sending updates to another location where I won't be there. It has to be exact and done completely right or somebody can't work. It takes a lot more coding to make sure things are done just like I am sitting there. You can't depend on someone doing as they are supposed to for the update, so it has to be automated. I will test this on my lan, then at least 2 others before shipping.

                          A database compact will rebuild all your indexes, so set it up to run this by way of a button maybe. It will keep you from worrying about those cdx files. I never worry about those. Alpha seems to catch them up real good. I always do a compact on the db after a redo of anything. Read my post above to see what not to copy over to the server. you can skip the cdx files if you want.

                          My indexes are sparse and pretty straight forward. Never seem to have much problems there. People who try to use them as heavy filters/queries seem to have more problems.

                          Don't discount anything Cal said, he is very smart. Others on here can pass me by too.

                          Can you get access to the server app so you can do your work there? I do minor changes on the server. If I change a table, I do it there(duplicating what I did on my own machine in some cases). this way, when I copy the support files over, it all works. Yes, I have erred a few times, but mostly, it works real well. I always keep a completely current copy of the server app on my work computer and another that is being changed.

                          My backup copies the server app(complete) to my computer. This is done before my fumble fingers go to work. I can swap it back if I make a real bad error.

                          You will be ok. It is always good to be friends with the it guy. If he knows what you are doing, he can open the necessary doors for you.
                          Dave Mason
                          Skype is dave.mason46


                          • #14
                            Re: Updating the master database

                            Thank you! Didn't know compacting also rebuilt my indexes. That will make things much easier. All you guys are incredibly helpful! These ideas are going to save me from many headaches. Thank you.