To facilitate systems testing with current data files, I found it fastest to 'put aside' my current testing account and create a 'fresh' one by loading down a just saved image of the current live account.

My intent was to then bring my development software file into this

refreshed image of the live data by being able to copy the software

from my prior testing environment which I had set aside by copying it

to my local C: drive (my new test files reside on the D: drive).

Establishing alias-named pointers to the old test environment has

proven practically impossible for me - even after resolving the

duplicate volume name problem by using NAMEVOLUME.

In desperation I decided to try to have 2 separate active test environments so I could copy between them by attaching to a directory commonly available to both of them and by copying out of one test account into that directory and then copying from that directory into

the target test account.

Stymied again: I can no longer create a logon into the test account

that was 'put aside' in a different location - even though I'm using

the same procedure that successfully installed the 'new' test system.

Every time I attempt to logon, it attaches the same D: directories that the new test account uses - though I modified the

'TRAINING.LOGON' TCL procedure's attachments to find the directories

on the C: drives they now reside on and altered the shortcut icon to point to the C:

How can I have these two testing accounts on my local system and log

on to either one by choice?

Thank you,

Lewis Unger

Good Idea. As you can see there are several issues to resolve.

1) Look in the VOC table for rows with "VOLUME" as the first column. They may have full paths to the original data volumes. They will have to be changed to point to the test data.

2) Simple XCOPY of directories causes several problems:

a) The Indexing system relies upon unique volume names as you found using the NAMEVOLUME command.  They are stored in the %%REVMEDIA%% row (hidden) of the REVMEDIA table.  Also part of the index definition when the table is indexed.  So, best to remove ALL indexing in the test system and re-apply.

b) Row locking relies upon unique DOS filenames (the REVnnnnn portion).  So, you may want to use COPYTABLE instead of using DOS or Windows copying.

3) Then you will have the problem of making program and dictionary changes in your test system that you want to apply to the production system. And, vice versa. This can be done if you keep good notes and use separate transfer files, or you can use my utility, PX, which I sell for this purpose. email [email protected] for information

Good luck!

Just buy Dave's utility….

Don't just take Dave's word for his PX program. Here's an independent review of PX we did for Revmedia around 10 years ago. This venerable product has stood the test of time. Sprezz would like to write one for OpenInsight, but we're letting Dave replicate his excellent work in the OI world.

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...