dparker@xroads.UUCP (David M. Parker) (01/20/88)
I have heard rumors that Ashton Tate will be bringing out dBase IV shortly. Is the rumor true and, if so, what will the enhancements be like? Thanks in advance, Dave Parker (dparker@xroads) -- \ / C r o s s r o a d s C o m m u n i c a t i o n s \/ (602) 971-2240 /\ (602) 992-5007 300|1200 Baud 24 hrs/day / \ ihnp4!crash!xroads!*
karthur@codas.att.com (Kurt_R_Arthur) (01/23/88)
In article <421@xroads.UUCP> dparker@xroads.UUCP (David M. Parker) writes: > > I have heard rumors that Ashton Tate will be bringing out dBase IV shortly. > Is the rumor true and, if so, what will the enhancements be like? Rumored improvements include use of "interpret on the fly" psuedo-code generation to significantly decrease execution time (but it is not as fast as FOXbase or the other compilers), some new functions, a new 'assist' feature more powerful than the one in dBaseIII+, better LAN support, and an increase in the number of modules in a catalog (presently 32, soon ?). Enhancements not added are a compiler, memo field query, and arrays. In short, A-T has raised the standard, but not by as much as most had hoped. Kurt Arrhur Software Services of Florida, Inc.
regoli@silver.bacs.indiana.edu (michael regoli) (11/14/88)
]:[ decisions, decisions. i've long ago received my upgrade invitation to go from III+ to IV. however, why upgrade now when the rumor is that the dbase version shipping today will go out with documentation printed in *JUNE* that no longer matches features of the program?! has anyone received their official upgraded version of IV? if so, are there the thousands of bugs present that everyone is speaking of? (3,000 rumored "bugs" as of september.) is it compatible with ms-dos version 4? what's it like? thanks for your response. i will post a summary of IV's status... -- | | michael regoli | ...rutgers!iuvax!silver!regoli | regoli@silver.bacs.indiana.edu |
awd@dbase.UUCP (Alastair Dallas) (04/27/89)
Ken Sellards says that dBASE IV doesn't erase its temporary files and I thought he was wrong until I found that I can duplicate the problem. We'll have it fixed in the next release. The problem is that uniquely- named files with the extension "$VM" are left around (one per session) when you leave dBASE. The files are typically 0 bytes. One way to mitigate this problem is to use an undocumented feature, but even that doesn't help much. The feature is: - Create a DOS environment variable called 'TMP' and point it at a RAMdisk or a special subdirectory, such as: SET TMP=E:\ (E: is a RAMdisk, VDISK, etc.) or SET TMP=\TMP\ MD \TMP - dBASE IV will now write its temporary files to the specified directory, which can be cleaned up periodically (ERASE \TMP), or to the RAMdisk, where rebooting will erase them automagically. I hope this posting has a higher information content than Ashton-Tate- bashing or In-defense-of-dBASE mail. /alastair/
coop@cerc.wvu.wvnet.edu (Boris Pelakh) (09/28/89)
A strange thing happened to me today in the land of dBASE IV :) I have a file with 1518 records in it. I do an append blank, then assign recno() to a variable. It now contains 1519. I do some operations on the file and then do a goto to that record #. dBASE gives me a "record out of range" error, but GOES to the right record !!! (after I choose Cancel or Suspend on the popup that occurs, the record pointer is at 1519. If I choose Ignore, the application keeps running without problems. Very strange !!! Suggestions ? Alastair : How does one become a beta tester for Ver. 1.1 ? I would be interested. Boris Pelakh.
awd@dbase.UUCP (Alastair Dallas) (09/30/89)
In article <248@cerc.wvu.wvnet.edu.edu>, coop@cerc.wvu.wvnet.edu (Boris Pelakh) writes: > I have a file with 1518 records in it. I do an append blank, then > assign recno() to a variable. It now contains 1519. I do some operations > on the file and then do a goto to that record #. dBASE gives me a > "record out of range" error, but GOES to the right record !!! (after I > choose Cancel or Suspend on the popup that occurs, the record pointer > is at 1519. If I choose Ignore, the application keeps running without problems I went to duplicate your bug. I created a 1518-record file and did: APPEND BLANK x = recno() <some operations> GOTO x This doesn't cause any problem for me. Of course, it could be that I picked different operations to try :-). Could you be more specific? > Alastair : How does one become a beta tester for Ver. 1.1 ? I would be > interested. > > Boris Pelakh. I have heard that we may go to hundreds of beta sites with 1.1, and the people who administer that effort act as if they already have thousands of requests. However, there's no harm in writing to the only name I know in the beta-test department: Tom Brcka (pronounced "birch-ka") Ashton-Tate 20101 Hamilton Avenue Torrance, CA 90502-1319 I'm sure Tom would appreciate a letter outlining your reasons and qualifications w.r.t. beta testing 1.1, rather than a phone call. Feel free to mention my name (for all the good it'll do you :-). /alastair/
rwilliam@grebyn.com (Roger Williams) (10/02/89)
> Alastair Dallas in article <266@dbase.uucp> writes > In article <248@cerc.wvu.wvnet.edu.edu>, coop@cerc.wvu.wvnet.edu (Boris Pelakh) writes: > > I have a file with 1518 records in it. I do an append blank, then > > assign recno() to a variable. It now contains 1519. I do some operations > > on the file and then do a goto to that record #. dBASE gives me a > > "record out of range" error, but GOES to the right record !!! (after I > > choose Cancel or Suspend on the popup that occurs, the record pointer > > is at 1519. If I choose Ignore, the application keeps running without problems > I went to duplicate your bug. I created a 1518-record file and did: > APPEND BLANK > x = recno() > <some operations> > GOTO x > This doesn't cause any problem for me. Of course, it could be that I > picked different operations to try :-). Could you be more specific? I had the problem described by the poster of the initial article. I found that preceding the program with PUBLIC x . . x = recno() <some operations> GOTO x solved the problem. Apparently if the operations include a "Do" statement the contents of x are lost if x is a private variable. Defining x as a PUBLIC variable solves this problem. Give it a try anyway and see how it goes. rtw rwilliam@grebyn.com
coop@cerc.wvu.wvnet.edu (Boris Pelakh) (10/03/89)
In article <266@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > I went to duplicate your bug. I created a 1518-record file and did: > > APPEND BLANK > x = recno() > <some operations> > GOTO x > > This doesn't cause any problem for me. Of course, it could be that I > picked different operations to try :-). Could you be more specific? > I found a most interesting quality in this error. In the <some operations> block, I was modifying the field that was the current key field. Somehow, it was not entered into the index (AUTOSAVE matters ?!) and when trying to go to it, it was giving the out-of-range. If a reindex was put before the goto statement, all went smooth. Could that be the reason ? Boris Pelakh. "Software - a spell one casts pelakh @ cerc.wvu.wvnet.edu on a computer to transform input into errors." - Me.
awd@dbase.UUCP (Alastair Dallas) (10/04/89)
Excuse me for posting to the net--I can't reach Boris by email and I'd like to solve this problem. In article <256@cerc.wvu.wvnet.edu.edu>, coop@cerc.wvu.wvnet.edu (Boris Pelakh) writes: > In article <266@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > > I went to duplicate your bug. I created a 1518-record file and did: > > > > APPEND BLANK > > x = recno() > > <some operations> > > GOTO x > > > > This doesn't cause any problem for me. Of course, it could be that I > > picked different operations to try :-). Could you be more specific? > > > I found a most interesting quality in this error. In the <some operations> > block, I was modifying the field that was the current key field. Somehow, > it was not entered into the index (AUTOSAVE matters ?!) and when trying to go > to it, it was giving the out-of-range. If a reindex was put before the goto > statement, all went smooth. Could that be the reason ? > > Boris Pelakh. "Software - a spell one casts > pelakh @ cerc.wvu.wvnet.edu on a computer to transform > input into errors." > - Me. I still need more information to recreate the problem. What I have is: Create a 1518-record file indexed on a field called Key. Then: APPEND BLANK x = recno() REPLACE Key with "Something" GOTO x This does not fail for me on the version you have, which we call x322 internally. No, AUTOSAVE should not matter here. What might matter is if the index is UNIQUE, and the "out-of-range" error is not "Record out of range" but rather "Record not in index". I need the exact details of your environment and what steps come between APPEND BLANK and GOTO in order to track this down. You've really got me curious, that's for sure! /alastair/
doug@herbert.uucp (Doug Phillipson 5-0134) (01/14/90)
I have heard that DBASE IV is very buggy. Can any experienced users of this product give concrete examples of this. Douglas Phillipson (EG&G)
foot@tc.fluke.COM (Andrew Proudfoot) (01/16/90)
We are considering using Ashton-Tate's dBase-IV for a production
application. I have no experience with dBase myself. I know the SQL
portion of dBase-IV is buggy. Our in-house "dBase expert" believes
we're safe if we use no SQL, relying instead on the traditional dBase
programming language, application generator, etc. Is he correct?
Andy Proudfoot || domain: foot@tc.fluke.COM
John Fluke Mfg. Co., M/S 58 || uucp: {uw-beaver,microsoft}!fluke!foot
PO Box C9090 ||
Everett, WA 98206 || phone: (206) 356-5446cy@dbase.A-T.COM (Cy Shuster) (01/19/90)
In article <1990Jan13.221901.6381@herbert.uucp> doug@jimi.cs.unlv.edu (Doug Phillipson 5-0134) writes: > > I have heard that DBASE IV is very buggy. Can any experienced >users of this product give concrete examples of this. > >Douglas Phillipson (EG&G) In addition to soliciting info from other users, please try it for yourself, on your hardware, with your LAN software (if any). dBASE IV runs on an extremely wide variety of environments, including DOS 2.1 (!) through 4.0; your mileage may vary. --Cy-- cy@dbase.a-t.com
elliott.chapin@canremote.uucp (ELLIOTT CHAPIN) (02/11/90)
An index (MDX) problem, hopefully answerable by someone among those out there who have had a chance to explore dBASE IV more intensively than I have since its arrival (I haven't had very good luck via A-T on Compuserve): the index in question is an IIF of the concatenation of 2 trimmed character fields ( both fields length 21), order of concatenation dependent on the contents of another field. The index works, and I can do successful index key searches off BROWSE with substrings; the catch is that dBASE will not allow the search string to be more than 21 characters long(?!). This is not terribly important for practical purposes, but IT SHOULDN'T BE HAPPENING ! Elliott Chapin --- * QDeLuxe 1.10 #4315
awd@dbase.A-T.COM (Alastair Dallas) (02/16/90)
Elliot Chapin mentioned a problem with dBASE IV indexes. He cites a detailed description of the problem, but the answer is clear from the first sentence. You can't index on TRIM(field), because the resulting key length is indeterminate. You can do it; it will work for some data so the system allows the construct, but the results are as indeterminate as the key length. In this case, the index code "guesses" how long the key should be based on the current record's data--for Mr. Chapin, it seems to guess 21; your mileage may vary. Lest you think "dBASE is squirrelly to allow such a thing," you should realize that any dBASE expression evaluating to a data type other than Logical or Memo is a valid index key expression. So you can say: Mvar = "A test string " INDEX ON TRIM(Mvar) && Key is fixed at 13 USE Foo && Contains a field called Name INDEX ON TRIM(Name) && Key length ??, not useful to continue USE Foo1 INDEX ON 5+3 && Adds a key (8) for each record in Foo1 dBASE is either extremely squirrelly or extremely flexible, depending on your point of view. For my money, it's both :-). /alastair/
elliott.chapin@canremote.uucp (ELLIOTT CHAPIN) (02/17/90)
Thanks for your answer! I would have said that the allowable search string length in the case I described could have been set as the sum of field lengths (+ 1 for an internal blank I added). I can see, however, that such problems might in general place unreasonable demands on the program. Elliott Chapin --- * QDeLuxe 1.10 #4315
gunnar@imf.unit.no (Gunnar Taraldsen) (01/25/91)
I would much appreciate if someone could answer the following questions conserning dBASE IV: >> 1. I run into the message: "Insufficient memory ..." when DO'ing relatively small *.prg files. I have all the PROCEDURE/FUNCTION declarations in one file and I suppose I could save some memory if I splitt the file, but then the application becomes to slow. I run the application on a Copam 386sx with 4MB RAM. What shall I do?? >> 2. Is there a way in dBASE IV to check if a variable is defined and/or wich type it has? I can do it in Clipper, but... >> 3. Is there a way to avoid using *.fmt (or *.fmo) and still associate PICTURE and FUNCTION options to selected variables when entering BROWSE/EDIT? (I think about speed ... I've tried to just put @ ... GET ... statements in front of the EDIT/BROWSE command, but it didn't work as expected.) >> 4. Recursive calls to BROWSE/EDIT are not allowed. Is there a way to get around this restriction? Please respond to gunnar@imf.unit.no if you have any answers. Thanks Gunnar Taraldsen
awd@dbase.A-T.COM (Alastair Dallas) (01/28/91)
Email doesn't work very well for me, so I'm posting this reply. In article <1991Jan25.124902.15522@ugle.unit.no>, gunnar@imf.unit.no (Gunnar Taraldsen) writes: > I would much appreciate if someone could answer the following > questions conserning dBASE IV: > > >> 1. I run into the message: "Insufficient memory ..." when > DO'ing relatively small *.prg files. > I have all the PROCEDURE/FUNCTION declarations in one file > and I suppose I could save some memory if I splitt the file, > but then the application becomes to slow. If you're out of RAM, you're out of RAM. If your file is very large, you should split it up (most dBASE applications consist of many small files). dBASE IV includes a fairly smart segment loader; I'd like more information about why your application gets slow using more than one procedure file. > >> 2. Is there a way in dBASE IV to check if a variable is defined > and/or wich type it has? I can do it in Clipper, but... The TYPE() function will return "U" if a variable is undefined. A = 1 ? TYPE("A") N ? TYPE("B") U > >> 3. Is there a way to avoid using *.fmt (or *.fmo) and still > associate PICTURE and FUNCTION options to selected variables > when entering BROWSE/EDIT? (I think about speed ... No, that's what .fmt files are for. Generally speaking, having a few extra files open should not cause noticable slowing--perhaps there is something unusual about your situation? > >> 4. Recursive calls to BROWSE/EDIT are not allowed. > Is there a way to get around this restriction? Glad you asked. Version 1.1 includes a command: SET DBTRAP OFF which will allow you to call BROWSE/EDIT recursively. You must be careful to avoid damaging the parent BROWSE's environment (don't reposition the record pointer, don't close the file, etc). This is akin to an 'expert' mode--RTM, page 3-32. Hope it helps. /alastair/