Last Friday, I had the privilege of traveling to Renton (Seattle), Washington to meet with Wayne Erickson and Razzak. Along with my programming associates, we had been using R:Base 6.5++ for Windows build 1.840K on large complex databases with sophisticated R:Base and Tango applications. In general, 1.840k is a superb product. It is chalk full of new features and significant bug fixes. Because of the complexity of our database environment - tables with a primary key and several unique keys, all referenced; tables with multiple compound foreign key references (up to four columns) against unique keys, tables with a single columns participating in multiple compound foreign keys each referencing different tables; extensive use of varchar and varbit columns, lots of multiple user pressure from concurrent native R:base Windows and DOS applications and Tango applications, in some cases from world wide users - we were encountering a few obscure and one nasty problem. Specifically, when adding a column to a multi column table which had a varchar column as the last column in the list and the added column was appended on below the varchar column, R:Base would error when you tried to assign a constraint such as a foreign key or a primary key to that column. Second, RBdefine could corrupt the sys_indexes table when a column with a primary or foreign key constraint was dropped. Using the alter table command at the R> operated correctly. Third, under certain circumstances, using RBdefine to delete a foreign key reference for a compound key in which one or more of the participating columns participated in other foreign key references would also error out. Again, using the alter table command at the R> did not produce the error. Finally, we were observing the degradation of autonumber integer columns under heavy Tango use, where such use resulted in lots of inserts. The autonum degraded in a way such that its value in the sys_defaults table became null. In Rbdefine, displaying the column with the autonumber yielded a display of a real number xxx.yyy when the datatype was an integer. I have been an R:Base programmer for a long time - maybe 18 years or more. I have always been a prolific beta tester. I have experienced the hay-days of Microrim, the low days of Abacus, and the Glorious days of RBTI. I have run all the good versions of R:base (which ironically all tend to be even numbers (2X, 4X, 6X) and the less than good versions (3X, 5x). I always found Microrim to be reasonably cooperative; I have always found Razzak to be extremely cooperative. This weekend, however, was amazing. Wayne and I simply sat down, in a hotel room, he with his laptop and I with mine. I showed him a problem, he reproduced it on a copy of one of my databases housed on his computer, and he then tweaked the R:Base source code to eliminate the problem, issued a new build of R:base, put it on a zip disk so it could go on Razzak's computer, from which it went on my computer. By shortly before midnight, we had 3 out of the 4 problems put to bed. Wayne got up at the crack of dawn the next day and while Razzak and I were eating breakfast, he fixed the last problem and we had the final build waiting as soon as we got back to the hotel room. I am relating this experience in some detail, because, I believe that it has some truly profound significance. First, the reason Wayne only fixed four bugs is that that is all I could show him. I don't know of any more. I suspect that if I had 5 or 6 or 10 or 12 replicate-able bugs, he would have fixed every single one of them before noon the next day. I would like to encourage everyone to make use of RDCC and document anything that is wrong with R:Base. Be very careful to document it in such a way that it can be reproduced. If you can send a snippet of code or a portion of a database, do so. It is my experience, that WITHOUT EXCEPTION any reproducible bug you document will be fixed. The intimacy of this kind of relationship between the development community and the database owner and code author is unparalleled. It is clearly one of R:Base's great strengths. I would challenge any other developer of any other database to relate an experience wherein the database owner and code author are so approachable and so helpful. Second, and this should not be underestimated: it didn't take Wayne very long to fix any of my bugs, some of which were tricky. I got the distinct impression that Wayne knows R:base source code like the back of his hand. Wayne is simply an irreplaceable and invaluable asset to the R:base community. It is apparent that he "knows his onions" and likes to "hand around in the garden." Moreover, this is not the first or the second or even the third time that Wayne has helped me out before; it is the first time that I have had the pleasure of working one on one with him. I have nothing but admiration for his ability and his willingness to help. After Wayne retired for the night, I FTP'd build 1.841 to one of my large client sites and upgraded them on the spot (Using VNC and the hotel room high speed internet connection). I even executed a remote reload of the 500+ Meg database, all from my hotel room - a tribute to the manageability of the R:Base environment. Razzak then gave me a tour of all of the new features in build 1.841 (go to the R> and type show version to see what build you are currently running). Some of the features were quite cool. I think the official version of R:base will ship around June 15. I plan to upgrade all of my clients immediately - this will easily be the strongest and best Rbase that has ever shipped. I then tested my luck and asked Razzak to show me R:base 7.0. He did. From what I can see, it will be a dramatic improvement over 6.0 in both look and feel and functionality. As if that wasn't enough, Wayne also tweaked Oterro and gave me a new build of it as well. I think the future of R:base is very very bright, due to Razzak, Wayne, and the special relationship that they have extended to the R:base development community. R:base 1.841 is a fabulous product. Thanks Wayne, Thanks Razzak. Harlan
