I have had a small medical practice management database that I set up in Revelation since the Release G days. I have always updated my development copy of AREV and recently installed a system in a new clients office. They purchased the Runtime 3.12. I made sure to upgrade my development copy to 3.12 as well so that both systems would be compatible. All of their practice specific files are in a separate volume, which gets attached upon logon. Here are some problems:

First, I noticed that even in my developer system, all cross reference s in the PAINT screen (using code B) were not automatically changed from FILENAME*L.NAME.XREF to FILENAME.L.NAME_XREF. I had to manually change each one to replace the period with an underscore.

Second, my system seems to only handle ATTACH while the new one only recognizes ATTACHTABLE. This also happens with SETALIAS (mine only recognizes SETFILE) etc. I assume this is a function of my VOC or something like that having been upgraded over the years, but I don't know why my recently upgraded version can't recognize both ATTACH and ATTACHTABLE. It is not that convenient for me to have to set those items to one thing while I develop and reset it each time in the application. I just need some advice before I launch into it (would this be copying the voc and dict voc from my development copy?).

Third, and worst, is that in the runtime, when a screen with an indexed field is called using F2, the user is prompted to enter a last name, but when F9 is pressed, the following message occurs:

"The object code for Getkeylen cannot be found in the SYSOBJ table. Getkeylen is also not cataloged. Please enter the name of the table containing the object code for Getkeylen."

As far as I can tell, the SYSOBJ for the runtime is the active one. Why would this feature be different?

I figure I did something wrong on the developer upgrade side. Is there any way out of this mess? Thanks in advance for any help you can give.

Michael

First, I noticed that even in my developer system, all cross reference s in the PAINT screen (using code B) were not automatically changed from FILENAME*L.NAME.XREF to FILENAME.L.NAME_XREF. I had to manually change each one to replace the period with an underscore.

I 'think' this is normal - we had to do the same thing.

Second, my system seems to only handle ATTACH while the new one only recognizes ATTACHTABLE.

You can create a new VOC entry to handle this. Look at the ATTACHTABLE record in the VOC table (edit voc attachtable), you can copy everything there to the clip board - and paste it in a new VOC record called ATTACH. Save it, and now the system should recognize both/either command. There is a utility in the 3.12 (I believe) upgrade that will create synonyms for the older commands. You may want to try and find that and run it against your system - although I'm not sure if that would help your runtime situation.

The object code for Getkeylen cannot be found in the SYSOBJ table. Getkeylen is also not cataloged. Please enter the name of the table containing the object code for Getkeylen.

You need to actually find/verify where the $GETKEYLEN record is stored. The message is saying it's not in SYSOBJ - however, on our system here it is indeed in the SYSOBJ file. Maybe you have records from the old VERBS file that were not copied over correctly (at all??). Take a look and see if you can find the record in your SYSOBJ and/or old VERBS file.

Jeff

Thanks Jeff. I worry that doing it item by item is going to be a nightmare down the road, especially glitches that I don't catch right away and my client then keeps calling me. I can't understand why some things get copied and some things don't. But I DO appreciate your help!

Michael

I thought the upgrade application sections handled that. However this is one of those funny things that could have just been my imagination. I can envision environments where going in and programatically updating all forms could be a problem. However, the system should be smart enough to find _XREF from .XREF. I have clear memorys of putting this in code, I'm pretty sure it was in the XRF.BROWSE and VALIDATENAME should handle the rest.

The attach (and VOC stuff in general) is definetly related to upgrading the application. You should have run the upgrade application. Now, depending on how the system is set up, you could have a situation where the upgrade application didn't take all that well. I'm doing this from memory, so bear with me some.

Coming up to 3.x, ARev started that whole application in a subdirectory concept. Before that, the application files were stored in REVBOOT. Many developers already did this, and moved files out from REVBOOT into an application directory. For most of these files it didn't matter. However, ARev required that VOC remain in REVBOOT. What would happen is that there would also be a VOC in the application directory. So, it could be that ARev updated the REVBOOT VOC, but not the application VOC. You should be able to solve this by logging into the application and running OLDSTUFF.

Interesting that KEYLEN could not be found in the runtime. This seems to be a pretty popular problem. The upgrade processor has an option where files are flagged development, runtime, or both. I'm wondering if somehow this flag is set incorrectly. As mentioned in other messages, just copy from one system to another.

[email protected]

Sprezzatura, Inc.

View this thread on the forum...