Hello all,
Our paradox database has grown well beyond it's initial plan and has become
unruly. i'm stepping in to try to reign it in. there has never been a separate
test/dev environment. i want to set up a separate paradox environment that
will be a copy of the production environment (at least initially) and i don't
want the two systems to ever be aware of eachother or interact. Can i do
this and still have the two environments on the same LAN?

They won't interact with each other if they don't access the same data folders
or use the same WORK folder, am i correct? I realize the BDE's talk to each
other and are aware of each other (how? by broadcast i assume) but i want
to be sure my test environment doesn't interact with the production. Does
anyone have any tips, pointers, advice?

Thanks all, have a good day

just make a separate, complete copy and go on your merry way.. the main
point being "complete"..

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

Basically it's all about defining your aliases to point to another location.

There are several ways to do this.

One approach I use in some of my apps:

- Keep two separate folder structures like:


DEV
DATA
FORMS
REPORTS
LIBS

PROD
DATA
FROMS
REPORTS
LIBS

Prod is probably on your server, dev could also be on the server or on your
local drive depending on your situaion.

In prod I only keep delivered files, FDL, RDL, SDL. In dev I keep only
undelivered objects, FSL, RSL, SSL etc.

I use two different shortcut. One to dev, one ot prod with different private
folders (using the -p switch) and different work with the -w switch. Each
shortcut opens up Start.ssl (dev) resp Start.sdl (prod).

In the start script I define all alias for the app. I never store any alias
in the BDE config file. The scripts define the alias relative to the
location of the script it self using getFileName() so I don't need to have
different code in the start script.

With this setup I can run two instances of my app simulatenously - both
using the same names for the aliases but pointing to different locations.

There are probably many many other ways to do this (to be honest I don't use
this approach for all my apps) but this is the one I have found to be
easiest.

Anders

A few things. Best to have your aliases defined on the fly as the ap starts. There
is plenty of info on this in various locations both in these groups, on our paradox
resources site (link in my signature) and at thedbcommunity.com. Given that you can
then set up 2 different start icons. One for the real ap and one for the dev. You
can't run them at the same time and you will have to make sure that either you shut
down all BDE access when switching from one to the other or make sure that you code
is robust enough to always remap the aliases. DON'T SAVE the aliases.

Each will also need its own PRIV so make sure each uses its own -p switch in the
start icon. Also, WORK should just point to some neutral location you don't use so
any number of aps can share the same workplace. See the Database Basics paper on our
paradox resources page for more on that.

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since 1982

Don't forget there can be hard-coded paths - whether for aliases or
lookups or RI or some other reason.

IMO, better to totally isolate them until/unless you're sure there are
no issues like those already raised.

NOTE: IMO, using one workstation for both test/dev and production can be
very dangerous - doesn't matter that you have scripts to point your
aliases where needed - if you forget you're on production, think you're
on test and empty a table, boy are you gonna be mad that you didn't just
go with a physically separate box... :-) (experience speaking here).

Liz


RickM wrote:

My preference has always been to make the switch for DEV/TEST/PROD occur
outside of the application. If the application is responsible for
explicitly selecting it's own environment, there's the potential for stuff
to slip through testing and only rear it's head in production. I use a
directory structure like what Anders posted.

I make sure the .net files are different between environments. Someone
working in DEV should not be able to see PROD data whatsoever.

I do try to make it obvious when pointed to the non-production environments,
so folks will know what they're looking at.

--
Larry DiGiovanni

Wow, thanks everyone for great advice. I also like the directory structure
previously mentioned. Although i'm not sure i may want to go with a separate
box if i can get it. Also the RDA website is an excellent resource i used
years ago when i first did Paradox development for a brief time. Back in
the days of the Application Framework, glad we don't use that anymore.

"Larry DiGiovanni" <nospam (AT) nospam (DOT) com> wrote:

Rick,

Along with all the other suggestions, it is critical that you make sure the
BDE's Network Control File directory points to a different place between
production and development. This is how Pdox 'knows' about other users.


You can use network mapping to fix this (say, by giving development a different
"X:\" drive than production), or just manually update the BDE Admin.

HTH,
Jim Moseley