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

[Peter.Greulich]

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.

[Allen Klimeck]

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.

[SNusa]

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

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.")

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)

[Peter.Greulich]

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

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...

[Raymond Lyons]

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

[SNusa]

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

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!)

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.

[DaveM]

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.

[SNusa]

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.

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."

[CALocklin]

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.)

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.

[SNusa]

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.

[BillA]

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.

[SNusa]

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.

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......

[kkfin]

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

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

[Wesolson]

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

[Wesolson]

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?