 |
 |
 | |
 | |
 | |
 |
|
|
| |
| |
| |
|
Last updated: 13 Apr 1998
The following is an excellent article comparing six major database packages, including Approach and Access.
http://www8.zdnet.com/products/content/cshp/1804/288515.html
Articles about how Approach ranks against other databases, as well as handy hints, and how to optimize your productivity with Approach and SmartSuite, are available by searching the following web sites:
The following is a collection of comments made by different subscribers comparing Approach and Access:
Approach is oriented toward the non-programmer both in ease-of-use areas and in terminology. You can get a lot done with just Approach's design tools and a few simple macros, whereas in Access you must get into "basic" programming fairly quickly. Defining fields is an example of the programmerese in Access - it uses technical terms instead of the more simple "numeric 10.2" or "date fixed" terms in Approach. I also like the idea that my data is stored in commonly used formats like dBaseIV as that opens up the data to use with dBase shareware and reporting packages, if I need them. Access stores all your data and views in one file - you lose it and you have "lost the farm".
---
As far as Approach vs Access, both have advantages and disadvantages. I find Approach easier to get started with. It also handles data in a safer manner. Your data tables remain separate from your front-end file (the .apr file) which makes them more secure, easier to save, and available for other programs. (The last could also be a disadvantage under some circumstances.) Access has much better third-party support - you'll find 20 or 30 Access titles in Borders or Barnes & Noble, and (maybe) one on Approach. And IBM (the owner of Lotus) does not have the
same commitment to desk-top computing and software that Microsoft has.
Because your tables are not part of your various .apr files, you can start all over again with new .apr files, and safely destroy the old ones when you want to. You may have noticed that you create calculated fields in Approach - for display in forms and worksheets, and summaries in reports. The calculated fields are in the .apr files, so you might want to write down any neat ones you have developed for use in new .apr files.
You can create and use multiple data-entry forms with any single table or any group of tables in one .apr file, and turn around and use some of the same tables, with other tables, in a separate .apr file. For example, the "customer" table can be in the sales-contact database, and also in the Accounts Receivable database, in such a way that the sales people would not see the money records, and the bookkeepers would not see the future sale projections. (Revenue and projections being in
separate, related tables.)
You can copy views within a .apr file. The only way I have found to copy a view between .apr files is to import the entire source file, and delete the parts I don't want. In doing this I also have to reset the table joins and connections.
---
When I evaluated Approach v Access the advice I got was that Approach was easier to learn and much faster to develop in. You can develop a larger app in Access. Approach has limits like 50 joined tables in an apr whereas I think (from memory) Access can handle 100. Anyhow, most Approach users would say that once you get above 20 joins in an apr you should split the app over multiple apr's for performance reasons. For our Company's circumstances Approach seemed the way to go and has turned out a big success.
---
I use both Approach and Access. I tend to agree with those that feel that Approach offers a more friendly user interface. I have not come across any tool yet that can compare to Approach in terms of quickly designing and rolling out an app. On the other hand, I have found that I am beginning to push the limits of what I can do with Approach. I was forced recently to develop a billing application in Access, because I just could not get Approach to do what was needed without gobbling up all available memory or generating gpf's. I qualify this by pointing out that I do my Approach development in v3.02 of Approach (16 bit). I cannot speak to the relative merits of Approach 97.
Overall, though, I still prefer to use Approach whenever possible. On your second question, there is no "correct" number of .apr files to underlying tables. I find that I use multiple APRs with particular tables, each tailored to the needs of a particular group of users. This flexibility is, IMHO, one of Approach's best features.
---
Approach vs Delphi 4?: Comparing the two products is like comparing apples and oranges. Delphi is a very good product if you like Pascal. It's not the easiest product to learn. Each time you perfect a level of understanding it, they come up with something new and better. If you write application for sale then it's one of the good products beside Topspeed. If you write database management programs, you'll find Approach to be one of the best tools... For you and me Approach is better because it takes us maybe two days to knock out a database, in Delphi or Topspeed think of two weeks to two months or more.