From: beh@po.CWRU.Edu (Bob E. Hetzel)
Newsgroups: comp.databases
Subject: Re: PARADOX 4.0 with Novell: Braindead?
Date: 1 Jan 1993 00:31:18 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: beh@po.CWRU.Edu (Bob E. Hetzel)
NNTP-Posting-Host: thor.ins.cwru.edu


In a previous article, joe@eng3.sci.com (Joe LaRocque) says:

>We are in desperate need of help in using PARADOX 4.0 off of a Novell
>server.  We have been experiencing 'unexpected errors' starting with
>release 3.5 and are continuing to have problems with release 4.0 of
>PARADOX.  

Note that I am currently only using 4.0 for a standalone application
(not networked) but I do work with 3.5 on a 6 user novell networked
database which is quite huge.

>	CONFIG.SYS
>
>	DEVICE=C:\QEMM60\QEMM386.sys EXTMEM=2560 RAM exclude=c800-cfff

first, I would not advise using qemm.  It does not truly buy you
anything, and could considerably slow down paradox if the wrong
blocks of memory are not excluded.  Paradox likes to manage its
own memory, anyway.  This, I suspect is your biggest problem.
--
>	DEVICEHIGH=C:\DOS\SETVER.EXE

not that this would cause a problem, but most of the time you do not
need it, if you have reasonably new versions of all your software.
--
>	lastdrive=f
>	FILES=40
>	BUFFERS=40
>	DEVICEHIGH=C:\DOS\ANSI.SYS
>	SHELL=C:\DOS\COMMAND.COM C:\DOS\  /p /e:1024

It is always a good Idea to use the command.com which resides
in the root directory.  If you don't have one there, put one there.
Then change this line to read...
	SHELL=C:\COMMAND.COM /p /e:1024

You also probably have no use for such a big environment.  Your
path can only be so big before dos truncates it, no matter what
the size of the environment.  If your computer needs to have a
lot of dos variables set, then you might need such a large environment,
but try reducing it anyway.
--
>	DOS=HIGH, UMB

also, get rid of the umb part of the above line.  Upper memory blocks
don't buy you much.  A better solution is to just put more extended
memory into the machine by adding simms.  Most newer programs 
(such as paradox) truly only care about how much total memory you
have, not base memory.
--
>	**************************************************************
>
>	AUTOEXEC.BAT
>
>	@ECHO OFF
>	c:\dos\share
You probably do not need to run share unless you are going to run
two copies of the same application in windows, and or two programs
which access the same file from within windows (or any other 
"multi-tasking" program.
--
>	PATH C:\qb45;C:\;C:\DOS;c:\bin;C:\bats;c:\mcshell;c:\windows;
>	PROMPT $P$G
>	set cdpath=c:\;
>	cd \

this line does not do anything, since the computer boots from the root
directory, anyway.  Also, it will produce an error as dos uses
the back slash, not the forward slash for directorys.
--
>	C:\mouse\mouse.com /1
>	VER
>	set GRASP=c:\grasp
>	loadhigh c:\dos\doskey
>	subst d: c:\d

This command will truly confuse a lot of stuff.  It's never a good
idea to fool dos as to location of files.  I recommend backing up
all your stuff on this machine, then re-partitioning the drive
(using fdisk) so that the c: drive is 100% of the disk space.  If you
actually have two separate drives, then I would still remove
this line, even though you will not be able to put all the stuff on
the same logical drive.
--
>NOVELL:
>
can't help you on this section, but I suspect any problems here
will show up as error messages on the server and not on 
the pc's in the middle of applications.
If you can't get all your problems solved with my above suggestions,
you could ask the folks at comp.sys.novell.

>TUTILITY:
>
>We ran TUTILITY 4.0 on two tables.  We're almost certain the tables
>were corrupted.  We had gotten key violations when restructuring and
>continued to have "unexpected condition 449" problems.  TUTILITY 
>rebuilt without lossing records and said it had 0 problems. However,
>we had a problems with a form afterwards.  We found that all forms
>were corrupt or out of date (modify/change/form).  We had made a backup
>of the tables before Tutility ran. The forms were ok on the backup.
>DOES TUTILTITY KILL YOUR FORMS? DOES IT REALLY FIX ANYTHING?

More likely, when you changed the "key fields" in your table 
(by restructuring it), it blew up the forms, but you didn't 
notice this until after you ran tutility.  

Hope the above suggestions help.

     Bob
-- 
"I held the blade, in trembling hands,
 Prepared to make it hurt.
 Just then the phone rang... 
 I never had the nerve to make the final cut".-- Pink Floyd, 1983.