NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/database/8788

Text File | 1993-01-04 | 7.6 KB | 198 lines

Newsgroups: comp.databases
Path: sparky!uunet!dcatlas!joet
From: [e-mail] (Joe Trott)
Subject: Re: PARADOX 4.0 with Novell: Braindead?
Message-ID: <[e-mail]>
Organization: U.S Dept. of Transportation
References: <[e-mail]> <[e-mail]>
Date: Mon, 4 Jan 1993 16:20:19 GMT
Lines: 187

[e-mail] (Bob E. Hetzel) writes:

>In a previous article, [e-mail] (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.

I've used QEMM for years and love it.  It *does* buy you conventional memory
that may be needed by other apps.  My QEMM line does not include the
EXTMEM parameter, and _does_ include the ROM parameter.  I am assuming that
C800-Cfff is where your network card is living; can this be reduced to
C800-Ca00?  I am also using ST:F; I find that ST:M is not reliable.  In any
case, after making the changes I/we mention, you may want to rerun the
OPTIMIZE program that came with QEMM.

>--
>>    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.

I would agree that SETVER is not needed.

>--
>>    lastdrive=f
>>    FILES=40
>>    BUFFERS=40

You could cut BUFFERS back a bit.  You're using 20K of RAM this way.  If
necessary, look into some disk caching software for better performance.

>>    DEVICEHIGH=C:\DOS\ANSI.SYS

Since you are using QEMM, this should be:
device=c:\qemm60\loadhi.sys c:\dos\ansi.sys    instead.

>>    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.

Make *sure* it is the right COMMAND.COM; re-SYS your drive if you are in
doubt (it probably is though...)

>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.

With QEMM and using LOADHI and LOADHI.SYS, you do not need the UMB portion;
QEMM provides you with the very useful upper memory blocks anyway.  These
can be used to load device drivers (including your network shell) out of
regular DOS memory.   Some rules though: Don't load anything high that swaps
memory itself, e.g. a TSR that only leaves a stub of itself in memory and
swaps when you invoke it to load the rest of itself.  Loaded into high RAM,
this swap will clobber your system.  Also, check (especially older) TSRs
for compatibility when loaded high.  For example, the very useful PRTSCRFF
utility from PC Mag (good for formfeeding laser printers after PrintScreens)
will lock up your machine.

>>    **************************************************************
>>
>>    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.

Assuming you need to run SHARE (some other program, like an email package,
requires it), you can put INSTALL=C:\DOS\SHARE.EXE in your config.sys.
In fact, with QEMM it can be loaded high, with:
install=c:\qemm60\loadhi.com /tsr c:\dos\share.exe

>--
>>    PATH C:\qb45;C:\;C:\DOS;c:\bin;C:\bats;c:\mcshell;c:\windows;

Add \QEMM60 to your path; I have no problem with it being the first.

>>    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.

It may not do anything, but I see there a backslash...

>--
>>    C:\mouse\mouse.com /1

You can change this to   LOADHI C:\mouse\mouse /1   and get your mouse
driver out of conventional memory.

>>    VER
>>    set GRASP=c:\grasp
>>    loadhigh c:\dos\doskey

Use QEMM's LOADHI, not DOS' loadhigh.

>>    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.

Agreed.  The only time I ever use SUBST is on a machine I use when working
on stuff that someone else has hard-coded to use a specific drive.

...  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.

Having just admitted to not using SUBST very often, correct me if I'm
wrong, but isn't this assigning a virtual drive letter D: to the *real*
drive C:, subdirectory \d?  In other words, he already _has_ just a C:,
but perhaps something else is hard-coded to use D:.  That would make the
backup/fdisk/reformat unnecessary (well, backing up is _always_ a good idea).
You may want to reconfigure whatever needs that D: if possible.

>>NOVELL:
>>
Check that people have the relevant rights in the directories, and that
they are using the correct PARADOX.NET and PARADOX.CFG files.  These are
fairly well explained in the Paradox manuals.  Also, Paradox databases and
their supporting files should *not* be flagged Shareable.  Paradox handles
all of the file and record locking.

>>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.

Another option would have been to export the tables' data, empty the tables,
do a Modify/Restructure/DO-IT! (i.e. don't actually change anything) and then
re-import the data.  Or, you could have Created a new table, borrowing the
structure from the old, then a Tools/Copy/JustFamily to copy over the old
forms, export the data from the old tables, import it into the new, delete the
old, and rename the new to the old to match your apps.

>Hope the above suggestions help.

Ditto.

-JTT