Hello Folks --
I have received a few responses to my earlier posting concerning my planned
upgrade of some systems and the problems I faced with the soon-to-be
discontinued Foxbase for Sun by SCO.
THE BOTTOM LINE: dbase IV for Sun is NOT a direct replacement for Foxbase for
Sun. However, there are users out there who use Foxbase 2.1.1
in the 4.1.3 and the 2.x environment. While I could simply
reword the response from Alan Mintz, I won't because he
describes the answer completely and accurately. It is:
-------------BEGIN-----------------------
My god! Another Foxbase+/Sun user? I was beginning to think I was completely
alone! To answer your original question, which SCO didn't, it works fine
on 4.1.3, and Solaris 2.x. The only thing SunView is used for is to
create a fixed size 25*80 window in which to run it. Of course, on 4.1.3,
with only half-":" SunView support, you can't put anything else in front
of the window once it's up, and you can't min/max it. To solve the
problem, I simply created a shelltool of the proper size and had it auto-
matically run the foxplus.pr binary. This works fine. I've included my
mods to the supplied "foxplus" script at the end of my response.
> I called Borland to see if dbase IV could be a direct replacement so that
> changes would not be needed to present applications written for Foxbase.
> They said yes, but with certain qualifications. I feel more than a little
> uncomfortable relying on sales promises (the person who answered the phone
> didn't know Sun was a unix box :^{ ); I have really no time to play around
> with any issues of incompatability - the upgrade starts in 2 weeks.
In a word, "bull". The syntax and abilities of dBase IV are different enough
to require some conversion. A-T, before they were bought out, sold a
product called StepIVWard (step forward) that brings Clipper, Fox, III code
up to IV code. The version I have was written for IV 1.0, and doesn't
deal with a couple instances, notably filtered indices, which I think
are in 1.1.
***********************
The script to replace the "foxbase" startup script is:
***********************
#
# Front-end to foxplus.pr
# Handles multiple arguments
# 9/12/89: modified for hardware, software scrolling options
#
# If Fox has been installed on a non-root filesystem
# then the FOXDIR variable should be changed to reflect
# this fact.
#
#trap "" 4
FOXDIR=${FOXDIR-/usr/lib/foxplus} ; export FOXDIR
ARCH=`/bin/arch`
HARD="-H"
SOFT="-S"
labels=''
case "$1" in
-W*) labels="$1 $2 $3 $4"
shift ; shift ; shift ; shift
;;
*) labels="-Wl Foxbase+ -WL Foxbase+" ;;
esac
#set the defaults by looking at the arch
#set your archetecture defaults here
case $ARCH in
sun3)
CONS=$HARD
term=$HARD
;;
sun4)
CONS=$HARD
# CONS=$SOFT
term=$HARD
;;
sun386)
CONS=$SOFT
term=$HARD
;;
*)
CONS=$HARD
term=$HARD
;;
esac
#if options are chosen overide the defaults
case $1 in
-S | -s | -H | -h)
CONS=
term=
shift
;;
*)
;;
esac
if [ $WINDOW_PARENT ]
then
exec shelltool -I "$FOXDIR/foxplus.sh $CONS $* " -Wp 122 61 -Ws 912 469 -WP 601 3 +Wi -font courier-bold18 $labels
else
exec $FOXDIR/foxplus.pr $term $*
fi
I have altered it to appear in a nice large readable font, but you can change
the -W params to suit your taste. The important thing is that it end up
being EXACTLY 25x80 in whatever font you choose. Also, if you call the script
line with "-Wl xxxx -WL xxxx" as the first four params, they will be passed
to the shelltool as labels for the window, otherwise "Foxbase+" is used.
The only thing I haven't been able to figure out how to do is to get the
shelltool to die after you quit Fox+. It's probably something obvious, but
I can't seem to figure it out :-(
Thanks also to Kurt Sauter who reported that foxbase + is a superset of
dbase III+, and dbase IV is a superset of dbase III+ as well.
"MOST THINGS are compatible between the languages but
not all. My experience shows that most dbase code
will run under foxbase + but not all foxbase + will
run under dbase. Anyway I currently have dBASE IV for unix installed
in a 300 + users sun network environment. dBase
has had some minor problems but on the average it
works ok. I am not thrilled how it handles mult user
code though as I have had bigger problems with
file/record locking."
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:05 CDT