View Full Version : So, where's the Rosetta Stone?


Craig Smalley
04-19-2004, 06:42 AM
Okay, so I finally joined the club [the A4 to A5 Club, that is]. Delayed doing so for approx. 12 years, but now it seemed the time to "bite the bullet". Thought that in that time all the explorers would have marked the trail.

Well, as I've tried to start up a couple A5 copies of dbf's/tables & sets for practice as I become more comfortable and begin to bring the rest of my sets into the 21st century. For help I have again been over these pages, searched the Alpha Five User's Manual, checked the "Book" titles, and can find almost no reference to Alpha Four [A4]. Aaarrrgh!

It seems that someone somewhere would have assembled & offered something like a matching/translating Glossary to help in the translation/transition. All I find is the info that beginners must re learn the languages in order to function. Right now I feel like I'm going thru some sort of "hazing", where the "members" try to convince the "novice" that being beat over the head will build loyalty & confidence. And the victim starts to feel that it is his fault, that he volunteered to join.

Can y'all help us novices find some sort of Rosetta Stone that will explain/translate phrases, titles, commands, scripts, forms, etc. in our ambient language [A4, which was tough enough to learn] so that we may move into Alpha Five more easily?

Some other cliches occurred to me, such as "My kingdom for a horse!", but at this time "Eureka" sure isn't one, Yet.

Robin Sculthorpe
04-19-2004, 10:10 AM
Here's something that might help you out some(I'm sure that others will off other ideas for learning A% as well):

The newsletter archive had the following articles: Alpha Four to Alpha Five - #1-4:

Craig Smalley
04-19-2004, 10:30 AM

Thanks. I'll take a look.

Craig Smalley
04-19-2004, 11:16 AM
Okay, thanks for the good info. I'm sure that it will come in handy.

I'm still hoping that there is a table [or something] somewhere that will take words or terms in "A4 Speak" & return the "A5 Speak" equivilent.

Take care.
Craig "e"

04-19-2004, 04:31 PM
Hello Craig:

PACE Training has developed an online course for transitioning from A4 to A5. However, it is not a tutorial on Alpha Five, it concentrates upon maintaining your A4 data and converting it into an Alpha Five Database.

Once you've moved your A4 data into an A5 application, answering very generic, wide ranging questions isn't easy. It would help if you could ask more specific, narrowly focused questions.

Robert T

Tom Cone Jr
04-23-2004, 12:51 PM

Can you give us some examples of terms that you know in Alpha Four that you can't find in Alpha Five?

Or, is the problem the other way round? are you looking for A4 translations for terms you are encountering in A5?

-- tom

Craig Smalley
04-23-2004, 03:16 PM
Hi Tom,

Re: your first Question
The A5 start-up welcome says that it will use only the [A4].dbf files. Somewhere, someone suggested that the A5 files be in a separate file, which made me feel better, since that was already done. The Control Panel has a tab for "dbfs/sets" which wud seem to indicate that I may have a choice of choosing an A4 set containing the dbf's, or either, choosing the individual dbf's whille ignoring the A4 set.

Anyway, I've tried several times to get started.

Re: your 2nd Question
Either way wud work it's the lack om mentions of A4 within the A5 documentations.

Craig "e"

Tom Cone Jr
04-23-2004, 03:55 PM

the only terminology issue I recall is that Alpha Four databases (the DBF files) are now called tables.

You should not attempt to use both Alpha Four and Alpha Five against a common set of 'tables'.

Copy your A4 DBF's and DBT's to a new (empty) folder. Open Alpha Five. Create the new 'database' structure there (in the new folder). Then 'Add' the 'tables' to the database from their new home... not from the A4 database folder.

Warning: It's important that you keep all your tables for a single A5 database in one specific folder. Keep it in the same folder that you use for the A5 database itself.

You cannot use the A4 sets at all in A5. They must be rebuilt there.

However, the work you've done before learning how to sort and search your records, and how to use the lengthy collection of functions in various expressions will all stand you in good stead. They work the same in Alpha Five, so you should little trouble reestablishing your sets in their new home, or in building new indexes.

I suggest one more thing. Resist the temptation to try to immediately build a new version of your A5 application. One can build amazing complex applications with A4, and it's hard work to replicate the same functionality in the Windows environment of A5. A much better approach is to invent a few dummy applications, much smaller in scale and simpler in complexity. Use them as learning devices. Concentrate on learning the Windows' way... don't try to build the familiar DOS app in Windows... you'll drive yourself crazy.

--- tom

Craig Smalley
04-23-2004, 04:51 PM
Thanks for your attention. I've watched the phorum for many years & try to keep my ??'s important by seeking the easier answers elsewhere. Hence by search for a "Rosetta Stone". The closest that I've seen, so far, is an online class offered by Pace. Three weeks ago!

More recently I have downloaded the "A5 Quick Qverview" It starts rite off but when I was interrupted I'm left wondering what kind of time will be needed to start from the top, again.


Your reply reinforced some of my tentative conclusions. And raised some more questions.
1. Your "...keep all your tables for a single A5 database in one specific folder"
Several of my dbf's reference dbf's in another "LookUp" folder
So, I now have my "E:\a5\year04\bank_1.dbf" & "E:\a5\year04\bank_2.dbf" both referencing "E:\a5\lookup\customer.dbf" and/or "E:\a5\lookup\chrtacct.dbf" etc. some of which shcnge frequently.
Do you mean that that won't work? Or is it close enuf?

2. You mention "DBT's" After a couple trie of just copying my [a4] dbf's, I have now restored a backup to the a5 folder, but I worry that some or all the support files will be taking up space unnecessarily.

3. As part of the startup/learning process, I plan to be duplicating raw data in both A4 & A5. But not for too long, I hope!

I believe that there are some other issues, but your message is truncated in the "Tom Cone Jr wrote:" window. Guess that I'll have to copy it elsewhere for reference.

Again, thanks.
Craig "e'

Tom Cone Jr
04-23-2004, 06:21 PM

The only advantage to keeping all the tables in the same folder as the database application itself is that portability is assured. If you put your lookup tables in a different folder it will work fine on your development machine. Howower, if you ever need to move the application to another machine you would then have to recreate the exact same directory and subdirectory structure (including drive letter designations) for the app to work correctly in its new home. Otherwise the original path information stored in the application when you designed it won't work on the new machine, or any machine, cause the drive letters and folder names don't match, until you change the drive letter and folder names by hand. Most would find this intolerable. Doing this kind of thing can unexpectedly cause other applications on your machine to break.

In short, if keeping the lookup tables in a separate folder is what you need or want to do, you can... but you lose convenient portability.

If your app is intended for a LAN, and multi-user access, the difficulties of maintaining matching drive and directory structures should give you pause for reflection. On the other hand if you follow the recommended advice, and store all the tables in the same folder as the database itself, the database will run just fine wherever it is located. I hope this is clear. Let me know if you still have questions.

As you begin your climb up the learning curve, don't overlook the tutorials. They can be a big help.

-- tom

Tom Cone Jr
04-23-2004, 06:30 PM
Craig, your existing A4 application may not use DBT files. They are only present if your database structures include memo fields. Variable length text stored in an A4 database is physically stored in the DBT files that are companions to each DBF file. Don't worry about them if they're not part of your app.

Before signing off I note that you haven't listed any confusing terminologies yet. If you run across something that you can't figure out from the A5 docs give us a holler. If you are looking for an A5 equivalent for a familiar A4 routine, likewise. On the other hand if your concern is simply that you 'might' have this kind of trouble one day... and you'd feel better if there were a 'rosetta stone' available, I'd encourage you to relax. You'll find lots of helping hands willing to assist.

The transition from DOS to Windows is apt to be difficult for you, especially if your development experience has been limited to Alpha Four. Learning how the interface works, and then how to build something that gives your app the necessary flexibility, but still assures the integrity of your data, will take some effort. While this may seem a high price to pay it pales in comparison to the effort that would be required with other database development packages.

-- tom

Jeannette Cook
06-21-2004, 08:06 AM
In addition to Pace Training's webinar on this subject, may I also recommend the following:

Susan Bush, author of Alpha Five Made Easy, devoted almost one quarter of her v5 book to A4 transition issues. This segment was co-authored by Francie Peake. The book is available from the following link:


I would also contact Francie Peake directly to see when another of the Bush/Peake seminars will be held. Francie can be reached at: francie@peakedatabase.com

This is what I found on the subject in an archive of Alpha's newsletter:

Register now! Alpha Five seminar to be held in Atlanta in March
Great News - Francie Peake and Susan Bush will hold a seminar to take place in Atlanta, March 26-28, 2004. The seminar expands their popular GET INTO ALPHA FIVE! seminar, offering both Level 1 and Level 2 sections.

-Jeannette Cook
Alpha Software Customer Service and Marketing