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

Database Maintenance

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

    Database Maintenance

    I have searched, read and searched some more and am still confused about what options I should give my customer for running maintenance on their application.

    I am ready to ship them their new application and if I understand correctly, should I give them a button on the main menu to pack all tables (except the menu.dbf where the command is run from) and then another button to rebuild indexes? (Most likely, I will purchase Cal Locklin's rebuild index script)

    I always see references in messages suggesting to compact the database to ensure data integrity. Best I can tell, this isn't necessary for the customer to be able to do?

    Also, if I give them a button to pack the tables and then another to rebuild the indexes and they are run from a shadow copy, I assume they actually update the master tables on the server?

    Lastly, is it sufficient to run these from the standard action script functions or can anyone point me to modified versions that are more efficient?

    Thanks!

    #2
    Re: Database Maintenance

    Mark,

    I don't know how others do it, but . . .

    I have a Utility Menu passworded button on my applications that allow only admin people access. On the utility menu, there are certain tasks that are specific to the application, along with what I consider 'standard' utility functions (empty, pack, rebuild indexes, backup and restore).

    On one application, the HR entry person can select type and level of insurance an employee signs up for, but the administrator is the only one who can edit the insurance tables (ins. co, premium, level of coverage, etc.)

    The utility functions are necessary, but should NOT be available to all users.

    Dave
    Dave Jampole
    www.customalpha.com

    Women and cats will do whatever they want. The sooner men and dogs realize that, the happier they will be.

    Comment


      #3
      Re: Database Maintenance

      Originally posted by Mark Williams View Post
      I always see references in messages suggesting to compact the database to ensure data integrity. Best I can tell, this isn't necessary for the customer to be able to do?
      Correct. The database compact compacts the data dictionary in addition to packing all tables and updating (not rebuilding from scratch) the indexes. The customer should never need to compact the data dictionaries unless the customer is being allowed to edit the application itself.

      Originally posted by Mark Williams View Post
      Also, if I give them a button to pack the tables and then another to rebuild the indexes and they are run from a shadow copy, I assume they actually update the master tables on the server?
      The Table.index_create() function will create the index on the local machine. (At least it did in v5 when I built my Index_Rebuild routine.) My routine actually builds the index (.cdx file) on the local machine, copies the .cdx to the server, then deletes the one on the local machine. It does this because I ran into a problem on some systems where opening the table on the server and rebuilding that index directly didn't always work. So far, my method has worked every time.

      If you simply update the indexes with the <index>.Update() function or <table>.update_production_index(), I'm not sure what will happen but you can always try it and look for .cdx files in the shadowed folder. There should NEVER be a .cdx file attached to a shadowed table. (My guess is that it correctly updates the index file on the server but I'm just not sure.)

      However, if the Pack is run from the local machine it should correctly update the server because there is no data on the workstation anyway. The only thing that can be packed is the server.

      Originally posted by Mark Williams View Post
      Lastly, is it sufficient to run these from the standard action script functions or can anyone point me to modified versions that are more efficient?
      Since I almost never use AS anymore, I'll leave that one up to someone else.

      Comment


        #4
        Re: Database Maintenance

        Does packing the tables also rebuild the indexes or does this need to be run separately?
        Thanks

        Comment


          #5
          Re: Database Maintenance

          Packing rebuilds the indexes.

          It HAS to. When records are removed by packing, the indexes would need to be rebuilt because the records are now in a different location.

          And, according to my tests, the indexes are rebuilt by a 'pack' command even if there are no records to be deleted. (I suppose this could change sometime but last I checked it was true.) BECAUSE OF THIS, if you are dealing with really large tables and/or many indexes that take a lot of time to rebuild, you may want to set up the Pack routine to only pack the database if there actually are deleted records. That all depends on your needs - if you want the indexes to rebuild anyway, go for it. If there is no need to rebuild indexes and you just want to remove deleted records, then checking for deleted records first may allow the routine to run faster.

          In case you haven't noticed, there are always many options when it comes to databases. The trick is determining the best one(s?) for your situation.

          Comment

          Working...
          X