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

CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

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

    #16
    Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

    Wow Robert
    Personally I dont agree or disagree with your view or any others. Simply, it works that way.
    Drop a table everything related will probably be lost on next startup.
    Shift/delete in explorer - likewise, The warning that it offers is no help, you know you just requested it.
    Before you drop a table - you have the option to simply zip it (rightclick, zip)
    Isn't everything you need available in that zip?

    When you really (and mostly) choose to drop a table it's because you want it and all that goes with to be gone. Otherwise you will bloat your app,

    Comment


      #17
      Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

      Originally posted by Ray in Capetown View Post
      Wow Robert
      Personally I dont agree or disagree with your view or any others. Simply, it works that way.
      Drop a table everything related will probably be lost on next startup.
      Shift/delete in explorer - likewise, The warning that it offers is no help, you know you just requested it.
      Before you drop a table - you have the option to simply zip it (rightclick, zip)
      Isn't everything you need available in that zip?

      When you really (and mostly) choose to drop a table it's because you want it and all that goes with to be gone. Otherwise you will bloat your app,
      Yes it is. Actually one thing I should have mentioned in my post above is why I actually began using table duplication in the first place.
      I had remembered this early this morning before seeing your reply. ~ And it does add sound reasoning as to why I began doing this!

      Originally I began duplicating sets and tables in this manner NOT as a rudimentary form of "versioning." ~ It was a defense against the possibility of form corruption!
      I had kept reading how other users were experiencing "form corruption" here on the forums for reasons unknown. (The "versioning" idea/usage became an "afterthought" after realizing another usage for dropping tables & sets.) And now, whenever I try new things, am worried about "breaking something" I automatically employ this duplication method. It's a lot quicker and easier to recover/undo/restore from a mistake quickly. (Without having to involve making backups etc.) ~ Also I have made a mistake and/or broken something which I don't immediately realize, there's some fallback.

      I find this technique extremely "forgiving" with the exception of a wrong dropped table (still in use) not being included in the backup after I test an application. And that is the underlying reason for my post here. Not being able to backup all objects in the "workspace container" makes the built-in backup routines useless for me.
      Incidentally, I'm not sure the problem of form corruption still exists, because you don't hear about it anymore. But I don't want to find out the hard way!
      (There were instances where indexes were being truncated too, which still continues to this day. We know the scenario for this now, but I didn't back then. All I did was read warnings.)

      Making backups of the set and tables seemed like a very smart idea in this regard. You could always back up a set/for and the drop it.
      If a layout ever became "corrupted" you always had another good one to fall back on!

      And yes, dropping the set or table keeps everything nicely and safely hidden from view. ~ Adding it back anytime has always worked without incident.

      I also have to add a "knock on wood" to my good fortune regarding never loosing data in all those years! (not superstitious, but this is one topic I take very seriously.)
      Last edited by SNusa; 01-31-2013, 09:42 AM.
      Robert T. ~ "I enjoy manipulating data... just not my data."
      It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
      RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

      Comment


        #18
        Re: CAUTION: Reliance upon the built-in a5 backup tools can be a "risky" proposition!

        Thread reminds me, I swear, my sister keeps all the emails she wants to retain, in her Outlook Deleted folder. She manually moves all new emails from the Inbox to the Deleted Items box, then manually deletes the ones she wants to purge, leaving the desired email in the Deleted Items box. She does this because she does not like the idea of making a bunch of, or even one, subfolders under the Inbox.

        For everyone else in the world, the Deleted Items folder = "gone". And so with Dropped Tables, the term Dropped = "gone" -- except in Alpha. So in a way, it is a problem with the term "Drop". Alpha should have used a different term like "Detach Table/Set".

        In IT, the term "drop" means "removed", "gone". The fact that Alpha happens to have "Drop-remove from project, but retain" and also "Delete-remove completely", is an anomaly that exists because tables/sets can be in the project folder, but not "part of" the project.

        But the Alpha Backup clearly says "Back up Workspace". The Workspace does not, by definition, include "dropped" objects.

        Here is a definition of Drop from the Internet:

        Drop (a table) : Removes one or more table definitions and all data, indexes, triggers, constraints, and permission specifications for those tables.

        Alpha treats tables and sets differently than other components like grids, dialogs. With the later, if they are present in the project folder, they are part of the project. With tables/sets they have to be officially "included in the project". If you simply copy a table into your project folder, they are not part of your project until you go through the process of adding, or un-Dropping them.

        In SQL, all tables, views, etc., are part of the project automatically. In SQL, Drop means Remove, Delete, "gone forever".

        But this discussion is esoteric, it is what it is. And because of what it is, you need to use a 3rd party back up system to back up your files. I use Cobian Backup on all of my machines for local and to FTP them off site. I also use Carbonite and a local NAS that I guess I am supposed to grab in case of fire. Another good Developer-friend of mine on this forum likes the "lucky as hell" method because he happend to email me their major project a few months before their only copy was stolen along with their laptop.
        Steve Wood
        See my profile on IADN

        Comment


          #19
          Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

          There is not doubt that Robert is right in this case.

          When Alpha changed the term from database to Workspace things changed. We don't backup databases we backup workplace and workplace is a folder(workspace) .

          Some of us are using SQL some of us are using dbf some of us are using NoSQL databases. Backup is Backup
          Backup should be similar experience to all users regardless what database they use. But now Alphas backup does some sort of cleaning when using DBF. DBF developer has to understand that their backup is different than backup for others not using DBF.

          Comment


            #20
            Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

            Ken, I think you're mistaken.

            On the desktop side the "workspace" can include tables located in more than one directory. "Workspace" really means "Project". In this context it does not have anything to do with directories.

            Comment


              #21
              Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

              Originally posted by Tom Cone Jr View Post
              Ken, I think you're mistaken.

              On the desktop side the "workspace" can include tables located in more than one directory. "Workspace" really means "Project". In this context it does not have anything to do with directories.
              Odd but I understand this. I also understand that most of them who use SQL server or MySQL server do not install it to the "workspace".

              Comment


                #22
                Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                As Steve and others have said, it is best to use a commercial backup. For most this is the best way to go.

                I prefer to make my own and have done so. I get all the tables and other files I want whether someone has them open or not. It is 2 stage because the first step is to completely copy whatever folder(s) desired and then backup the folders including only the files I want. It is more work, but very satisfying.
                Dave Mason
                [email protected]
                Skype is dave.mason46

                Comment


                  #23
                  Re: CAUTION: Reliance upon the built-in a5 backup tools can be a "risky" proposition!

                  Originally posted by Steve Wood View Post
                  For everyone else in the world, the Deleted Items folder = "gone". And so with Dropped Tables, the term Dropped = "gone" -- except in Alpha. So in a way, it is a problem with the term "Drop". Alpha should have used a different term like "Detach Table/Set".
                  How about the term "hidden." (or "partially lost but not totally forgotten tables/sets") Because in many instances, that's the "net result." (It may be detached from the "virtual workspace" but it's not detached from the "workspace container." ~ Which also surprised me. (Now we have two slightly definitions of what is supposed to essentially be the same thing. ~ Especially in the specific scenario I encountered and considered to be a "bug." (Which in essence also has implications when using the term "workspace" itself.)
                  There are many hidden capabilities (treasures) hidden below the skin of a5. I suspect it's he process of "exploring and finding these hidden treasures" that ultimately results in my ability to perpetually expose "previously undocumented bugs and anomalies." (I'm never satisfied just taking for granted that "things" work or don't work. I always strive to understand why!)

                  Possibly what I consider to be a problem with the built-in backup tools (due to the way in which I use table dropping/adding) should have been classified by me as "limitation." Nevertheless, changing this (as described) would have no negative implications that I am aware of. (only positive ones)

                  Interestingly enough: After dropping a table, it is only the .dbf file that is actually excluded by the built-in a5 backup tools!!! During my exploration of using wildcards to "re-include" dropped tables, (which cannot be done, you have to select individual files which also precludes the selection of an entire directory) I noticed the following: Although the table's .dbf file is not included, the .alb, .alm, and .alx files are still included in the built-in a5 backup zip even after the table is dropped!?!?!? (Until just now, I had not realized this was the case! How bizarre?) ~ This fact alone should "raise a few heads here."

                  Ironically, the zip has everything needed to re-create the dropped table, except for the actual table data itself. But without the .dbf, the rest of the files that are preserved are useless in terms of reconstruction capabilities! ~ (Unless I'm missing something else here, you can't re-create the the table when this one single piece is missing!) ~ What is the logic for this? ~ Does this make any sense? Why would/should this be?

                  Because of this: I'm "reverting" to my original assumption/conviction and "viewpoint" on this matter! ~ (That the backup routine should not only be modified, but may need to be fixed as well?) ~ And that there may in fact be something wrong here?!?!?!
                  Now I'm thoroughly "perplexed" over this entire ""topic of debate!"............... Anyone?
                  I'm also glad I pursued this. (after reading the initial responses) ~ As I still may have something to learn here.


                  NOTE: Ignore faded content above. (Thinking about the "larger issues", I failed to notice a few "minor" details: Like the names of the files I was looking at. Hence my observations (and statements in gray) are/were incorrect.) ~ Had a "PICNIC"
                  Last edited by SNusa; 01-31-2013, 10:54 PM.
                  Robert T. ~ "I enjoy manipulating data... just not my data."
                  It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                  RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                  Comment


                    #24
                    Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                    Originally posted by DaveM View Post
                    As Steve and others have said, it is best to use a commercial backup. For most this is the best way to go.

                    I prefer to make my own and have done so. I get all the tables and other files I want whether someone has them open or not. It is 2 stage because the first step is to completely copy whatever folder(s) desired and then backup the folders including only the files I want. It is more work, but very satisfying.
                    "SOUND JUDGEMENT!" And I agree wholeheartedly.
                    Last edited by SNusa; 01-31-2013, 10:59 PM.
                    Robert T. ~ "I enjoy manipulating data... just not my data."
                    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                    Comment


                      #25
                      Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                      Robert,

                      I wrote my backup routine before alpha had one. I swore they copied me to an extent, but found it was actually different. I have since varied my routine to making a copy of the whole app folder before the zip operation(zip the copy). My users are able to press a button and it gets done. If it is backing up a server app, it knows to do that instead of the work station.

                      I do not and never have relied on alpha for their backup or their security and sign on.
                      Dave Mason
                      [email protected]
                      Skype is dave.mason46

                      Comment


                        #26
                        Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                        The .alb, .alm, and .alx "support files" are the workspace files.


                        http://wiki.alphasoftware.com/Alpha+Five+File+Types

                        Comment


                          #27
                          Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                          Good catch, Allen.
                          Peter
                          AlphaBase Solutions, LLC

                          [email protected]
                          https://www.alphabasesolutions.com


                          Comment


                            #28
                            Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                            Content removed by user. Due to error above, question is irrelevant.
                            Last edited by SNusa; 01-31-2013, 11:05 PM.
                            Robert T. ~ "I enjoy manipulating data... just not my data."
                            It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                            RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                            Comment


                              #29
                              Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                              Originally posted by SNusa View Post
                              Dropping table1.dbf leaves table1.alb, the table.1.alm, and table1.alx files in the backups, without the table1.dbf.
                              No.

                              Table1.alb, table1.alm, table1.alx files DO NOT exist for a table.
                              Andrew

                              Comment


                                #30
                                Re: CAUTION: Reliance upon the built-in a5 backup tools is a "risky" proposition!

                                Originally posted by aschone View Post
                                No.

                                Table1.alb, table1.alm, table1.alx files DO NOT exist for a table.
                                I'm going to re-check after dinner. (I had just tested this with three tables, a, b & c.) ~ I could have sworn they did!

                                I stand corrected. "The drop" dropped everything.... I was working with someones example database which contained tables named a, b & c. Added to the confusion, the database example itself was named (not by me) "adb_a.adb." (And on top of that, this database also contained contained sub directories (containing merged databases) named a, b & c! ~ It was originally an example of combining/merging databases.

                                The table names were simple so I chose it. (Nevertheless I undoubtedly picked the wrong example database to test on.) ~ Looking foolish here......

                                "Everything began to look the same." ~ OOPS!

                                Snap 2013-01-31 at 18.13.07.png
                                Last edited by SNusa; 01-31-2013, 07:23 PM.
                                Robert T. ~ "I enjoy manipulating data... just not my data."
                                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                                Comment

                                Working...
                                X