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

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

    Please pass this around, because a5 developers backups (using .dbf's) may be at risk of being USELESS!
    My thoughts on the following matter is: "You can't fix stupidity, but you can (and should) take precautions!"

    I recently uncovered what I consider to be a "bug." And in combination of the way the internal a5 backup tools behave, this essentially means (at present): It is IN FACT 100% possible, & plausible to create a backup (of a 100% functional and working .dbf database/program) that is missing table(s). ~ All a developer needs to do (to find himself/herself in this "unfortunate situation") is to do is drop the wrong table accidentally and not catch the mistake. (There is no warning that this has happened, until the backup is needed after a catastrophic failure.) ~ In which case, it's too late! The restored database will be missing these tables along with all the associated support files!

    PROOF OF RISK/THREAT:
    1.) Create 2 related tables.
    2.) Generate a set from these tables. (Build a form from this set, use the wizard if you wish & save the form.)
    3.) Next, drop a table (heck, drop both of them!)
    3.) Run the form, double click on the set, view/edit the set. ~ Everything appears fine and the form still runs.
    (Because although the tables were dropped, they are still physically located in the database directory.)

    Note: Since there are no layout objects based solely on these individual tables, nothing but the tables disappear from the CP & the database is still 100% functional.

    Now backup the entire (100% working database) and take a look at the zip!
    You'll find the backup (zip) does not include these tables & their associated "support files." (because they were dropped "accidentally.")

    ~ Hence a restored database (although it ran 100% fine just prior to making the backup) cannot be restored from this zip.
    ~ In this instance, there are no warnings. (And in a "loaded" control panel, this is a very plausible possibility, give the lack of organizational tools.)


    The consequences of this, when combined with the fact that the built-in a5 backup tools do NOT have a default setting (or any setting for that matter) to includes dropped objects leaves a developer with a potential disaster and thus IMHO creates unnecessary risk. ~ Incidentally, this is something I had recommended last year, for essentially this same reasons, before I uncovered this scenario even existed.)
    I had also recently suggested, that (in absence of folder organizational control within the control panel) that "color coding" (assigning color attributes to individual objects via right click) be added to provide some sort of visual organization/cues. ~ It's easy to "loose things" (and make mistakes like dropping the wrong table) as the CP fills with a lot of objects present. (After duplicating objects, color coding may also eliminate the need to drop some of these objects in the first place.)

    Bottom line: "A developer should NOT & can NOT rely on the built-in backup routine in a5 (on a self contained & fully functional WORKING .dbf database) to re-generate a completely restore-able copy of the database."
    Unfortunately, Selwyn doesn't consider this a bug! (Nor does he consider it a problem, and thus there are apparently no intentions to address this.)
    I had hoped (expected actually) that Alpha Software's business philosophy included taking "reasonable initiatives to protect user data" whenever possible.


    CHECK YOUR DATABASES & BACKUPS TO MAKE SURE YOU DON'T HAVE ANY "DROPPED TABLES THAT SHOULDN'T HAVE BEEN DROPPED!"
    Last edited by SNusa; 01-29-2013, 10:09 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."

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

    Why would it be a bug to not back up tables that you dropped? Also, pretty much everyone on this forum has recommended not using the Alpha backup for many years. Not because of the table issues, but because it is purposely designed to be incomplete; although it has been so long I cannot remember the details. But I know it only backs up what it considers part of your project. Back when it was invented, there weren’t as many good (and free) backup and zip systems out there. I think we’ve all just been zipping our projects up since version 7. I use Cobian Backup (free) for all backups.
    Steve Wood
    Join the ALPHA DEVELOPERS NETWORK
    There is no Cloud. It's just someone else's computer.
    Web - Mobile - Hosting - Products - Frameworks - Developer Resources
    AlphaToGo | IADN (100% Alpha Anywhere Websites)

    Comment


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

      I agree with Steve. Backing up a "database" is not the same thing, nor should it be, as backing up a "database folder".

      Comment


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

        Originally posted by Steve Wood View Post
        Why would it be a bug to not back up tables that you dropped? Also, pretty much everyone on this forum has recommended not using the Alpha backup for many years. Not because of the table issues, but because it is purposely designed to be incomplete; although it has been so long I cannot remember the details. But I know it only backs up what it considers part of your project. Back when it was invented, there weren’t as many good (and free) backup and zip systems out there. I think we’ve all just been zipping our projects up since version 7. I use Cobian Backup (free) for all backups.
        It may in fact not be a bug Steve. But to leave a "gaping hole" like this in the built-in backup tools is merely asking for trouble. And a setting (which includes dropped objects by default) is a very reasonable and precautionary solution. ~ It would do wonders to protect developers against risk too! (Not everyone knows the backup tool should not be trusted.)
        Based on your assessment (which I was aware of for years), Alpha would be better of to remove the backup tools completely, so nobody (unaware that they are unreliable in certain circumstances, which to most are "vague" at best) looses precious data & work unexpectedly. Imagine the surprise when someone realizes their backups are useless, after it's too late. (And there is no working backup of the backup which was presumed "OK.")

        Besides, if it can't be trusted, it shouldn't exist in the first place. (I would imagine the mere fact that it still exists knowing this could be construed as gross negligence!) ~ "Knowing it isn't reliable is not an acceptable excuse." ~ Not when irreplaceable data is involved
        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


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

          I don't see it as usless, it is a backup of (and only of) your Alpha Five app, which would not include dropped tables. If you restore from your backup, you will get everything that is/was part of your Alpha application. I also just fount it too cumbersome and stopped using shortly after I started.

          In case anyone else missed the advice, don't use the built in Alpha Five backup. Instead use an off-the-shelf zip or other backup system.
          Steve Wood
          Join the ALPHA DEVELOPERS NETWORK
          There is no Cloud. It's just someone else's computer.
          Web - Mobile - Hosting - Products - Frameworks - Developer Resources
          AlphaToGo | IADN (100% Alpha Anywhere Websites)

          Comment


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

            But if you are going to use it, then have the discipline to add all files to the adb from the control panel!! before backing up.
            Cole Custom Programming - Terrell, Texas
            972 524 8714
            [email protected]

            ____________________
            "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

            Comment


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

              To not build in precautionary measures to protect irreplaceable data is for lack of a better word "insane." The entire philosophy with much of a5's internal code is to preserve data, not "loose it." ~ Take for instance editing and removing buttons from embedded browse fields. ~ Remove the button and the event (along with the code) remains.

              In on breath, you're saying "don't use the built in routines." In the other you're supporting the very reason you suggest not using them.

              Where do these backup import/export problems end.... Here's another one I reported just last week.

              An exported form layout (.a5pkg) can not be imported into a new database IF the the old database (from which it was exported) is also located on the same machine. What ends up happening during (attempted) import is: A second instance of the layout it added to the original database that isn't even open. Just prior to this, the import routine incorrectly indicates the layout already exists on the open database, even though it doesn't. The screen captures at bottom is the screen show what comes up, and what should come up. If you temporarily rename the database directory from which the .a5pkg was created, the import process will work as expected & you get the second screen.

              Snap 2013-01-23 at 12.28.33.png Snap 2013-01-23 at 11.09.23.png
              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


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

                Originally posted by martinwcole View Post
                But if you are going to use it, then have the discipline to add all files to the adb from the control panel!! before backing up.
                If you never realized you "dropped the wrong table" (aka made a mistake) by accident, all the discipline in the world is not going to save you here. (And that's what I'm implying here. ~ People make mistakes, and mistakes go unrecognized. And in this case, the mistake result in data loss without warning, which goes "unrecognized" until it may be too late.)
                ~Just look at the a5 GUI itself. (I am forever uncovering "nooks and crannies where" it doesn't "work" as expected.) ~ "The little bugs."

                Since there is no official bug tracking (or list of what works and what doesn't) using a5 largely comes down to "trial and error" (and luck) ~ It shouldn't be this way, and that's the underpinnings of what's really wrong here. ~ Anyone can make excuses (and justifications) to their hearts content. But it isn't going to fix the problem.

                "Complacency is not the solution. It is the problem."
                Last edited by SNusa; 01-29-2013, 11:02 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


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

                  Originally posted by martinwcole View Post
                  But if you are going to use it, then have the discipline to add all files to the adb from the control panel!! before backing up.
                  Try telling that to someone who "had no idea" that the backup routine doesn't necessarily recreate a backup of a 100% functional .dbf database, AFTER it is too late!

                  ~ABSOLUTELY RIDICULOUS. ("RECKLESS" may be a more appropriate & descriptive word to use here.)
                  Last edited by SNusa; 01-29-2013, 11:12 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


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

                    I lost forms and reports early in A5 when I began to look at v7 and v8 - there was a warning.
                    I learned that it is what it is, and subsequently always MAKE BACKUP/S BEFORE doing any housekeeping.
                    If anything, keeps me on my toes. Not too worried about that.

                    Comment


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

                      Robert,

                      I don't see this as a shortcoming of Alpha at all. Dropping tables/sets is a useful & productive function in A5 that I have used many many times. If you drop a table, it's no longer in the adb definition and it doesn't get backed up - rightly so in my view. And, yes, I too have accidentally dropped a table or two and wondered what the heck was going on. But I use A5's backup utility daily. Martin and others are right when they say the developer has an obligation to be aware of what he is doing - including catching mistakes, and we all make mistakes.
                      Peter
                      AlphaBase Solutions, LLC

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


                      Comment


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

                        Originally posted by Peter.Greulich View Post
                        Robert,

                        I don't see this as a shortcoming of Alpha at all. Dropping tables/sets is a useful & productive function in A5 that I have used many many times. If you drop a table, it's no longer in the adb definition and it doesn't get backed up - rightly so in my view. And, yes, I too have accidentally dropped a table or two and wondered what the heck was going on. But I use A5's backup utility daily. Martin and others are right when they say the developer has an obligation to be aware of what he is doing - including catching mistakes, and we all make mistakes.
                        Dropping & adding tables is extremely useful. And that is the basis for my reasoning. I use the feature frequently. Nevertheless, I guess I'm outnumbered on this one....

                        Irrespective, logic still leads me to believe that: Backing up a 100% functional .dbf database (all contained together) should result in the creation of usable backup (or at least provide the ability to generate a fully recoverable copy.) ~ If the database wasn't working as expected prior to generating a backing up, I suppose I might see things differently....
                        Because: "An ounce of protection is worth a pound of cure." (And I'm extremely cautious with regards to data preservation.) ~ So I still believe a persistent checkbox (to include all dropped objects in the backup) is still a worthwhile suggestion/request. "That's my story, and I'm sticking to it!"

                        I still feel "good" about presenting this "warning." (Even though many of you disagree & are privy to this limitation of the built-in backup tools, not everyone is!) ~ And I sincerely hope the ones who don't already know about this "limitation" read this thread for their sake, "before it's too late." (I myself will not be using the a5 internal backup again for anything. I believe in eliminating potential hazards like this whenever possible. And my track record over the past 30 years behind a computer ("knocking on wood" as I type this reply) reflects this.

                        Alpha still needs to address the import/export bug regarding .a5pkg (with forms & possibly all other objects too), so that it works as expected. (when both the export and the import database reside on the same computer)
                        Last edited by SNusa; 01-29-2013, 01:01 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


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

                          Originally posted by Peter.Greulich View Post
                          Robert,

                          I don't see this as a shortcoming of Alpha at all. Dropping tables/sets is a useful & productive function in A5 that I have used many many times. If you drop a table, it's no longer in the adb definition and it doesn't get backed up - rightly so in my view. And, yes, I too have accidentally dropped a table or two and wondered what the heck was going on. But I use A5's backup utility daily. Martin and others are right when they say the developer has an obligation to be aware of what he is doing - including catching mistakes, and we all make mistakes.
                          Peter question: Since you also use dropped tables & use the backup routines, how do you test to make sure you haven't dropped a table in error?

                          Running the database won't show any errors in the scenario I depicted. (Nor do I don't believe there is any test for this, since the code still finds what it needs in this scenario of a dropped table.) ~ A table that only exists in a form based on a set. (When the dropped table has been embedded in a browse via a "non stand-alone embedded browse?)

                          If there was a test, and/or the code failed... Or there was some other way to catch this error, (other than staring at a CP full of tables), I might feel differently ~ It's the notion that there is no "test" or way to check for this mistake (under these circumstances) that has me concerned.
                          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


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

                            Originally posted by SNusa View Post
                            Peter question: Since you also use dropped tables & use the backup routines, how do you test to make sure you haven't dropped a table in error?

                            Running the database won't show any errors in the scenario I depicted. (Nor do I don't believe there is any test for this, since the code still finds what it needs in this scenario of a dropped table.) ~ A table that only exists in a form based on a set. (When the dropped table has been embedded in a browse via a "non stand-alone embedded browse?)

                            If there was a test, and/or the code failed... Or there was some other way to catch this error, (other than staring at a CP full of tables), I might feel differently ~ It's the notion that there is no "test" or way to check for this mistake (under these circumstances) that has me concerned.
                            Sorry, but I don't get it. 1) As Steve said, if this bothers you that much, use a zip utility or other backup program that gets everything in the desired folder(s). 2) How can a competent developer drop a table "in error"? Possible, I suppose, but if so it would have to be an extremely rare occurrence, and if worried about it, see the previous sentence. 3) Developers who choose to use the A5 backup utility surely know they have dropped a table 99.9999% of the time, and when they do it is a simple matter to add it to the backup using the Additional Files button, which can include any file in any folder. Not a big deal assuming the developer is half way competent.

                            So again, I don't get it, and it's not a bug nor even a problem worth losing sleep over.

                            Oh, and BTW, zip files and third party backups are also not 100% foolproof either. I am sure I am not the only one who has tried to restore such a backup only to discover that the backup file was corrupt. Nothing is risk free.

                            Raymond Lyons

                            Comment


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

                              Originally posted by Raymond Lyons View Post
                              Sorry, but I don't get it. 1) As Steve said, if this bothers you that much, use a zip utility or other backup program that gets everything in the desired folder(s). 2) How can a competent developer drop a table "in error"? Possible, I suppose, but if so it would have to be an extremely rare occurrence, and if worried about it, see the previous sentence. 3) Developers who choose to use the A5 backup utility surely know they have dropped a table 99.9999% of the time, and when they do it is a simple matter to add it to the backup using the Additional Files button, which can include any file in any folder. Not a big deal assuming the developer is half way competent.

                              So again, I don't get it, and it's not a bug nor even a problem worth losing sleep over.

                              Oh, and BTW, zip files and third party backups are also not 100% foolproof either. I am sure I am not the only one who has tried to restore such a backup only to discover that the backup file was corrupt. Nothing is risk free.

                              Raymond Lyons
                              Hi Raymond.

                              With computer data, I have one philosophy with regards to data preservation which has never let me down in the ~35 years I've been behind a computer. Take every reasonable precaution possible. (To do otherwise is both foolish & ignorant IMHO. Nevertheless ~ I still continue to "knock on wood on this one.") ~ I've worked with a ton of (my own) data (which included backing it up on a daily basis) over the years.... So much so, that my signature at screen bottom jokingly makes reference to this.

                              Consequently, it does bother me, and I do use a third party tool. (I had just begun using the built-in one because I found it convenient. But due to the possible scenario I uncovered, I have since returned to my old ways.) ~ And I have little doubt, that someday (if it hasn't already happened) some developer (or end user - have you thought about that possibility) will experience a catastrophic yet 100% avoidable data/database loss as a result of the way the built-in backup "works." It won't be me, but it will happen to someone. And the clock is ticking...

                              To be brutally honest, I can't see many scenarios where backing up only "some of the workspace" would be logical anymore. (Particularly when most developers are connecting to external databases to get to the data via active links.) I can see that someone would want to perform a backup without including the entire "workspace" when a project is finished, and you want to "clean out all the junk." But then you need to restore it elsewhere to check it first. (More on this explained below, see #2.) And there are other scenarios too such as not wanting to backup/send a directory full of graphics.

                              You ask how and why could this dropped table/data loss scenario occur to a conscientious/competent developer? I can think of a few scenarios:
                              (I know when I'm "beating a dead horse" but I'm going to reply nevertheless.)
                              1. Possibly a developer uses dropping and adding as a means to "temporarily" to clear up the CP workspace since there is no built in organizational tools. (I recently suggested a "right click" option to "color code" the names of individual objects in the CP.) It's a great idea, but impractical on the desktop side (was the response I received) due to the age of the "C code" the CP is built from. I wouldn't be surprised if this feature shows up in the web CP, because unlike the "old stuff", it is based on Xdialog.
                              2. Another possibility is the way in which developers may be using dropped sets and tables. It's an extremely powerful capability likely understood & underutilized by many. I tend to use this feature as a "backup/versioning mechanism." Duplicate the table (or set) and add the date stamp ie: 130130 to the end of the table/set name before dropping the new duplicate with the date encoded name. (Which also drops the associated layouts from the CP. ~ aka. quick and simple versioning) This may not be a perfect solution, but it sure works in lieu of CP folder support, and or being able to color code object names as suggested above. ~ Using this methodology, I am much more susceptible to making a mistake in the event I need to restore back to older versions. (It's a toss up. Duplicate and drop, or live with clutter in the CP which offers no organizational tools on it's own with the exception of simple object name sorting.) Note: In this scenario, I would actually use the backup routine (in it's present form without backing up dropped objects) to "strip" the "workspace" of unnecessary/ancillary objects as a method of "cleaning up." (I would also test the results for completeness.)
                              3. I'm sure I could come up with a few other scenarios too. There are some interesting (albeit possibly non-conventional) ways in which dropping and adding tables can be used within the a5 environment. (The above two are what come to mind.)


                              Honestly, I have yet to hear a single logical reason from anyone as to why a settable (persistent) option to backup the entire workspace should not exist! (I'm going to go back and check the posts above, but I don't think I missed anything.) All I have heard thus far is that it is not a bug, and that any "competent" developer should be held accountable for his mistakes. (I see it as justification to accept things as they are. So be it. ~ Well, we agree to disagree.)

                              Also, nobody has provided a single reason as to why it is even a bad idea! Nor has anyone explained a test to check for dropped tables (still used in sets) that would alert the developer as to a mistake like this. I presume "there is no test." So if you don't catch something like this @ 2am while the CP is staring you in the face and you're groggy eyed, you could get yourself into trouble with no warning. ~ "An ounce of precaution is worth a pound of cure."

                              And while I find it rather humorous that nobody sees the "significance" (or the possible threat this presents) here, I certainly won't loose any sleep over it. But when I run into things like this, it reminds me of why this planet is so messed up. (To me, this is more a case of "exercising good judgement," and not about developer competence, or lack thereof.)

                              Irrespective of all this: I don't see any harm in backing up the entire workspace (or at least having an option to do so). Isn't this a primary reason that people rely on 3'rd party tools instead? ~ Most data is stored elsewhere via active links anyways. Even if this (external linked data) is not the case, it's still an option which could be turned on/off. Besides, most databases are not that large, and storage is insanely cheap. Better to be safe than sorry is how I see it.

                              All I can see are the potential benefits, and not one single negative. I just don't get it......

                              PS: I'm well aware of the corrupt zip thing. (I validate them for an added measure of safety.) ~ Back in the late 80's, early 90's there was a utility suite called "PC-Tools." ~ Amazingly enough, it actually (in some strange instances) totally omitted backing up a single file in a directory. Even worse, it validated everything fine, and never saw the missing file, even during the compare/validation process. I caught this omission only after about 6 months of backing up live data from my first business. (A ton of data.) ~ Fortunately, I never had a failure during that time period!

                              As for using the "add additional files" option, that's a PITA IMHO. You have to know what is missing in order to add it back. Although you brought up an interesting idea/workaround: Possibly I can use "a wildcard" (persistently) there to "force add" all the contents of the directory and accomplish what I want. ~ I'm going to "take another look" at the "add additional files" options with regards to using wildcards.... NOPE, Not an option. No wildcard support there.

                              Regarding it being simple to add back that .0001% of the time a mistake occurs. (FYI: Your statistics are way off here, but I'm sure you were exaggerating to make your point.) It's simple to "add back" only if you realize the mistake prior to loosing the original workspace where the database exists. What you're also failing to take into consideration here is this: Even if a client is making backups of his data with 3'rd party tools, they may have been instructed to use the a5 backup tool to backup the "a5 workspace" separately. Under this scenario, it's plausible that (because of this along with active links to data elsewhere) they won't have a copy of the "entire workspace" (which includes the dropped tables) when a catastrophic failure occurs. (Especially if the original developer were to disappear from the scene.) It's quite easy to imagine "Murphy's law" in action, where there may be no backup in existence of the "complete workspace" to rely on. (Even when 3'rd party tools are used for "workspace" backups.)

                              This whole ordeal has taught me something with regards to "workspace terminology." When developing, "the workspace" essentially represents the objects that both the developer (and a5 alike) should have access to from within the control panel. But when a database runs, the "workspace" takes on a different meaning. It then encompasses the entire directory, which includes dropped tables, all files & sub directories etc.). ~ During development, a5 has "control of the usable workspace." But during runtime, "the computer's filing system (the directory itself) acts as the workspace boundaries. Incidentally, this difference is supportive of the concept that dropped tables are merely tables which are "hidden." And hidden tables are still seen as database objects during "runtime." ~ Just an added "random afterthought" here.....
                              Last edited by SNusa; 01-31-2013, 09:24 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

                              Working...
                              X