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



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

Deleting Table = Deleting Forms?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Deleting Table = Deleting Forms?

    Hi All,

    After deleting some of my tables and sets, I noticed that all my saved forms and browses were also deleted.

    Is it a normal behavior in AlphaFive?

    Thank you


  • #2
    Re: Deleting Table = Deleting Forms?

    Yup. Think about it a bit and it makes sense. When you design a form (any layout) you have to select a table or set to link it to. When the table or set is deleted, so are all the associated layouts. Some operations are also linked to the table/set and they would also disappear.

    If you have a backup (Rule #1 - Always make a backup - especially before deleting something. Rules 2,3, and 4 - see rule 1. It's a terrible comment on life but most of us have learned that the hard way.) you have two possibilities:
    1. You can restore the table AND all matching files - whichever ones exist - .dbf, .cdx, .fpt, .ddd, .ddm, .ddx.
    2. You could re-create the table then delete the "data dictionaries" (the .ddd, .ddm, and .ddx files for that table) and restore the original data dictionaries. (Not sure why you would want to do it that way but I suppose you could. I recommend #1 and just edit field structure if necessary.)

    The only other solution I can think of is to start from scratch and rebuild it all.

    FYI: Since a set is just a combination of tables, the only thing a set has is a data dictionary - the .set, .sex, and .sem files - these define which tables are in the set and how they are related plus they store the associated layouts and/or operations.


    • #3
      Re: Deleting Table = Deleting Forms?

      Thank you CALocklin.

      I do understand the logic behind it.

      But since a table is just a data source for the form, if the table is deleted, it would be more user friendly to have the obvious error message in every field and let the user change the datasource of the form to another table (just the way Access does).

      Since I rename/delete table often (I am dealing with a database of more than 100) and I put a lot of efforts in how my forms look, I just don't see the added value of the current AlphaFive method...

      Anyway, Thank you for the explanation!




      • #4
        Re: Deleting Table = Deleting Forms?

        "I rename/delete table often"
        Why??? I've been developing apps since A5v1 (about 1981) and have never had a need to delete anything other than temp tables which did not have any layouts attached. Maybe if you explained why you are doing that we could suggest a better way in A5.

        "it would be more user friendly to have the obvious error message in every field"
        Please no! I know of some tables with hundreds of fields. Don't make me answer the same question hundreds of times just to delete a table.

        "and let the user change the datasource of the form to another table"
        1. If you change the data source of the whole form in A5, then every field name in the new table will have to exactly match the field names in the original table.
        2. In A5 you can copy the layouts to another table or set but you have to do it before deleting the original. There are a couple built-in ways for a developer to do that 'manually' but there probably isn't any built-in method for doing that with code. I'm sure it can be done but it may require some rather advanced code. (I just can't imagine a situation where I would need to let a user do something like that. I suspect this is just a matter of different ways of doing things in A5 vs. Access.)

        There was also a third-party utility created by Jim Chapman some years ago that allows developers to send individual layouts to customers for updates. This might be adapted to a more automated process. But I think you should try explaining the reason you are deleting and recreating tables first and let us try to find a better way in A5.


        • #5
          Re: Deleting Table = Deleting Forms?

          "I rename/delete table often"
          My bad: I should have written "I rename table very often". True indeed that deleting tables occurs less often.
          I rename tables as the database grows out of convenience, giving them prefix to find them faster in the control panel.
          I would occasionally delete a table when I simply don't need it anymore. But I may still want to keep its related forms for its design elements.
          Please note that I am not a developer working on a defined specification documents but rather designing applications to optimize my daily activities. Hence the many modifications/change of directions.

          "it would be more user friendly to have the obvious error message in every field"
          Sorry I did not mean having these annoying "pop up messages" but simply to have a "N/A" (or whatever) in each field and give the user the freedom to select the datasource again.
          If the name of each field does not match then he could simply change the source of each field individually as well.

          "and let the user change the datasource of the form to another table"

          My bad again: by "user" I meant "developer" (I'm not a native English speaker as you probably already noticed! ;)
          (basically same point as the previous one)

          By the way, after renaming a table, I suppose it is also normal that the related sets are not automatically updated with the new table name?

          Thank You



          • #6
            Re: Deleting Table = Deleting Forms?

            Originally posted by jakircevic View Post
            I'm not a native English speaker as you probably already noticed!
            Actually no - I hadn't. Your grammar wasn't perfect but I've seen a lot worse from "natives".

            I'm not sure but it sounds like you've figured out that you can rename a table by right clicking on the table name and selecting "rename".

            Originally posted by jakircevic View Post
            IBy the way, after renaming a table, I suppose it is also normal that the related sets are not automatically updated with the new table name?
            Correct. In this case I've usually duplicated the table (with data, field rules, and/or indexes as appropriate), modified the set to use the new name, then deleted the original table. I believe this is also likely to mean you will have to modify any the fields on the layouts that belonged to the old table.

            Reminder: Don't delete the original table until after modifying the set or you will have to go back and "reduplicate" the table to the original name in order to even open the set.