Over the past year we have made a number of attempts to convert our AREV 3.12 applications to OI. Our attempts have failed or been abandonded because we were unable to sucessfully ADD our AREV files to OI.

Our major problem is our application names (xxx.xx or yyy.yy) include 'dots'. We have tried a number of different methods to change the application name with no success. One method ws to create a new application. We though we should be able to do a SETALIAS to the file to be copied and then do a file copy to a new file name. We hoped this would rename the file to the new application and change the file name to comply with the OI file format (no dots). All of the application files also contain dots.

One client has 500 + files that have to converted. So we need to find a method, hopefully under program control, to first change the Application name and then the file names.

Any help will be greatly appreciated.

Mark

I would appreciate any advice on how to chnge the AREV application name. We need to find a method to automate this as one clie has over 200 files that have to be converted to OI.

gingingce

It sounds like you need to interface directly with the REVMEDIA files. To do this you must either know the SYSPROG password or use one of the techniques published in various sources (I'm sure it's listed in Sprezzatura's Revmedia).

Anyway, then you could simply copy additional records into the REVMEDIA file for use by OI.

Here I must quickly note that I am rashly making another OI comment. Maybe this doesn't work (to leave the old records there).

In any case, whether you decide to leave the old entries in REVMEDIA there, reading and writing to the REVMEDIA files is the way to go. Make sure you are very careful where indexes are involved, however.

Why don't you just rename your AREV applications to something that OI can handle?

To change the application name,

1) you should create a new application in AREV with an OI-friendly account name.

2) You should probably remove all indexes from your application files

3) Then either log into your application and rename each table( from tcl, the table menu, or a program), or

4) Log into sysprog and attach the revmedia file (ATTACH volumename REVMEDIA). The account name is part of the record key in revmedia. You can then copy revmedia records to a new key that uses your new application name. I would probably delete the old revmedia entry, but, you can even leave the old names there, so a single table belongs to multiple accounts (although I am not sure how OI would react to this (arev handles it)).

5) Log in and reinstall your indexes.

It's not hard, it's just time-consuming detail work, so be sure to pack a lunch or two.

Thanks very much for your help and prompt replies. I will try the suggestions tonight.

Dan - I would love just to rename my application and have AREV copy all my files etc. Is there a way just to rename an application?

Mark

We actually do this all of the time. It is how we deploy our application to customers. Since we do it frequently, it was worth the time to write a program that would automate as much of this as possible. Even with that, there is some manual setup to specify which tables get copied, their new location and the account name of each table. We usually have 150 to 200 indexes installed, so we wrote utilities that remove all of the indexes in a single motion; then we run the copy program; then we use our indexing utilities to reinstall all of the indexes.

Here is more info on renaming an account…

When you create a new application in AREV the system generates the core system files, like WINDOWS, POPUPS, MENUS, VOC, etc. It also makes entries in the AREV system files in sysprog. I suppose you could go through all of this and manually change this stuff, but I find it easier to just create a new application with the new name.

After you have your new (empty) application you can attach any directories that you want. When you use the ATTACH command AREV looks in the REVMEDIA file located in each directory to determine which tables you are allowed to attach. It will attach GLOBAL tables and tables that have the same application name that you are logged in to. It determines this (I suppose) by looking at the record keys in the REVMEDIA table. The record keys contain 2 parts – logicalTableName*applicationName.

I have found that if the REVMEDIA file contains an entry that matches your application name, it will attach the table. It simply ignores entries that do not contain GLOBAL or your application name in part 2 of the record key.

So, you can add synonyms to REVMEDIA for each table. For example… COPY REVMEDIA MYTABLE*OLD.ACCOUNT TO: MYTABLE*NEWACCOUNT. Now, if you log in to NEWACCOUNT and attach the directory you will be able to see every table that has NEWACCOUNT as part 2 of the record key in REVMEDIA. If you log into OLD.ACCOUNT and attach the same directory you will be able to see every entry that has OLD.ACCOUNT in the record key.

The only issue that we have encountered has to do with indexing. Indexes are account specific. I would suggest that you remove all indexes before making your new revmedia entries, then log into your new application before re-installing your new indexes. Also, do not install the same indexes on both OLD.ACCOUNT and NEW.ACCOUNT. You will end up updating each index twice, and the updates would get out of sync.

Finally, you can only attach REVMEDIA from SYSPROG, so it should be obvious by now that anyone with access to SYSPROG can change security access to any table. Be sure to secure sysprog and any username that has access to sysprog with a non-public password.

I suppose there may be some details I have missed, but the approach above will work. Perhaps someone else out there can add something I have overlooked.

Thanks once again for the information.

I followed your suggestion to rename the files in Revmedia. This worked and I was able to add the files in OI. However, the file dictionaries were not "available" to OI. I atempted to change the dictionary file names in the AREV Revmedia and then ADD the dictionary to OI. This worked but I was still unable to 'see' the dictionary in OI so when I attempted to add the file to a OI form there was nothing to add. I checked the Arev file dictioanary and all appears in order. There are no 'dots' in the field names and the definition (data type is complete for all entries).

What am I doing wrong?

Thanks.

Mark

Mark,

Could it be that your problem is similar to the one I got resolved today (thanks to Sprezz and Scott).

My problem was, that I had a file, referenced in REVMEDIA, that could be seen by AREV but not by OI. OI doesn't seem to care too much about REVMEDIA, it looks into APPNAME.DBT, where the database definition is.

Hope this helps

Wilhelm

True to a point… OI uses the REVMEDIA to create the DBT in the first instance after which it uses the DBT.

The Sprezzatura Group

World Leaders in all things RevSoft

It may be the case that one or more of your DICT's is invalid in OI (Symbolics referring to fields with dots, etc.). Also, if these are not AREV 3.x files (from earlier version), it's wise to remove all indexing before fiddling.

Don

Not sure. Maybe someone with more knowledge of OI can help.

Not sure. Maybe someone with more knowledge of OI can help.

Don is correct and right on the point when he says that the files/tables contain invalid information in the dictionary of the table. One of two things are wrong -

Either there are periods in field names and/or symbolics

            or

Data Typing is not on each field

1. such as for AlphaNumeric fields - Data typing being VARCHAR(x)

  for Numberic/Value fields - Data typing being Dollars, etc.

OI will NOT add any dictionary tables that

have periods in fields 

       or

does not have data types on each field

There was a program available on the works area called

 MAGIC  (Zipped file)

which will automatically

data type each field

remove periods on each field name

will NOT remove periods within formula's

The problem is that when you run this program, you have to make sure that all of your queries/reports/programs etc that reference any selections/field names etc. are changed -

as an interium step, sometimes we copy the table to an OI friendly table name with all the data, run the magic program on that new table, modify the processes with regards to the old table to write any modified/new records to the new table - it is a hassle but works for an interium step…

View this thread on the forum...