You think like I do, Sami. Local setups are a maintenance nightmare.
Have the batch file, RBASE.CFG, RBASE.INI, OTERRO.CFG reside on the server,
in a READ ONLY directory, RBSETUP
The batch file could be:
SET RBNAME="%1"
SET PATH=G:\RBSETUP;G:\RBTI\RBDOS65;%PATH%
G:
CD \clients
RBASE65.EXE
Then you could call:
j:\RBSETUP\clientdb.bat myname
The app could check (ENVVAL('RBUSER')) (which in this case would be
"myname") and set the NAME.
If RBUSER variable does not exist or is empty, app would not start.
The ultimate in network-centric control. Update the batch file to point to
a new version of RBASE and all users coming to work in the morning are
upgraded.
You could even have an RBASE command file in the read-only directory that
your app runs every time the user returns to the main menu. No one can stay
connected overnight without being forced to restart with the new version
when they try to do anything in the morning.
--TESTVER.CMD
SET VAR vWinVer = "R:BASE 2000 v6.5 Windows (32-bit), U.S. Version, Build:
1.833xRT03"
IF (CVAL('VERSION SYSTEM')) = 'WIN' THEN
IF (CVAL('VERSION')) <> .vWinVer THEN
PAUSE FOR 60 USING 'R:Base version has changed.'
EXIT
ENDIF
ENDIF
-- Make similar commands for DOS version if needed
....
RETURN
All of this avoids having to add a login routine to your app, and makes
surer that all users are running the same version.
-- Dennis McGrath
mailto:[EMAIL PROTECTED]
-- Productivity Tools for R:Base Programmers
http://www.enteract.com/~mcgrath/dennis
-- Full time consultant with:
SQL Resources Group
Steve Hartmann
Oak Park, IL
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Sami Aaron
Sent: Sunday, November 18, 2001 4:56 PM
To: [EMAIL PROTECTED]
Subject: Placement of RBASE.CFG and RBASe.INI files
I've made some changes recently at a couple of 6.5++ clients in placement of
the RBASE.CFG and RBASE.INI files. None are running R:BASE in conjunction
with Oterro, but I think this scenario would still be acceptable and easy to
manage.
I place BOTH files, RBASE.CFG and RBASE.INI, in the working folder of the
icon that starts up their application, usually the shared folder where the
database resides. I delete all other copies on the user's workstations and
on the server. R:BASE will look for these files first in the startup
folder - for both the Windows and DOS versions. This may not work in all
situations as there are some caveats to this:
1. If I need to trap for the specific user, I use a login system in my app.
In 6.5++, I can also use (CVAL('NetUser')) rather than looking for the
(CVAL('NAME')) from the RBASE.CFG file. That way, the client can swap out
workstations every week, the network administrators can change the path and
search options to the user's home directory as often as they want and my
R:BASE users are still up and running. No more having to help them create
a new, personalized rbase.cfg file for new users, either.
2. Pro/con - All users must have a drive mapping to the exact same drive
and directory in order for the RBASE.INI file to work, since the path is
hard-coded in the INI file. I prefer to locate R:BASE on the server, that
way, again, if the IT department changes the user's workstation, R:BASE
doesn't have to be reinstalled, locally - they just have to place a copy of
the shortcut on the workstation. (Of course, if the user needs ODBC access,
R:BASE will have to be installed on the workstation.) The only other
drawback to placing the RBASE.INI file in a shared folder is that the users
ALL have to share the same settings for display and printer fonts. For
most of my clients that hasn't been a problem at all.
3. For clients running R:BASE for DOS and/or a combination of DOS and
Windows on the same database, I set up the R:BASE for DOS icon as either a
batch file or a shortcut to the RBASE65.EXE, depending on the version of
Windows. Each stipulates the search path to the RBASE program files on the
server. So, again, the user's workstation configuration is unimportant -
neither R:BASE nor the RABSE.CFG files have to be in the startup search
path. A batch file for Win9x would look like:
SET PATH=G:\RBTI\RBDOS65;%PATH%
G:
CD \clients
RBASE65
for Win2x , on the Program tab of the shortcut, set the RBASE65.EXE path in
the Cmd line, set the startup folder in the Working line, and then click the
Advanced button. I copy the default Autoexec.NT file to a shared folder and
edit it to add the path statement as above.
Anyway, it seems to make for an easier install, easier upgrade (you just
have to install the upgrade one place) and less headache with new users and
new equipment. So far, no clients have complained about response time with
running R:BASE from the server rather than from the workstation.
FWIW -
Sami
-----------------------------------------------------------
Sami Aaron
Software Management Specialists
13214 W. 62nd Terr, #139
Shawnee KS 66216
913-915-1971
http://www.softwaremgmt.com
----- Original Message -----
From: "Ben Petersen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 17, 2001 9:12 AM
Subject: Re: Launch command for e-mails
> Maybe they should share the CFG with specific sections for each,
> and what is shared.
>
> Ben Petersen
>
>
> On 17 Nov 2001, at 16:04, MikeB wrote:
>
> > Dennis,
> > Force the CFG file with the -O command line switch. The INI file is
> > another matter (for which no switch exists as yet). The switches are
OK,
> > but it doesn't help matters when there is mixed RB and Oterro accesses.
> > There is still the issue of making sure the settings in Oterro.cfg match
the
> > ?????.CFG file for RBase.
> >
> > Mike
> >
> >
> > ----- Original Message -----
> > From: "Dennis McGrath" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, November 17, 2001 3:32 PM
> > Subject: RE: Launch command for e-mails
> >
> >
> > > Impossible requirement. Have backups of CFG Files. Suggest RBTI
restore
> > > original behavior that CFG files are only accessed in default
directory or
> > > in path. Too much of this "Who knows which CFG file" nonsense. Or,
if
> > > behavior is always to do as I suggested, suggest support people know
that.
> > > Or, tell us how to force using specific cfg file. That would solve all
the
> > > unknowns.
> > >
> > > Simple is better. PLEASE
> > >
> > > -- Dennis McGrath
> > > mailto:[EMAIL PROTECTED]
> > >
> > > -- Productivity Tools for R:Base Programmers
> > > http://www.enteract.com/~mcgrath/dennis
> > >
> > > -- Full time consultant with:
> > > SQL Resources Group
> > > Steve Hartmann
> > > Oak Park, IL
> > > mailto:[EMAIL PROTECTED]
> > >
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
> > > Behalf Of david blocker
> > > Sent: Saturday, November 17, 2001 2:12 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Launch command for e-mails
> > >
> > >
> > > Razzak's pointing out that RBG.EXE is not the right executable for
R:Base
> > > 6.5++ rang a bell - I recently was having strange problems with R:Base
> > 6.5++
> > > and it took a long phone call with Tech support to figure out the
issue:
> > > extraneous RBASE.CFG and RBASE.INI files. So, if you are running
6.5++
> > > (show version at the R> prompt), do a full search with Explorer /
Tools /
> > > Find for both files. There should be just ONE RBASE.CFG on the PC,
best
> > in
> > > C:\WINDOWS or WINNT, and ONE RBASE.INI, in the same place or in the
RBASE
> > > 6.5++ directory. See if this helps.
> > >
> > > David BLocker
>
