New call-to-action
Page 2 of 2 FirstFirst 12
Results 31 to 53 of 53

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

  1. #31
    Volunteer Moderator Peter.Greulich's Avatar
    Real Name
    Peter Greulich
    Join Date
    Apr 2000
    Location
    Boston, MA
    Posts
    11,656

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

    Robert,

    ddd/ddm/ddx are associated with a table.
    set/sem/sex are associated with a set.
    alb/alm/alx are associated with the database or workspace - i.e. the adb.

    There is no alb/alm/alx for a table.

  2. #32
    Member
    Real Name
    Allen Klimeck
    Join Date
    Apr 2000
    Location
    Colorado
    Posts
    549

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

    If you click the link in my post you will see:

    Alpha Five File Types

    What we now call a workspace was a database.

  3. #33
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

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

    Quote Originally Posted by Allen Klimeck View Post
    The .alb, .alm, and .alx "support files" are the workspace files.

    http://wiki.alphasoftware.com/Alpha+Five+File+Types
    Quote Originally Posted by aschone View Post
    No.

    Table1.alb, table1.alm, table1.alx files DO NOT exist for a table.
    ^^ Seeing these two responses after Peter's "nice catch" response "woke me up." ~ I was "zoning" file names, and not on the particular extensions. ("After the drop", I was still seeing files (in the a5 backup screen) beginning with the "a" letter. ~ I was "zoning." When I took a look at Allen's link, I instantly realized "something was off.")

    Quote Originally Posted by Peter.Greulich View Post
    Robert,

    ddd/ddm/ddx are associated with a table.
    set/sem/sex are associated with a set.
    alb/alm/alx are associated with the database or workspace - i.e. the adb.

    There is no alb/alm/alx for a table.
    ^^ And this one made me realize exactly where I went wrong. (I actually knew this, but was "too focused elsewhere" to think straight.)

    Thanks guys for "setting me back on course!"

    Had I chosen a database named "TEST" and had three tables named ONE, TWO, and THREE: I could have preserved my integrity here.
    "Tunnel-vision" got the best of me here. Being "lysdexic" doesn't lhep either.....

    I became "a little too caught up in thinking the dropped tables were not dropping the table support files" that I failed to see my error, given the file names, directory names & database name.

    ~Even though I still think the option to grab the entire database via a persistent "include all files" setting should exist in the built-in a5 backup. (case in point: the "stupid" mistake I just made "looking at a list of file names", but not really "seeing them"): It's time to go hide and stick my own head in the sand. (or get some eye drops maybe)
    Last edited by SNusa; 01-31-2013 at 09:17 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."

  4. #34
    Volunteer Moderator Peter.Greulich's Avatar
    Real Name
    Peter Greulich
    Join Date
    Apr 2000
    Location
    Boston, MA
    Posts
    11,656

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

    Quote Originally Posted by SNusa View Post
    It's time to go hide and stick my own head in the sand. (or get some eye drops maybe)
    In situations like this, I have a shot of Old Grandad . Not suggesting you do that, just saying...

  5. #35
    "Certified" Alphaholic
    Real Name
    Raymond Lyons
    Join Date
    Apr 2000
    Location
    Carlsbad, CA
    Posts
    2,143

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

    I swore I wouldn't comment on this after my last post, but I just have to point out that any developer worrying about this problem (which in my opinion is still not a problem!) could have spent 1/10th the time all of us have spent on this to write their own zip backup routine within Alpha Five to do what I assume Robert wants. I am not going to do it here because I think Robert and those who agree with him can learn something valuable doing it themselves. There may be other ways, but all anyone needs are the following 4 functions:

    A5.GET_PATH() 'If using shadow you may have to adjust--look it up!
    FILEFIND.GET() 'Use wildcards and "FILE_FIND_NOT_DIRECTORY" flag if you don't want sub-folders
    COPY_FILES() 'copy the files into a temp folder--as Dave said, needed if someone has something open
    ZIP_FILES()

    Have fun, and please let this horse, hamster, pig, etc. die and RIP. I for one am done with it.

    Raymond Lyons

  6. #36
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

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

    Quote Originally Posted by Peter.Greulich View Post
    In situations like this, I have a shot of Old Grandad . Not suggesting you do that, just saying...
    ~Thinking I need 2 shots.... (Much thanks (again) for the "bangs over the head!" .....This record was definitely "skip-p-p-p-ping.")

    ~And thank you Raymond. (I can generate the code. Listing those functions saves me time searching/digging for the right functions!)

    Code:
    dim vc_FileList as C = filefind.get(a5.Get_Path() + "\*.*",FILE_FIND_NOT_DIRECTORY,"N")
    dim vc_DirList as C = ""
    dim vp_EnumValue as P
    
    showvar(vc_DirList) 'show enumerated files in directory
    
    for each vp_EnumValue in vc_FileList 'loop through list
    	vc_DirList = vc_Dirlist + chr(10) + vp_enumValue.value 'regenerate list instead of copying....
    next
    
    showvar(vc_DirList) 'testing output
    
    'copy_files() 'to temp
    'zip_files() 'to combine & compress
    end
    Got it. Thanks.
    Last edited by SNusa; 01-31-2013 at 11:14 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."

  7. #37
    "Certified" Alphaholic DaveM's Avatar
    Real Name
    Dave Mason
    Join Date
    Jul 2000
    Location
    Hudson, FL
    Posts
    6,047

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

    Don't forget to delete that temp folder you copied to once all has been completed. Most every workstation can do this on a server and have a copy on their computer(pw protected of course) or you can designate only certain user machines/people/groups or..... or.... where it is saved.....

    It may take us extra time to make this and test it, but it is the end product that counts. Maybe you can put it all in the code archive when you get it completely done and tested.
    Dave Mason
    dave@aldadesktop.com
    Skype is dave.mason46

  8. #38
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

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

    Quote Originally Posted by DaveM View Post
    Don't forget to delete that temp folder you copied to once all has been completed. Most every workstation can do this on a server and have a copy on their computer(pw protected of course) or you can designate only certain user machines/people/groups or..... or.... where it is saved.....

    It may take us extra time to make this and test it, but it is the end product that counts. Maybe you can put it all in the code archive when you get it completely done and tested.
    Valid point. One thing I should have also stated previously is: This thread was not about being able to create a backup/zip solution. It was about the built-in backup functionality, and not needing to "re-invent the wheel" (or require the use of 3'rd party tools) to "completely" backup a "project container."
    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."

  9. #39
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

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

    I gave up on reading this whole thread but here's my take on it.

    Yes, it's good to warn people about the limitations of A5's built-in backup. No, it's not a bug - it's just the way it is.

    Before Alpha added their own built-in backup, I created one of my own so I've never used Alpha's other than for a few tests long ago - I quickly decided mine was better. Mine is broken into two - one for the "Data" and one for the "Application". This allows the customer to run data backups as often as needed without wasting time/space backing up exactly the same application files every time. If they have to restore their application files they can just re-install from the original install package. My Data version copies ALL tables, indexes, and memo files in the main application folder whether listed in the A5 Control Panel or not. (The original reason for that was because I sometimes included tables in the folder that were not in the A5 Control Panel but that's another issue and I won't go into the details of 'why' here.) By default, it has the limitation that it does not copy any tables that might be located outside the main folder even if they are listed in the A5 Control Panel because I never build applications that way. The Application version copies almost all other files in the main application folder - basically all .dd*, .se*, .al*, .adb, .aex, help files, text files, and graphics files but I know it doesn't include PDF files.

    Both versions have the ability to copy additional files/folders by including them in a special text file that the routine reads. The backup routine itself uses one of A5's built-in zip functions and it can zip the files even if someone is using the database - and, so far, I've never had any problem as a result of doing that. Restoring files can be done by unzipping them manually or by running the "restore" option in the backup routine - which is what I normally do because it's much faster if I'm already in the application. The routine works with ANY A5 database if you install it in your Addins_installed folder and then just type bkup_data_zip() or bkup_app_zip() in the Interactive Window or add a 'backup' icon to your system toolbar. I made it work like that for any database - i.e., with no need to "install" it to each application - so developers like me that often end up debugging/reviewing someone else's database can quickly and easily create a backup before editing anything. More importantly, I do install it to every application I create so I can run a backup at my customer's location when editing data or the application locally - I've had problems with customer backups and never, never, never trust them anymore. Installing it to a specific application consists of putting the aex file in the application folder (not their Addins_installed folder for reasons that are too long to go into here) and loading it using the Load_library() command.

    Anyone could recreate it because I'm just using built-in A5 functions. However, I'll warn you that, in order to make it generic and handle as many issues as I could think of, there are 8,555 lines of code in my addin - 9,200+ if you include comments. (I created a free code_size addin a long time ago that was used to get this line count.)

    Anyone that wants more info on my routine can go here. This one is not free for those that want to purchase it but there may be ideas there for anyone interested in creating their own. (Disclaimer - I just looked at that web page and it's really out of date. The last update was when v9 came out. It basically works the same but the page needs to be updated - when I have the time. It does work for all versions of A5 from at least A5v5 through A5v11.)

    Quote Originally Posted by SNusa View Post
    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....
    I recommend using the Object_Import and Object_Export routines created years ago by Jim Chapman. I'm sure they're still available somewhere on this board; probably in the Code Archive. I use them quite often even for sending updates to some customers. I've even used them to copy forms, etc. from one version of A5 to another. WARNING: If you find them, use the latest version. The first version only handled a limited number of layout types but later versions include scripts, functions, menus, toolbars, and all layout types. HINT: For customer use, I even added a routine at the end of my Object_import routine that prompts them to increment the network optimize number and they can choose to accept the default new number, change it, or leave the existing number unchanged.

    Disclaimer: I suppose it's possible that the Object_Import/Export routines don't copy everything in the latest version of A5 but, based on what I know, I don't think it should be a problem and I've never found any issues yet.

  10. #40
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

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

    Thanks Cal for the info. I am going to start "adding features" to my a5 install, which will include some of yours. (I had already purchased an addin from CSDA last year, but had fallen into the "too much too soon" scenario. That's about to be added back too.)

    I never cease to be amazed when I encounter these "holes/omissions/odd behaviors." (I'm even more surprised with the responses I frequently receive from both Alpha & many "gurus" on these issues.) ~ Working with the underlying "data structures" of an a5 databases, and moving objects between "containers" has exposes some very surprising (and unexpected/unpredictable) results. (Things you might never experience unless you are working with a5 at the "database container level.")

    Looks like lots of developers take it upon themselves to fix these issues by writing their own code/solutions. (instead of confronting Alpha) It's very interesting & noble that this capability is even possible in a tool like this. (Nevertheless, if Alpha is not doing implement things like this on their own, they should, IMHO, be licensing these fixes/enhancements and paying the developers for their effort in solving "program deficiencies."

    The one I uncovered & you referenced above (export/importing an .a5pkg, ie. a "form") literally amazed me. (When importing an object, a5 places it in the wrong database that is not even open [after telling you the object already exists in the "open" database], unless you rename the other database directory after export.) That's definitely not a "limitation." It's a bug, and should be corrected by Alpha! (Maybe it has been.) ~ I reported this, but never specifically received a reply.
    Last edited by SNusa; 02-03-2013 at 01:03 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."

  11. #41
    Member
    Real Name
    Bill Abraham
    Join Date
    Sep 2006
    Posts
    48

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

    Call things by their right names. A backup is not a backup unless
    it backs up everything.

  12. #42
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

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

    Quote Originally Posted by BillA View Post
    Call things by their right names. A backup is not a backup unless
    it backs up everything.
    I"m pleased to see someone else agrees. ~ Only solution is to use 3'rd party tools and avoid the "built-in features" like this one... Alpha has "added the kitchen sink" to a5 desktop. Unfortunately, everything (the a5 code-base) is only "88~98% there." (Lots of longtime users will go to the ends of the earth to defend this product, and it's a shame really! (Because, if "things like this" were not tolerated, a5 would be an even better product.)

    It's also worth mentioning: Don't even try to export/import layouts (ie. forms, .a5pkg) from "one workspace to another" if they're both located on the same computer. The import routine adds a second copy to the original workspace that isn't even open. (unless this has been fixed.) ~ The workaround is to temporarily rename the export workspace directory name (after export, but prior to import.)

    While I'm on the subject:
    If you try to rename (and/or duplicate & drop) the original set, and you have a layout (ie. a form) based on that set which includes a "stand-alone (named) browse." If that browse is based upon/includes the top (parent) table of the set you just renamed..... You will have to edit the browse control properties (on the form), to reflect the new name of the set. (Properties of the browse control (on the form) incorrectly reference a set that is no longer present.) Note: There's a second (related?) bug here too... After clicking on "OK" to save the updated properties, you will notice that "selecting the correct primary table" resulted in clearing the "Used named browse" selection. You have to go back to properties a second time, and select the "Used named browse." (unless this/these problems has/have been fixed, which I doubt)

    The only "uses" for the built-in export/backup features (IMHO) are to either 1.) "Test" whether you have all the objects (files) present in the control panel (ie. you have not dropped the wrong table/set by accident.) ~ Dropping objects just hides them from both the CP and the built in backup routines. It doesn't effect their usage via code. So in reality: You could drop an important table, and have "database" still work fine. (Until you try to restore it from an a5 generated "back-up.") AND 2.) Sending files to someone......
    Last edited by SNusa; 03-24-2013 at 07:39 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."

  13. #43
    "Certified" Alphaholic kkfin's Avatar
    Real Name
    Kenneth
    Join Date
    Dec 2006
    Posts
    1,578

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

    Quote Originally Posted by SNusa View Post
    I"m pleased to see someone else agrees. ~ Only solution is to use 3'rd party tools and avoid the "built-in features" like this one...
    Let see what is already in my list:

    Do not use in Alpha:
    WYSIWYG -EDITOR
    DBF (UTF8)
    FTP
    CSS EDITOR
    SQL TOOLS
    ..and BACKUP

  14. #44
    Member
    Real Name
    Wesley J. Olson
    Join Date
    Nov 2006
    Location
    Minnesota
    Posts
    27

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

    OK Im in trouble. Seems invoice sets with tabs did not get backed up correctly. I have a backup folder that has many set functions, specifically invoices, and they are in zip format created by alpha5 backup. When I attempt to unzip I get only a file with a .a5bak suffix. Alpha does not recognize this to restore. AM I in deep do do here, or is there a solution to recover these zip files?
    Please respond someone, getting worried.
    Initial backups were just folder backups, and they were missing files when I had computer issues and rebooted a5v12.
    Wes

  15. #45
    Member
    Real Name
    Wesley J. Olson
    Join Date
    Nov 2006
    Location
    Minnesota
    Posts
    27

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

    Seems my set info is also corrupt, and zipped in a file that I cannot recover. HELP!
    How can I recover a .a5bak file?
    Last edited by Wesolson; 09-13-2017 at 03:56 PM.

  16. #46
    Member
    Real Name
    Wesley J. Olson
    Join Date
    Nov 2006
    Location
    Minnesota
    Posts
    27

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

    Steve, Is the info I have in my .a5bak files unrecoverable?
    Wes

  17. #47
    "Certified" Alphaholic Stan Mathews's Avatar
    Real Name
    Stan Mathews
    Join Date
    Apr 2000
    Location
    Bowling Green, KY
    Posts
    25,119

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

    The a5bak files are only useful for restoring prior versions of layouts, not an entire set.

    In the control panel, forms tab (for example) highlight a form name based on a set, right click, choose Restore Prior Version.
    There can be only one.

  18. #48
    "Certified" Alphaholic Mike Wilson's Avatar
    Real Name
    mike wilson
    Join Date
    Apr 2005
    Location
    Grand Rapids, Michigan
    Posts
    4,229

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

    For goodness sakes. Put the app and data under your applkication folder and back up your entire database application and app data all together (code attached). It will save you countless hours as it has me, all the time!! I go back to prior backups all the time, easily (usually when I screw something up). I back up our app, which we named URSA (UNIVERSAL RESOURCE SHARED APPLICATION), almost everything every night, and keep the last 10 backups. Our app is 16 GB and growing and takes ~ 11 minutes to back up (time to backup in the script). It has
    tables 200
    forms 133
    UDFs 1128
    Scripts 87
    Operations 47
    Reports 84
    Labels 14
    Browses 17
    Folders and files holding PDF, TXT, DOC, XLS, JPG, and others - alot, maybe 4000 at this juncture.

    Save yourself by saving it all!
    Attached Files Attached Files
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

  19. #49
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,492

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

    The Help Text for V11 and V12 says that the Backup works at the Database Level. It has not been updated.
    A dropped table is still in the Database so I believe it should be backed up. If you don't want it, delete it.
    When you back up a SQL database, just because a table isn't being used doesn't mean it is excluded.
    It does NOT say at the Workspace Level, which I suppose it should but then updating a User Help is not the most exciting thing in the world when you are not expecting to support it for much longer.
    A lot of us have been around long enough to take a complete Folder backup before messing with stuff, but new users might be in for a bit of a shock when they find a dropped table - still in the database - won't restore.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  20. #50
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

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

    Quote Originally Posted by Ted Giles View Post
    A dropped table is still in the Database so I believe it should be backed up.
    I have to disagree with you on this. I believe the "database level" means in it's in the A5 control panel. A table or set that has been dropped would still be in the "folder level" but not the "database level".

    Disclaimer: I'm about 2 weeks behind right now so didn't take the time to verify this but I'm 99.9% sure this is the case - or at least was in earlier versions. That's part of the reason I built my own AIMS A5 Backup addon.

  21. #51
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,492

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

    A Database is defined as a collection of data. That includes all used and unused tables.
    Database Management System is Alpha. That is the Workspace.
    So when Alpha offers to backup a Database, it really means it is backing up the DBMS.

    I know it's only semantics, but as Rob Tucker - who started this and is certainly no dummy when it comes to Alpha - found out, the text in the guide book can or may be be misleading to a new user.
    Once you have a few Alpha Callouses, you roll with the punches.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

  22. #52
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

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

    FWIW, Ted and I are saying the same thing about how the backup works. The terminology has been changing over the years and that adds to the confusion. For example, what Alpha is now calling the Workspace used to be called the Database.

    In addition, I just checked and, by default, the built in backup still only selects the tables/sets listed in the A5 Control Panel - whether in the main folder (where the .adb file is) or not. In other words, according to Alpha's semantics the "database" (now the "workspace" but the term probably hasn't been updated everywhere it's used) is just those files that are listed in the control panel whether they are in the current folder or not. This makes sense because you could actually have multiple applications (or 'workspaces' or 'databases' depending on which terminology you want to use) in the same folder.

    You can add other files to the backup as long as they are in the main application folder or a subfolder of the main application but that requires you to create the list of additional files.

    CAUTION: If you have your application in the "E:\MyApplication" folder but one or more tables listed in the A5 Control Panel is, for example, in the "C:\Something_else" folder, that file in the C:\Something_else folder will be included in the backup BUT it will be restored under the "E:\MyApplication\Something_else" folder.

  23. #53
    "Certified" Alphaholic Ted Giles's Avatar
    Real Name
    Ted Giles
    Join Date
    Aug 2000
    Location
    In the Wolds, Louth, Lincolnshire, UK
    Posts
    4,492

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

    Caution comment above.
    Good catch Cal.
    Ted Giles
    Example Consulting - UK
    .

    http://ec12.example-software.com//
    See our site for Alpha Support, Conversion and Upgrade.

Similar Threads

  1. "Add" and "Save" buttons don't stay on "Self" page
    By Scholin in forum Application Server Version 8
    Replies: 2
    Last Post: 02-05-2008, 07:50 AM
  2. Can One-Step backup be run "silently"?
    By smrogers in forum Alpha Five Version 7
    Replies: 2
    Last Post: 04-06-2006, 11:09 AM
  3. Error "cannot backup this file" Help Ple
    By Leslie Blades in forum Alpha Five Version 5
    Replies: 13
    Last Post: 07-20-2003, 01:57 AM
  4. Tools menu "Zip" problem
    By fairviewcomputing in forum Alpha Five Version 5
    Replies: 3
    Last Post: 10-19-2002, 08:27 AM
  5. Generic "Basic Data Entry" tools?
    By Rose Edwards in forum Alpha Five Version 4
    Replies: 6
    Last Post: 03-06-2002, 12:33 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •