gibsonlp@csd4.csd.uwm.edu (Dean A Herman) (07/31/90)
Questions, questions, questions. In my eternal wisdom, I turn to the net. After two years of bashing my head against a brick wall "programming" in dBase III+, I'm ready for a change. Actually, I have no choice, a project I'm working on has grown to the point where dBase III+ can't handle any more. So, I've looked around for a better DBMS, mainly looking for speed and a better interface. The demo version of FoxPro 1.02 I've been playing with is, I think, the answer to all my problems. I need more than 15 index/ database/program files, the windows look great, and the mouse support has me walking pinching myself, since the users of this particular application all all upper-level management with little love for or knowledge of computers. I'm most interested in making .EXE files. The thought of having 2+ megs of hard-disk storage used up by dBase III+ or IV on every machine makes me shiver, it'd never do. Although I've read through all the nice glossy ads Fox sent me, and I've browsed the computer publications, I STILL can't tell if I can make .EXE's with FoxPro 1.02 alone, or if I have to go deeper and buy the "FoxPro Unlimited Runtime" at the same time. I am not interested in telling the client that they will need to purchase x versions of a NEW package, that'd never fly. But, if I can just make small .EXE's, they'll build statues in my honor. Also, anyone working with FoxPro...are there any significant drawbacks? It simply CAN'T be a step backwards from dBase III+. I'm working with about 30 databases, 7 of which are heavily used. Importing/exporting is a time consuming headache now, since the databases being moved have up to 150 records in them. I also have a good deal of reports which look into five or six databases. They aren't slow, but I'm wondering how efficient FoxPro is with large databases, and jumping back and forth between numerous databases. As you may guess, any information would be GREATLY appreciated. - Dean Herman gibsonlp@csd4.csd.uwm.edu
lbrintle@umaxc.weeg.uiowa.edu (Lee Brintle,Advantage,337-5200,3374010) (07/31/90)
From article <5433@uwm.edu>, by gibsonlp@csd4.csd.uwm.edu (Dean A Herman): > Questions, questions, questions. In my eternal wisdom, I turn to the net. > I'm most interested in making .EXE files. The thought of having 2+ megs of > hard-disk storage used up by dBase III+ or IV on every machine makes me > shiver, it'd never do. Although I've read through all the nice glossy ads > Fox sent me, and I've browsed the computer publications, I STILL can't tell > if I can make .EXE's with FoxPro 1.02 alone, or if I have to go deeper and > buy the "FoxPro Unlimited Runtime" at the same time. I am not interested in > telling the client that they will need to purchase x versions of a NEW > package, that'd never fly. But, if I can just make small .EXE's, they'll > build statues in my honor. The development version of FoxPro does not compile down to ".EXE" files; in fact, no current FoxPro product (as far as I know) does compile to .EXE. They compile down to .FXP P-Code, which is then interpreted at run-time. Full FoxPro takes up around a Meg, the run-time (which only runs .FXP's, but does not create them) takes around 850K. Fox does, however, say that they will be coming out with an .EXE compiler sometime early next year. lbrintle@umaxc.weeg.uiowa.edu Lee Brintle
jas@ISI.EDU (Jeff Sullivan) (07/31/90)
In article <5433@uwm.edu> gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes:
Questions, questions, questions. In my eternal wisdom, I turn to the net.
After two years of bashing my head against a brick wall "programming" in
dBase III+, I'm ready for a change. Actually, I have no choice, a project
I'm working on has grown to the point where dBase III+ can't handle any
more. So, I've looked around for a better DBMS, mainly looking for speed
and a better interface. The demo version of FoxPro 1.02 I've been playing
with is, I think, the answer to all my problems. I need more than 15 index/
database/program files, the windows look great, and the mouse support has
me walking pinching myself, since the users of this particular application
all all upper-level management with little love for or knowledge of computers.
I'm most interested in making .EXE files.
You're SOL, my boy. It can't be done.
The thought of having 2+ megs of
hard-disk storage used up by dBase III+ or IV on every machine makes me
shiver, it'd never do. Although I've read through all the nice glossy ads
Fox sent me, and I've browsed the computer publications, I STILL can't tell
if I can make .EXE's with FoxPro 1.02 alone, or if I have to go deeper and
buy the "FoxPro Unlimited Runtime" at the same time.
The good news is you don't have to buy FoxPro Runtime to get .EXEs.
The bad news is that there's NOTHING you can do to get .EXEs.
FoxPro is like dBaseIII+, IV, FoxBase+, and most other DB systems, in
that it compiles and runs programs in its environment. If you buy
FoxPro runtime, you get about 700K of programs (FOXPRORT.EXE, .RSC,
and .OVL) that allow you to run FoxPro without a full development
environment, but you've still got your 700K+application program
size+databases to deal with.
There is no standalone .EXE generator for FoxPro. Period. (Please,
sombody flame me to tell me I'm wrong!). If you need that, you might
want to look into Force 2.1 by SophCo, which is essentially a compiler
that handles dBaseIII+ language with some extensions. It's lacking
some major functionality (& macro expansion for one) that akes it
unacceptable to us, so we use FoxPro runtime on our delivery machines,
but we're not grinning.
Also, anyone working with FoxPro...are there any significant drawbacks? It
simply CAN'T be a step backwards from dBase III+. I'm working with about
30 databases, 7 of which are heavily used. Importing/exporting is a
time consuming headache now, since the databases being moved have up to
150 records in them. I also have a good deal of reports which look into
^^^
Is this a typo? We've got 600-1800 records in our DBs, and I'm of the
opinion that they're not very big. Too big, but still not very big.
As you may guess, any information would be GREATLY appreciated.
- Dean Herman
gibsonlp@csd4.csd.uwm.edu
--
--------------------------------------------------------------------------
Jeffrey A. Sullivan | Senior Systems Programmer
jas@venera.isi.edu | Information Sciences Institute
jas@isi.edu DELPHI: JSULLIVAN | University of Southern Californiatimk@xenitec.on.ca (Tim Kuehn) (07/31/90)
In article <5433@uwm.edu> gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes: >Questions, questions, questions. In my eternal wisdom, I turn to the net. > >After two years of bashing my head against a brick wall "programming" in >dBase III+, I'm ready for a change. Actually, I have no choice, a project >I'm working on has grown to the point where dBase III+ can't handle any >more. I know that feeling :-) >I'm most interested in making .EXE files. The thought of having 2+ megs of >hard-disk storage used up by dBase III+ or IV on every machine makes me >shiver, it'd never do. Although I've read through all the nice glossy ads >Fox sent me, and I've browsed the computer publications, I STILL can't tell >if I can make .EXE's with FoxPro 1.02 alone, or if I have to go deeper and >buy the "FoxPro Unlimited Runtime" at the same time. To my knowledge Fox never sold a .exe compiler for their code, they sold 'unlimited runtimes' that you can scatter to the four winds without paying royalties if you want to *PROVIDED* your code tagged along with the runtime. >I am not interested in >telling the client that they will need to purchase x versions of a NEW >package, that'd never fly. But, if I can just make small .EXE's, they'll >build statues in my honor. Well - would you settle for a small pedestal instead? :-) Again, you don't need to purchase x copies, just one of the Developer's copy and one of the Runtime and your company's legit for life. >Also, anyone working with FoxPro...are there any significant drawbacks? It >simply CAN'T be a step backwards from dBase III+. I'm working with about >30 databases, 7 of which are heavily used. Importing/exporting is a >time consuming headache now, since the databases being moved have up to >150 records in them. I don't know how fast db3+ does 150 record moves/imports etc, but in Foxbase these things take place in a flash. (Given reasonable hardware of course). >I also have a good deal of reports which look into >five or six databases. They aren't slow, but I'm wondering how efficient >FoxPro is with large databases, and jumping back and forth between numerous >databases. I've had one system running with > 10 databases and the most heavily used history databases had > 15K records in them, and the response time was always reasonable in my opinion. Ditto reports, indexing, etc. (Although redoing 4-5 indexes per file at 15 - 35K records per file can take a while no matter what you're running!) In short, Foxbase/+ 2.1 and Foxpro 1.02 are the next best thing since sliced bread! (IMNSHO :-) ) ------------------------------------------------------------------------------ Timothy D. Kuehn TDK Consulting Services "Where Quality is Guaranteed" timk@xenitec.on.ca uunet!watmath!maytag!xenitec!timk 119 University Ave. East, Waterloo, Ont., Canada. N2J 2W1 519-888-0766 if no answer 519-742-2036 (w/ans mach) fax: 519-747-0881. Contract services available in Dos/Unix/Xenix - SW & HW. Clipper, Foxbase/Pro, C, Pascal, Fortran, Assembler etc. *Useable* dBase program generator under construction ------------------------------------------------------------------------------
doherty@vax1.tcd.ie (08/01/90)
In article <5433@uwm.edu>, gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes: > Questions, questions, questions. In my eternal wisdom, I turn to the net. > > After two years of bashing my head against a brick wall "programming" in > dBase III+, I'm ready for a change. Actually, I have no choice, a project > I'm working on has grown to the point where dBase III+ can't handle any > more. So, I've looked around for a better DBMS, mainly looking for speed > and a better interface. The demo version of FoxPro 1.02 I've been playing > with is, I think, the answer to all my problems. I need more than 15 index/ > database/program files, the windows look great, and the mouse support has > me walking pinching myself, since the users of this particular application > all all upper-level management with little > I'm most interested in making .EXE files. The thought of having 2+ megs of > hard-disk storage used up by dBase III+ or IV on every machine makes me > shiver, it'd never do. Although I've read through all the nice glossy ads > Fox sent me, Why not try Clipper from Nantucket. It is not an interpreter, which is a disadvantage during developement but one can construct mice interfaces with it and it does produce executable file which do not require the end user to purchase anything from Nantucket. It is also very fast compared to DbaseIII. It is a solid and reliable product. My experience has been with summer 87 clipper. I have no experience with latest version.
gibsonlp@csd4.csd.uwm.edu (Dean A Herman) (08/01/90)
In article <14456@venera.isi.edu> jas@ISI.EDU (Jeff Sullivan) writes: >In article <5433@uwm.edu> gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes: >> >> I'm most interested in making .EXE files. >> >You're SOL, my boy. It can't be done. > No suprise. How about Clipper 5.0? I'm impressed with all the third-party libraries available, especially 3 P's 3PX. The Nantucket marketing-type assured me 5.0 creates stand alone .EXE's. More lies? I hope not. Any Clipper fanatics around willing to throw out opinions? Arago Quicksilver? Maybe I'll just make a dart board... >> Also, anyone working with FoxPro...are there any significant drawbacks? It >> simply CAN'T be a step backwards from dBase III+. I'm working with about >> 30 databases, 7 of which are heavily used. Importing/exporting is a >> time consuming headache now, since the databases being moved have up to >> 150 records in them. I also have a good deal of reports which look into >> ^^^ >Is this a typo? We've got 600-1800 records in our DBs, and I'm of the >opinion that they're not very big. Too big, but still not very big. > No typo, just vagueness, sorry. I meant, some of the .DBF's have 150+ fields. No arrays and all. Using FoxPro on one of the largest editable screens I have is amazing, in comparison to dBase. If I remember correctly, there are 117 fields that must be written. dBase lets me stare at the nice flashing green 'Writing information to database' message. It doesn't even appear with FoxPro. I'll put some dBase manuals under the pillow and hope the DBMS Fairy has a liberal upgrade offer. - Dean Herman, gibsonlp@csd4.csd.uwm.edu ...that those with no rights display the right to have no life... - Skinny Puppy, on animal rights
duvalj@bionette.cgrb.orst.edu (Joe Duval - Entomology) (08/01/90)
In article <5468@uwm.edu> gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes: >In article <14456@venera.isi.edu> jas@ISI.EDU (Jeff Sullivan) writes: >>In article <5433@uwm.edu> gibsonlp@csd4.csd.uwm.edu (Dean A Herman) writes: >>> >>> I'm most interested in making .EXE files. >>> >>You're SOL, my boy. It can't be done. >> >No suprise. How about Clipper 5.0? I'm impressed with all the third-party >libraries available, especially 3 P's 3PX. The Nantucket marketing-type >assured me 5.0 creates stand alone .EXE's. More lies? I hope not. Any >Clipper fanatics around willing to throw out opinions? Arago Quicksilver? >Maybe I'll just make a dart board... Well, I'm still waiting for Clipper 5.0. They were supposed to be shipping on 27 July. Anyway, I've been using Clipper for about 2 1/2 years now. I like it a lot. YES you can create stand alone .EXE's. In fact, that is all you can create. There is no development environment so you use your favorite text editor and compile from the command line. I have a fast (33Mhz 386) machine that I use for development and can use Desqview to have a DOS window for compiling and my editor in another. I can even use Borland's TLINK to do the linking. This becomes a drawback for small programs or for testing hypotheses. You are forced to go through the steps of creating the program, compiling and then running unlike the pseudo-compilers that interpret the code. I don't know what 5.0 will have to offer in place of this but there seem to be plenty of other important goodies. Faster, more efficient compiling, better array handling, etc. The programs are solid, fast, and completely my own. I like it. I can do most everything my C programs can do because I can link Clipper and C. *** I don't have even the remotest affiliation with Nantucket. I just like *** Clipper. -Joe -- Joe Duval duvalj@bionette.cgrb.orst.edu Looking for 62-64 Chevy Nova body parts. I've got a 63 Nova SS forsale.
tomr@ashtate (Tom Rombouts) (08/03/90)
In article <19624@orstcs.CS.ORST.EDU> duvalj@bionette.cgrb.orst.edu.UUCP (Joe Duval - Entomology) writes: > >Anyway, I've been using Clipper for about 2 1/2 years now...< deleted >... >I can even use Borland's TLINK to do the linking. As an aside, TLINK 1.0 or 1.1 work fine, but NOT TLINK 2.0. Whether this is Borland's, Microsoft's or Nantucket's fault has been debated at length elsewhere. Tom Rombouts Torrance Technoid tomr@ashtate.A-T.com V:(213)538-7108
shevett@mccc.uucp (Dave Shevett) (09/29/90)
My company is in the process of converting 100,000+ lines of code over to FoxPro from FoxBase 2.1. We're a little cautious about the major changeover, and are wondering about a few things: 1 - Has anyone had any real problems/bugs with FoxPro v1.02? That's the version we're running, and haven't had anything major crap out, but we just want to be on the lookout for any problems. 2 - FoxPro Runtime v1.02 (and others) have an annoying 'enhancement' - on older versions of FoxBase, you could use the message(1) function to return the line of program code that caused an error. Our error trapping routine used to be able to show us the exact text of an error. Apparently that function has been nuked in FoxPro, unless the .PRG file is available in the running directory. This makes supporting our products very difficult, as we would prefer not to distribute the source code to our clients. Has anyone either found a way around this or heard if Fox is going to put it back in? /--------------------+ +----------------------\ | Dave Shevett | "The shortest distance | Labyrinth II BBS | | Lawrenceville, NJ | between two puns is a | (609) 584-8774 | | shevett@mccc.UUCP | straight line..." | 12/24/19200 PEP 24hrs| \--------------------+ - Doc Webster +----------------------/
shevett@mccc.edu (Dave Shevett) (04/29/91)
We have some 'oddities' cropping up in FoxPro, and we're wondering if some
folks should shed some light on them:
1 - We use 'foxswap' to shell out to applications we're calling from the
programs. (A graphics routine, and a communications program). THe problem
is, repeated usage of this functions tends to accumulate lost clusters on
the drive. Has anyone else seen this phenomenon? We're having a helluva
time finding what's cauusing it.
2 - We have a menu that has a pick that may or may not be available,
depending on the existence of a file. The applicable code follows:
oblslash = iif(file(filename),'','\')
define menu reps
define pad obl of reps prompt oblslash+'3 Out-Bound Bills of Lading (003)' at 7,30
define pad exit of reps prompt '9 Return to Main Menu ' at 10,30
on sele pad obl of reps do rpick with pad()
on sele pad exit of reps do rpick with pad()
The problem is the first time we ACTI the menu, it comes up with option
3 disabled, like we want it to. Then we hide it, and deac it. The *next*
time we make the pick for this menu, option 3 is still not available, but
is not greyed out on the screen. This is more annoying than a problem, but
we're curious what's causing it. Any suggestions?
3 - Our most critical problem is with memory. We want to upgrade all our
customers to FoxPro, but it's memory appetite is appalling. Since we use
Carbon Copy to support our customers, and it munches up 60k when loaded,
we're usually left with right around 500k of memory. I don't want to argue
with QEMM on every steenkin' machine in the world to free up memory
(although that does work fine here). Any suggestions on either getting
FoxPro to use up less memory, or shrinking Carbon Copy or freeing up
general RAM?
Thanx for all (if any) responses!
,___, .--------------------------------------------------------------.
\o.o/ | Dave Shevett | Unix-PC BOF | The shortest distance between |
( \_/ ) | Lawrenceville,NJ | TCF '91 | two puns is a Straight Line |
|_|_| | shevett@mccc.EDU | Apr 20-21st | -- Doc Webster |
'--------------------------------------------------------------'
pew@cs.brown.edu (Peter E. Wagner) (04/30/91)
In article <1991Apr29.141335.19497@mccc.edu>, shevett@mccc.edu (Dave Shevett) writes: |> We have some 'oddities' cropping up in FoxPro, and we're wondering if some |> folks should shed some light on them: You pose some toughies... |> |> 1 - We use 'foxswap' to shell out to applications we're calling from the |> programs. (A graphics routine, and a communications program). THe problem |> is, repeated usage of this functions tends to accumulate lost clusters on |> the drive. Has anyone else seen this phenomenon? We're having a helluva |> time finding what's cauusing it. I'm sure you know that FoxPro creates a temporary file on the disk which it uses for swapping (this is for general use, not just for foxswap). If FoxPro is not shut down properly, this file is left around and causes chkdsk to find lost clusters. I guess that foxswap creates another file or uses the same one mentioned above. Fox says they don't do anything special with this file, it's just a DOS file, but everyone knows that there's something funky there that causes lost clusters. My guess is that with repeated shelling, FoxPro gets confused, and doesn't clean up after itself as it should. |> |> 2 - We have a menu that has a pick that may or may not be available, |> depending on the existence of a file. The applicable code follows: |> |> |> oblslash = iif(file(filename),'','\') |> |> define menu reps |> define pad obl of reps prompt oblslash+'3 Out-Bound Bills of Lading (003)' at 7,30 |> define pad exit of reps prompt '9 Return to Main Menu ' at 10,30 |> |> on sele pad obl of reps do rpick with pad() |> on sele pad exit of reps do rpick with pad() |> |> The problem is the first time we ACTI the menu, it comes up with option |> 3 disabled, like we want it to. Then we hide it, and deac it. The *next* |> time we make the pick for this menu, option 3 is still not available, but |> is not greyed out on the screen. This is more annoying than a problem, but |> we're curious what's causing it. Any suggestions? Sorry, no idea. Don't have a PC handy for testing... |> |> 3 - Our most critical problem is with memory. We want to upgrade all our |> customers to FoxPro, but it's memory appetite is appalling. Since we use |> Carbon Copy to support our customers, and it munches up 60k when loaded, |> we're usually left with right around 500k of memory. I don't want to argue |> with QEMM on every steenkin' machine in the world to free up memory |> (although that does work fine here). Any suggestions on either getting |> FoxPro to use up less memory, or shrinking Carbon Copy or freeing up |> general RAM? I think you're stuck with QEMM :(. |> |> Thanx for all (if any) responses! Sorry I couldn't be of more help. Have you checked out the BB on Compuserve? Invaluable! All the top experts are there. Peter -- ---------------------------------------------------------------- Peter E. Wagner (401)863-7685 pew@cs.brown.edu Department Computer Science Box 1910 pew@BROWNCS.BITNET Brown University, Providence, RI 02912 uunet!brunix!pew Woody Allen when asked if he thought sex was dirty; `If you do it right.' ----------------------------------------------------------------