Issue 8 AMIGAZINE!  dBMAN And dBASE Compatibility  ============================= By Brian Jean and Terry Carter Welcome to PART II of dBMAN. PART I dealt with dBMAN from the novice's point of view. PART II will bring you a look at dBMAN from the point of view of dBASE III compatibility. Is dBMAN really dBASE compatible? To help answer that question, I enlisted the assistance of Terry Carter, a dBASE III programmer by profession. Mr. Carter is employed by the U.S. Government, programming exclusively in dBASE III and III+. This is what we found. First of all, we think it's important to understand there is no such thing as a truly 100% dBASE compatible "clone". There are always some differences. The key question is whether or not the differences are easily converted. Programs like QuickSilver, a leading dBASE III compiler, requires some changes to be made to most dBASE source; and it's written to be used with dBASE III, so you can safely assume some differences in any clone will be experienced. One problem that quickly showed itself was in the use of key words. dBMAN uses several keywords which dBASE does not. So when converting dBASE programs for use with dBMAN, you may run into syntax similar to this: DATE = DATE() The first DATE is not accepted. Changing it to XDATE works fine, but DATE = DATE() won't make it. Another key word we ran into while doing some conversions was CONTINUE. It was used as a variable in this fashion: Wait ' ' TO CONTINUE dBMAN saw no humor in that at all. Once again XCONTINUE worked just fine. We spoke to VersaSoft's technical support who explained, like dBASE III, variables can be assign to key words, but we were not successful. VersaSoft corrected themselves and explained dBMAN does have reserved words and variables can not be assigned to them. So this is a slight difference between dBASE and dBMAN. The people at VersaSoft were quick to add, and we both agree 100%, "it's crazy to use keywords as variables". Assigning values to key words is just plain bad programming. The next problem that popped up was in the syntax of some macros. The dBASE III syntax was simply: FIND &variablename we had to change it to read: FIND '&variablename' We ran into another minor problem in the way dBASE handles buffers as compared to dBMAN. It seems that dBASE ignores when entered, using it only as an end of line indicator. dBMAN adds the , or ASCII 13, to the buffer. The problem we ran into while converting a dBASE III program was in source that looks something like this: STORE ' ' TO doit DO WHILE (LEN(doit) > 0) .... .... .... WAIT 'Press Return To Exit' TO doit ENDDO What's happening here, is dBASE is allowing the user to exit the loop at the WAIT prompt by pressing . This then dumps an empty buffer to the variable specified (doit). The length of the empty buffer is zero, so the loop is terminated. dBMAN, on the other hand, adds the ASCII 13 to the buffer giving the length a value of 1. The end result is a loop which the user can't break out of. The problem was quickly handled by amending the code to read as follows: STORE ' ' TO doit DO WHILE (LASTKEY() <> 13) .... .... .... WAIT 'Press Return To Exit' TO doit ENDDO Now we're just checking the ASCII value of the last key. As long as it is anything but 13 (RETURN), the DO WHILE loop will keep looping. Thus far, the required changes have been minor in nature, so minor that you would be foolish to turn away from dBMAN due to them. There is another problem we ran into which was really rather silly, and we can not for the best of us see why the the dBASE "NORM" was so heavily deviated from. It is our opinion that if software billed as "dBASE compatible" deviated from the "NORM", then that deviation should be for the better. We honestly can not see where "for the better" was put. dBASE III selects work areas using "SELECT x" where x is a number from 1 - 10, or "SELECT A" "SELECT B" etc. dBMAN uses "SELECT FJ" through "SELECT FS". FJ? FS? Don't ask where that come from, your guess is as good as ours. Technical support said "SELECT A" etc. was supported. A syntax error was experienced here when we tried it. VersaSoft later stated they were in error on the "SELECT A" support, advising they in fact do not support this feature of dBASE. Another dBASE command is SET COLOR TO x where x represents a numeric value in turn representing a color. dBMAN ignores that command. So if you are porting a dBASE III file that uses a lot of the color commands, don't worry about changing them right away, they're nothing but dead weight. dBMAN uses SET VIDEO TO x, where again x is a color code. The manual explains a value of 112 will change to reverse video and 7 returns to normal. In reality, any value changes to reverse video with 7 returning to normal. After over an hour of assuming we were using the wrong syntax (or something equally as stupid) in trying to bring out any of the Amiga's 4,096 colors, we threw our arms in the air and called tech support. We were surprised to hear dBMAN *DOES NOT* support color on the Amiga! VersaSoft explained "... color on the Amiga involves getting into graphics, and we don't want to do that ... ". That is disappointing to say the least. We're not pushing for HAM pictures from dBMAN (it would be a nice touch), just the ability for color text. Although the question of color has little to do with dBASE compatibility, it is a definite shortcoming of the program. Most users want not only powerful software (which dBMAN most certainly is), but also software that *LOOKS* powerful. One more incompatibility is it's lack of ability to produce and use format files (.FMT files). .FMT files are really a nice feature of dBASE III. It allows a user to define a screen which can be called up later for use. dBMAN requires the programmer to create the screen format from within the program. In conclusion, dBMAN is relatively dBASE compatible. The necessary changes are really minor in nature. An experienced dBASE programer may pull his hair out for awhile getting used to the added keywords, but that should quickly pass. The non-experienced programmer learning dBASE for the first time will quickly fall in love with the language and it's power. Now for our "wish list" ... If we had the ability to snap our fingers and VersaSoft would grant me three wishes, this is what they would be: 1) Add color, at least an 8 color screen, or the ability for the programmer to open up a screen with the number of colors (bit planes) definable. Amiga Basic can do it ... 2) Add key words that allow for windowing, something the Amiga is famous for, giving the program a *REAL* touch of class. 3) A "HOW TO PROGRAM IN dBMAN" manual that goes along with the reference manual. dBMAN is very dBASE compatible; however, the first time programmer (as in zero experience in another language) will run into some problems with some of the conversions. We could do without #3, but #1 and #2 would take an already *GOOD* product and transform it into a *GREAT* product. Prior to publishing this review, we mailed a copy to VersaSoft for their comments. We felt they should have a chance to comment on any shortcomings we found in their product. As with PART I of the look at dBMAN, they were quick to resond. It was in this response they pointed out they were in error when at first saying "SELECT A" was supported along with the ability to use key words as variables. As to the question of compatibility, here's what they had to say ... "... what does compatability mean? dBMAN has never advertised dBASE 100% compatibility. We are a dBASE work-alike. In some of our older versions, we claimed 95% compatible. That is to say for every 100 dBASE commands dBMAN had 95. Well, to be honest, if your application uses just one of those commands that we do not support then your application is 0% dBMAN compatible. The question really should be "Does dBMAN bring the dBASE environment to the Amiga?" and we think the answer is yes ..." This is a very valid point on the part of VersaSoft. dBMAN does, without a doubt, bring the dBASE environment to the Amiga. VersaSoft also responded to our "Wish List", stating research and delevopement is in fact working on both color and windowing for the Amiga, stating it looks like it will be 6 months or more away. We're happy to hear that. At first we thought they had simply dismissed the idea of ever adding either. They also explained that a "How To" book is not needed because the market is flooded with dBASE "How To" books, all of which would help the novice learn the programming logic of dBMAN.