RevMedia

It is not the intention here to print a review of the new functionality provided by the new version of AREV. You will already have your own copies and if you do not you will inevitably have read reviews about it back documenting 2.0 until after the official release). This article sets out to describe some of the more developer oriented features of what is becoming an increasingly more 'programmer' influenced system. We will also attempt to highlight the areas to avoid until release 2.1 is with us (being worked on at present).

First Impressions

The first thought on opening the manual box is "This MUST be a serious product, it looks like a Microsoft v5.1 C compiler reference book". The next thought as you invoke the pull down menu structure is "This must be a serious product, it looks just like Microsoft Works". Whilst I am sure that this resemblance is purely superficial it is encouraging that the product is aligning itself more with Microsoft (and of course, IBM's CUA) in this way.

Turning to the documentation itself, it has to be said that this represents a signifiant improvement over the old version. It is readable, and joy of joys, abandons the old PICK style documentation format for an in-house style that provides decent examples of code and usage. (Perhaps one day I'll meet the person at RevTech who develops the Arcade games using AREV. S/He must exist as ECHO OFF is described as being of prime use when developing games, as is another feature later in the manual). The utility diskette has been replaced by decent printed documentation. There are few mistakes of any magnitude and most of those are picked up in the on-disk documentation.

Best Features

This must of course be purely subjective but I feel very strongly that one of the most immediately useful features to the developer is the change in the way that numbers are represented internally. Thus rather than being restricted to input/output of 4 decimals it is now possible to have up to 18 digits in the number string, with the amount of decimals being decided by the programmer/application up to the maximum of 18!. Programmers working in a financial environment with interest rates/exchange rates with Lira or Yen will find this a veritable bonus.

The second most immediately useful feature is the incorporation of a check of printer status in print statements. All attempts to print to a non- connected printer results in a warning message on the top line of the screen permitting the user to retry or abort. It is a shame that if abort is chosen the program drops into the debugger rather than aborting. This could still be improved but is a major improvement on previous versions.

The third most immediately useful feature to users coming to 2.0 from an earlier release is the tutorials. Abandoning the old style "read this screen then I'll show you another one", the tutorials actually guide the user through the systems menus demonstrating the new features complete with user interaction. since they are "real" and not screen-slides they do not recover well from low memory situations but they do point out that this might be a problem before the situation is encountered. (Heavier use of the routine MEMSPACE is made throughout the new version). To get up and running (and excited) about the possibilities of the new features (especially SQL and bonding) just run the tutorials.

The fourth most immediately useful feature to new users/untrained established users, is the incorporation of a decent sample application. Finally abandoning the stance against third normal form, the application normalises invoices into a table separate from the customers. There is plentiful on-line help, the source code is well documented and the soft-keys provide useful examples of things which can be done.

Finally from an aesthetic perspective, the new window shadowing and pulldown menus cannot be overlooked. There are many features making life easier for the developer, such as multiline comments in programs (like C), lower case variables/statements/functions, and new error handling routines. For the most part these are well documented so will not be mentioned here.

The features that will become more and more useful with time are legion. It is for example, so pleasurable to execute your first relational join using SQL. For an example see the sample application, invoice processing, Shift F3. Note that it displays information from the customer and invoice file WITHOUT XLATES. SQL is undoubtedly the biggest gift we have received from RevTech for quite some time. Not only does it enable us to become familiar with the industry standard "in the comfort of your own homes", it provides the base upon which the strategy of the future, the SQL Server, can be based.

The whole approach of separating the file i/o layer from the application layer has been refined to an at times almost confusing level. However it allows immediate benefits to be reaped, the most obvious being the fact that test running windows now no longer updates the proper data file unless prompted. This is necessary when prototyping on a live dBASE system!

The attention to detail displayed in the whole conceptual structure of this new product is phenomenal. I can only applaud the braveness of the vision.

Worst Features

Unfortunately the complexity of the product is its own worst enemy. WIth the best will in the world, bugs will remain at release date. Few of these are lethal. We list below the worst/most annoying

Program code of > 34K no longer compiles. The process that previously stripped out comments and white space no longer exists and code that previously compiled correctly under version 1.15 may need to be slightly rewritten to compile under 2.0.

The INVALID Code and Command now resets STATUS() to 0 if used, so if you use a system pattern match and replace the cryptic system message with your own HL, the edit pattern will fail, your message will be displayed and then the user will be allowed to continue with the erroneous data accepted into the prompt. You must reset STATUS() to 3 if you use this feature.

1.15 allows a null key. This has been used in the past by programmers to provide a hidden record in the dictionary of files. 2.0 no longer permits a null key to be entered onto the dictionary but if upgrading from 1.15 it will not remove it. This then becomes a MAJOR problem. When one Shift-F2s in indicate that there are no columns to choose from. This seems to be because the assistant reads in %FIELDS% and reads the dictionary names UNTIL the next dictionary name is null. As null sorts before everything else, the first name encountered in %FIELDS% will be null and no columns will be returned. In itself this is a minor inconvenience. A major inconvenience is that as the new filing system does not permit a null key, it rejects attempts to delete the record from the dictionary and hangs. Pressing Escape informs you that you have a physical error trying to operate on the file. The only way to remove the null key is to create a temporary file and remove the indexing from the original file. Then write a program to select the dictionary items from the old file and copy across those not having a key of null or beginning with "%" to the dictionary of the new file. Once this has been run, DELETE DICT of the old file, MAKEFILE DICT of the old file and copy the saved dictionary items back. Finally add the indexes back on and rebuild them. This is both time consuming and annoying.

Under 1.15 it was possible to relationally index a file back to itself. This was a very useful feature permitting the establishing of hierarchical structures within files (employee to superior, children to parents etc). Any attempt to implement this in 2.0 results in a system hanging until the Escape key is pressed whereupon the system generates a FS421 message and returns to the dictionary item/indexing menu. At this point it has not unlocked the file and an EVAL UNLOCK ALL is required to continue work. The problem seems to be the indexing logic not recognising its own lock on the file being indexed. Thus it locks the file to add the first index, tries to lock it to add the second, is unable and hangs. It has not yet been proved possible to get around this problem.

There are naturally many more minor bugs not worth mentioning here (for example the "Update All Indexes" option does not ignore %PROTECT.SPEC% in the dictionary of the file and thus generates an error message for this when running), but they will doubtless be rectified in the next maintenance release of the software.

SQL whilst incredibly attractive to demonstrate to Clients (especially doing a relational join across AREV and dBASE files) has several bugs. The worst that has been encountered thus far with interactive SQL is the OCONV bug. If querying against a field containing data with an MD2 conversion, the query comparator must be entered in internal format rather than external. Thus to get records with amount > 10,000 one would be forced to use WHERE AMOUNT > 1000000. This does NOT apply if the data has been TYPEd as dollar, in which case the conversion is applied to the data before it is returned from the filing system. (Another gripe here, why only dollars?). The imbedded SQL also suffers from bugs when dealing with extended SQL syntax. The treatment of NULL also gives some cause for alarm. AREV SQL cannot yet be said to be ANSI compliant.

Conclusions

This is undoubtedly a major step forward for Advanced Revelation. The product is gaining a maturity in the marketplace surpassing that of all its rivals. If you are developing in AREV and have the spare capacity on your machine you should upgrade. If however you are thinking of starting a mission critical/time critical application, or converting over an existing application, perhaps waiting a month or so for Release 2.1 would be more prudent.