R&R in a Multi-User environment

[fsu4ever_(Guest)]

In our DOS application, we call R&R (5.x) Runtime with a /I option that allows multiple users to run the same report at the same time. We are transitioning over to R&R ver 10, but we can^t find a comparable option for the /I we were using. In fact, in reading the documentation, it appears that this capability has been removed from R&R. Can this be true? Is there no answer to the problem of two users running the same report without overriding each other? Can someone out there help us???__Thanks!!

[fsu4ever_(Guest)]

Is there anyone out there who can help with this issue. How about any of you R&R support people, any help from you would really be appreciated.

[kfleming]

You can use the /O switch to create a unique output status file for each runtime user.____Kathleen__R&R Support

[fsu4ever_(Guest)]

Kathleen,__Thanks for the response. Is /O the equivalent of the /I from Ver 5.x?If not, I^m not sure that will solve our issue, unless I misunderstand the use of the Status file. I think that the status file is to report the results of the report run. The problem we are having deals with two users running the same report at the same time. User #1 wants the results sent to the printer, so #1 makes the appropriate selection, which is stored in the runtime library. User #2 wants the report sent to the screen and has a different query as well, so selection is made the runtime library is updated with user #2^s selections. User #1 get the report on the screen and with the wrong information, since the query was changed.__Under the 5.x version with the /I option, each user got their own runtime library and these overlays were not a problem.__Thanks for any help you can provide...

[cal]

I tink I understand your problem correctly. The way I handle this in my Clipper apps is:____The user is required to "login" to the app at startup, with his or her initials... no two users may have same initials... an "appusers" file is used to prevent this, as well as preventing a user from starting the app more than once.____The users inits are used to create a unique runtime input filename for the user "AppRi" + cInits + ".dbf" = user^s unique runtime input file... AppRiCAK.dbf. The runtime input file is then copied to this file. The each user^s call to the runtime are made using his own runtime input filename. This way maore than one user can call the runtime module for the same record (report), using different runtime parameters such as master file, or printer. Most often, a similar technique is used to produce unique temporary files for report data, both dbf^s and cdx^s for a report. This seems to have solved these problems for me in my Clipper apps, once and for all.____Hope this helps.____Cal ______________________________________

[fsu4ever_(Guest)]

Cal,__Thanks for the feed-back. We do the same thing in our Clipper applications, using the operator-ID along with the /I option. This works fine for Clipper/DOS applications, as you said. My issue is with the newest release of R&R (ver 10). I don^t see an equivalent to the /I option from the 5.x versions of R&R. __Any insight to the newest versions of R&R would be appreciated.__Thanks,__fsu4ever

[fsu4ever_(Guest)]

Cal,__Oops, I think, after re-reading your reply, that you did answer my question. Are you saying that you use that technique for the newer versions of R&R? If so, then thanks for the answer.__

[cal]

Yes. I used the same technique for 8, 8.1, and now 9.0. I have purchased 10, but do not yet use it. ____I did have to make a few changes to my PrtRpt() function when I went from 6.0 fot DOS to RR8, since the calling conventions are a little different for a Windows exe than for a DOS one. Also at the same time, I ran into Win2000 which has a significantly different behavior from Win 9x when a Clipper app calls another process... to make it a little more complicated, I have network systems, where some of the stations are Win9x and some are Win2000. My PrtRpt() function detects which OS is running and makes the appropriate call.____Finally, I hope you are using Blinker. If so, I can share my PrtRpt() code here, if you feel the need.____Cal

[fsu4ever_(Guest)]

Cal,__Thanks for the offer and yes we do use blinker. However, we are in the process of moving our app from Clipper to VFP. We still use R&R 5.x with our Clipper application, so our R&R connection in the Clipper app is working just fine. We ran into the problem with the newer version of R&R when trying to plug the interface into the VFP app. Our users were overriding each other. That brought this problem to our attention. I can^t believe that R&R lost some functionality when they made this move. However, we will most likely implement your suggestion and copy the runtime library to a separate database for each user as the kick off a report. The biggest drawback from this is that our users can^t share queries now, since they are located in custom runtime libraries as opposed to being universally accessable.

[cal]

You might consider providing another little shared dbf file and an interface browser to allow the users^ stored queries to all be located in the one file which is accessible to all users. Using the browser, tBrowse object in Clipper, any user could then select an existing query (character string) which would then be written into his own runtime input file for that instance. Any user could add queries into the shared file which would then be accessible to all users.____Cal