Moving a form to another database

[Finian Lennon]

Re: Moving a form to another database

All you really need to know about data dictionaries and the utilities I developed is the following. A single data dictionary, that is, the combination of the ddd, ddm and ddx (or sem, set and sex) files, is that they are representative of dbf tables, contain records which represent any object that can be used in Alpha, and can be manipulated in the same way that any other table can. In other words, don't even think about selectively copying individual data dictionary files from one location to another. All you will get is a mess.

So none of the data dictionary files get "copied" during a copy operation. The data dictionaries are opened as tables and selected records, representing the selected objects (forms, scripts, operations, menus, toolbars etc) are appended from one table to another. The target "table" is then restored as a data dictionary and the "copy" is complete.

[Tom Henkel]

Re: Moving a form to another database

Erika,

the tool copies individual objects from one dictionary to another, not entire dictionaries. If you need to add a new table to a database, that is an entirely different thing.

The roll up / roll down feature just "hides" the dialog or "shows" the dialog.

I would suggest you try it with some object, say an append opperation, to see how it works. Select a table from your development system as the source, select a table from your production system as the destination, and then click copy. Another dialog will appear that shows you the "append" operations that can be copied. select one and then click OK.

You will get the feel of the routine pretty quickly.

Tom

[eblaschka]

Re: Moving a form to another database

Also, when searching the messageboard for solutions (more here than anywhere else!!), search ALL the forums.

Books.....there are a few, but for sure none that I know of that specifically addresses your question....but it HAS been discussed on the messageboard many, many times so the answers you seek are here....and when they are not, most times, someone here will provide one (with a money back guarantee no less!!). :)

Mike,

I appreciate the money back guarantee.

Wikis and forums are great, but the bigger they get, the more unwieldy and you can spend hours reading in threads that contain the keyword(s) but not the answer.

I would think that a step by step instruction how to best keep a production system running while working on a development system and
then when ready to update the production system as save and quick as possible, should be lined out ( as a sticky ???) by some of you Gurus, Wizards and Alphaholics).
Especially if there seems to be no other documentation.

Just for the benefit of all of us.

[MoGrace]

Re: Moving a form to another database

Finian,
This utility looks great. I keep a development copy of my app on my workstation but the main app is on a server. Will this work for updating the server files too from my desktop? And I take it when you say backup you mean both app copies? btw I had to close Alpha and restart to get the utility to appear - I suppose that is normal procedure? It showed Ok in the Addin Manager but would not perform til I did. Just closing and reopening the App didn't do it either.

[Finian Lennon]

Re: Moving a form to another database

Hi Robin:

Yes, all that matters is being able to select the path in the source and destination boxes. I've used it across a LAN and from Citrix Servers back to my development machine. As to backups, you can never have too many, so backups to source and destination are always a good idea.

[CALocklin]

Re: Moving a form to another database

I would think that a step by step instruction how to best keep a production system running while working on a development system and
then when ready to update the production system as save and quick as possible, should be lined out ( as a sticky ???) by some of you Gurus, Wizards and Alphaholics).
Especially if there seems to be no other documentation.

Just for the benefit of all of us.

I've considered doing that a number of times and many of us have posted much of the info on the message board. The things that keep me from doing it are:
- It takes time.
- It can get very complicated if you want to get into all the details of the various options and their ramifications.
- My preferences aren't necessarily the same as those of other developers.
- There are many ways to accomplish the same thing.
- We have no way to make it sticky here and I have no idea where to put it so people could easily find it in the future. (In other words, the questions would continue anyway.)

Here are my "pearls of wisdom". They are not necessarily hard and fast rules - just things to consider when updating applications.

1. I never copy a "production" table from a customer to me, modify it, then send it back anymore. I consider this too risky because I once did that and somebody didn't get the message at the customer location and updated something while I was editing the file. Now I either make the necessary changes at the customers location (this is very, very rare for me anymore and IF I do it, it's usually through remote access) or I add a routine in their autoexec that adds any new fields needed or restructures existing fields. I never delete old fields and new fields are always added at the end of the current table.

2. I use Finnian's Object_Import/Export routines on occasion (I just sent one to a customer last night) but ONLY if I am absolutely, positively, indubitably, and without any question certain that I did not make any other changes. One possibility for the "any other changes" would be a change to a table structure. A more insidious "any other change" is the one(s) that I forgot about - and this used to happen more times than I care to think about. It makes me angry that I have to take the time to fix my update and it makes the customer angry also.

If I have spent more than a couple hours making changes, I will usually send the whole application as an update. That way I don't have the, "Oops! I forgot that I changed that script also" problem. Then the inevitable next issue like, "Oh crap! Yes, I added that new field you wanted but I did it two days ago and forgot to send you the new form."

In general, my customers never change anything in the application - only the data. Therefore, I can send them the complete application every time and not worry about overwriting anything. I think you can create an application backup using A5's built-in backup routine but I have a more complex simpler method (ya like that combination?) that I think works much better - at least for me. I use a third party program to build an "update installer" file. The "complex" part is that it takes a bit more to create the original install definition and the "simpler" part is that it is much easier to use for future updates once that initial set up is complete. I just tested the time it takes to create a new update routine for my most complex app and it was 9 seconds including the time it took me to open the third party program and select the saved definition. The only downside to this method is that the install file is a little larger than may be necessary. But think about it, would you rather spend 10 minutes trying to cut 5 megabytes out of the the install file and risk making the customer mad because you forgot something or would it be better to let the user spend another 30 seconds downloading a slightly larger file?

This method also makes it much easier for the user to install - no zip files need to be unzipped, no Object_Import routine has to be started, no folders need to be selected, nobody intelligent needs to be at the computer. (OK, nobody who knows anything about computers needs to be there.) I upload my install file to my website and all the user needs to do is click the link I send them in an e-mail and say "Run". The file could also be attached to an e-mail if you don't have your own website.

(My method also involves adding a simple registry entry every time the autoexec runs. This (a) allows the original program to be installed in any folder of any drive since some people don't want to install programs in their default locations and (b) allows the update routine to be run from any workstation on a network. I won't get into the details of this here but the registry entry is simply the path to the main application using either a5.get_path() or a5.get_master_path() as appropriate. This is essentially the same thing A5 does every time it starts.)

3. If you restructure the table you MUST send the updated data dictionary files for that table also. If you don't them some forms may not show the correct data. My method as described above will copy the new data dictionary files to the folder then the first time the application starts the new fields will be added before any forms are open.

4. As someone else said above, NEVER send just one data dictionary file. Always send them in groups of 3 - "ddd, ddm, ddx" or "set, sem, sex" or "alb, alm, alx".

5. NEVER, NEVER take any chance of copying the .adb file from the main application to a shadowed folder or vice-versa. Those files are different and it will create a real mess if you do this accidentally. (BTDT - can you tell?)

6. Be aware of the other things that might be saved in the .al* files. The A5 Help says it "Contains settings" but the implications of that are not clear. Some of these "settings" might be the security settings (I think they have been moved in the more recent versions of A5 but I'm not sure), the network optimize number (in other words, if you send the .al* files they will automatically get any new network optimize number without doing anything extra), anything you created with a5_save_settings(), and probably a couple other things that I can't recall at the moment. Also, some user created saved queries (yes, this is possible - and I'm not talking about queries that are saved in the Operations tab) are stored in these files. I had to create a utility for my one customer that does this so they could export them, install the update, then re-import them.

I'll probably think of other things later but that will have to do for now.