saxena1@cerc.wvu.wvnet.edu (Naveen S. Saxena) (08/28/89)
I am running dBASE IV Version 1.0 (Where is 1.1 ???) on a Model 50, and have experienced a very disturbing problem - every once in a while, dBASE seems to scramble the file chains, therefore losing a lot of data, and leaving my hard drive in total disarray. Any similar experience/solutions ? Boris Pelakh P.S. Mail answers if possible - pelakh@cerc.wvu.wvnet.edu saxena1@cerc.wvu.wvnet.edu
keithb@hpindda.HP.COM (Keith Broussard) (08/30/89)
Oh yes...this is the same problem I have heard from many, many Dbase IV v 1.0 users. Note the following common problems that I have with Dbase IV: 1. Indexes seem to get corrupted so that large chunks of data are often skipped during sequential searches, or cyclical repetitions of records occur. I.E. An alphabetical listing will skip all names between R and V, for example, or a list will get to Z and start again at C, over and over and over... 2. Pointers to memo fields get all mixed up. Sometimes I go to edit a memo field and I find another record's memo field there, usually incomplete or corrupted. I have not found a suitable way to correct this problem. 3. When using relations, sometimes a seek on a database which is related to another database returns the wrong record (usually the next record). This problem occurs when a seek is done on database A when it is related into database B on a common field: i.e. SELECT 1 USE A ORDER IDNUM USE B ORDER Name IN 2 SET RELATION TO Name INTO B SEEK 500 For me this has returned with FOUND() = .T. but IDNUM = 501, NOT 500. These are my most common problems that I can be specific about, but in general, I have noticed that sometimes records that I am SURE I have entered have mysteriously disappeared. I cannot pinpoint the cause of their disappearance. Reindexing all of my databases on a daily basis seems to help problems 1 and 3, but I have not found a solution to 2. If I encounter a corrupted database, sometimes reindexing doesn't help, but COPYing the database to a temporary database and then back again, then reindexing, helps. I agree that this should not be necessary and is a pain in the **FLAME**. Also, I suffer a lack of confidence in the product, since it seems to have a mind of its own in causing my data to disappear into the "bit bucket". I can't wait for 1.1, since all my code is already written. BTW, I am using 1.0 on a Novell network version 2.12. I suspect that many of these problems are problems with file updating in a network environment. In any case, I don't think that Ashton-Tate has officially recognized these bugs although reports of them are posted all over their own public BBS. If you have written an application for someone else, my suggestion is to include a routine for reindexing databases, and have them run that every morning. Regards, Keith Broussard
mr@cica.cica.indiana.edu (Michael Regoli) (08/31/89)
keithb@hpindda.HP.COM (Keith Broussard) writes: >1. Indexes seem to get corrupted so that large chunks of data are >often skipped during sequential searches, or cyclical repetitions of >records occur. I.E. An alphabetical listing will skip all names >between R and V, for example, or a list will get to Z and start again >at C, over and over and over... i've been experiencing this as well. i'm *damn* glad that i'm not alone in this. ask mr. zuckerman in my database of over 2,500 names. when indexed on the lastname field, mr. zuckerman (and mr. zehr, mr. zobrist, et al.) mysteriously disappear on a random basis. we've created mr. zzzzbar to hold the file's bottom from dropping out but sometimes he goes away as well. it's a pain that i've had to include a reindex menu option (!cringe!) on our secretary's dbms. what gives?! alastair (awd@dbase.UUCP)? has this been reported to a-t? -- michael regoli mr@cica.indiana.edu regoli@iubacs.bitnet ...rutgers!iuvax!cica!mr
steve@violet.berkeley.edu (Steve Goldfield) (08/31/89)
In article <135@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes: #>keithb@hpindda.HP.COM (Keith Broussard) writes: #> #>>1. Indexes seem to get corrupted so that large chunks of data are #>>often skipped during sequential searches, or cyclical repetitions of #>>records occur. I.E. An alphabetical listing will skip all names #>>between R and V, for example, or a list will get to Z and start again #>>at C, over and over and over... #> #>i've been experiencing this as well. i'm *damn* glad that i'm #>not alone in this. #> #>ask mr. zuckerman in my database of over 2,500 names. when indexed #>on the lastname field, mr. zuckerman (and mr. zehr, mr. zobrist, et #>al.) mysteriously disappear on a random basis. #> #>we've created mr. zzzzbar to hold the file's bottom from dropping out #>but sometimes he goes away as well. #> #>it's a pain that i've had to include a reindex menu option (!cringe!) #>on our secretary's dbms. #> #>what gives?! alastair (awd@dbase.UUCP)? has this been reported to a-t? #> #>-- #>michael regoli #>mr@cica.indiana.edu #>regoli@iubacs.bitnet #>...rutgers!iuvax!cica!mr I've seen similar behavior in all versions of dBASE, including McMax, I've used. Generally, these problems are caused by abnormal exits from the program through hard or soft crashes. In most cases, packing and reindexing clears them up. Packing is necessary before reindexing because such crashes often create non-Ascii characters in the database which interfere with its operation. You may also have to delete or clean up such records. I haven't used dBASE IV, but I doubt that it is immune to the same kind of problem. In general, once I get the bugs out of a program, I find that most of the problems users have are caused by bad data, either entered by them or created by a crash. I usually check the data first (after packing and reindexing before trying to solve problems). Even in Ingres, I recently found that a retrieval problem was caused by unexpected data values. Steve Goldfield
timk@xenitec.uucp (Tim Kuehn) (09/01/89)
steve@violet.berkeley.edu (Steve Goldfield) writes: ><135@cica.cica.indiana.edu> mr@cica.cica.indiana.edu (Michael Regoli) writes: >#>keithb@hpindda.HP.COM (Keith Broussard) writes: >#> >#>>1. Indexes seem to get corrupted so that large chunks of data are >#>>often skipped during sequential searches, or cyclical repetitions of >#>>records occur. I.E. An alphabetical listing will skip all names >#>>between R and V, for example, or a list will get to Z and start again >#>>at C, over and over and over... >#> >#>i've been experiencing this as well. i'm *damn* glad that i'm >#>not alone in this. >#> ...stuff deleted.... >#>-- >#>michael regoli >#>mr@cica.indiana.edu >#>regoli@iubacs.bitnet >#>...rutgers!iuvax!cica!mr > >I've seen similar behavior in all versions of dBASE, including >McMax, I've used. Generally, these problems are caused by >abnormal exits from the program through hard or soft crashes. Or just *bad software*. I had a AT version of dbIII+ running a tracking application on a computer that at irregular interval (phases of the moon, president's cramped little toe, who knows?) the index's would get all confused and/or the database would have some records that were *totally* bad (a record of control characters and other misc garbage). Accessing that record would cause the package to go to never-never land, and cause me untold hours of time fixing the problem by writing a program that would, record-by-record copy the old database to a new database, skipping over the offending records, a process which often took at least an hour. (And since I'm a contractor who lives about 20 min. away there's the travel time both ways too....on a Saturday or Sunday morning...grrr...) Interesting thing - on the same machine, with the same program using Foxbase/+ I *never* had that problem again. ...stuff deleted... >In general, once I get the bugs out of a program, I find >that most of the problems users have are caused by bad >data, either entered by them or created by a crash. Bad data? How, in a properly written program, can a USER enter BAD DATA? And even if the stuff the user entered was out to lunch, how could a database package which is writing the record to the dbf file screw the dbf file or the indexes up? In such cases it's *still* the dbms responsibility to take care of keeping everything straight! ...more stuff deleted.... +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Satisfaction Guaranteed| +-----------------------------------------------------------------------------+
steve@violet.berkeley.edu (Steve Goldfield) (09/02/89)
In article <1989Sep1.153527.3489@xenitec.uucp> timk@xenitec.UUCP (Tim Kuehn) writes: I wrote the first: >>In general, once I get the bugs out of a program, I find >>that most of the problems users have are caused by bad >>data, either entered by them or created by a crash. > >Bad data? How, in a properly written program, can a USER enter BAD DATA? >And even if the stuff the user entered was out to lunch, how could a database >package which is writing the record to the dbf file screw the dbf file or the >indexes up? In such cases it's *still* the dbms responsibility to take care >of keeping everything straight! I was going beyond the bad index problem. The most common user complaint I receive is: "I entered the data into the database but your program doesn't find it." Almost invariably, I find that the user mistyped some data (which no reasonable data verification could catch--things like misspelling the name of a company or mistyping an account number). They are always very apologetic when I find the problem. At first, such a problem looks like a possibly bad index, until you find out that the program did what it was supposed to do with incorrect data. I only raised this point because one can save a lot of time reading code if he or she makes sure the data is what it was supposed to be. Steve Goldfield
alexis@panix.UUCP (Alexis Rosen) (09/05/89)
In article <1989Aug31.153729.20204@agate.uucp> steve@violet.berkeley.edu (Steve Goldfield) writes: > [somebody else describes numerous horrible problems in dBase iv, relating > to indices...] >I've seen similar behavior in all versions of dBASE, including >McMax, I've used. Generally, these problems are caused by >abnormal exits from the program through hard or soft crashes. >In most cases, packing and reindexing clears them up. Packing >is necessary before reindexing because such crashes often >create non-Ascii characters in the database which interfere >with its operation. You may also have to delete or clean up >such records. I haven't used dBASE IV, but I doubt that it >is immune to the same kind of problem. [...] >Steve Goldfield I've seen problems like these in databases too numerous to mention, on a variety of platforms. The most recent such pleasures were with Rbase on a PC and Omnis on a Mac. I haven't worked much with larger systems in recent years so I can't comment about them, although I'm sure that those systems which don't have true transaction support are vulnerable to some extent. On the other hand, I've *NEVER EVER* seen FoxBase (either Mac or PC) trash its indices. I'm sure it's possible, and I know how to do it- turn off the disk while it's writing. But if that happens, you've got serious troubles anyway, the least of which is that you need to rebuild an index or two. Unlike other programs, too, Fox is so stable I can't imagine it ever crapping out on its own while writing, so it would take a machine or power failure to bring about such a problem. In fact it's so stable, I can't remember the last time I saw it crash, period. (That's on a Mac, which I use much more than the PC these days, and not including various Beta versions they send me- most of which are perfectly stable as well...) Of course, if (and only if) you are using Fox in single-user mode, and you do lots of database alterations, and then go on to do other stuff without FLUSHing and without waiting for user input, you are asking for trouble, and if the machine crashes, you would likely have to reindex. But I've never seen this either, because FOX DOESN'T CRASH. The point of all this is, a lot of people seem to have been trained to expect shoddy, second-rate software, when they don't need to. I can't imagine using dBase for anything- how can you trust it??? It's a case of DIGO- Data In, Garbase Out. Sort of reverse AI :-). Anyway, now I can get off my soapbox and let people get back to discussing the merits of OODBMSs (which discusion I've been following with some interest). --- Alexis Rosen Owner/Operator, PANIX Public Access Unix uunet!actnyc!jsb, until we get our mail feed fixed, then it will be uunet!cmcl2!panix!alexis
keithb@hpindda.HP.COM (Keith Broussard) (09/05/89)
Gentle notes users, I can assure you that the problems that I cite in the first response of this notes string are not the result of BAD DATA, or CRASHES. My best suspicion at this time is that dBase IV has some problems with concurrency on a network. I have followed the design of the A-T sample programs, basically letting dBase handle file/record locking and providing locking error trapping routines. Thus, I can be sure that (except in the case of memo fields which I'll talk about later), it is not I who is causing the problems. Besides, I've studied and debugged the code for months. Memo fields present interesting problems because of a couple of 'realities' of dbase IV (and DOS). First, there are no variables equivalent to memo fields, so a user editing a memo field requires that the record of the database be locked. It is not possible for the user to edit an equivalent memory variable, thus leaving the database unlocked during edits. Why is it important to leave the database unlocked during edits? Answer: it must be able to be locked exclusively by anyone wanting to APPEND a record. It is possible to copy the contents of a memo field to a text file, and then edit the file, but this raises the second problem with memo fields: If you copy the contents of a memo field to a text file, then edit the file, and leave the database record unlocked in the meantime, someone else may edit the same memo field and someone's data is going to get overwritten. There is no way to check to see if someone else has read the memo field since you read it. Due to the nature of memo fields (they invite long editing sessions) this problem is very likely to occur. I solve this problem by copying the memo field data to a text file WHICH IS NAMED BASED UPON THE KEY FIELD OF THE RECORD, and make sure to check that there is no file by that name which exists before I start editing. Primitive record locking, I guess. While memo fields are inconvenient in dBase IV, they should be used with caution and a "Let the buyer beware" attitude, I believe. However, I find them to work most of the time. The problem with pointers to memo field data getting mixed up is the first OUTRIGHT BUG that I have found with them, though. I AM CONVINCED that there are problems with dBase IV that MUST BE ADDRESSED by A-T. I have had no indication that certain problems which I and others have encountered are being addressed. Some of these problems are discussed in the first response to this notes string. Since I am sure that v 1.1 of dBase IV has had a change freeze for many a month now, I guess I can only WAIT and HOPE for improvements in v 1.1. I would like to see, however, some acknowledgement by A-T that these problems exist and are being considered by A-T. Regards
danielg@ranlo.med.unc.edu (Daniel Gene Sinclair) (09/06/89)
In article <136@panix.UUCP> uunet!cmcl2!panix!alexis writes: >this either, because FOX DOESN'T CRASH. I just want to remark that I am constantly amazed at the numerous postings in praise of Fox. I am a dBASEIII+ user only, and it does great, but my-my, after listening to everyone in net.land, I would buy Foxbase straight off!! I know that Emuleo O.O. (ok, sorry, couldn't remember how to spell it off the top of my head) is right behind me gushing with exclamatories :-). No harm meant E.! Disclaimer: My opinion means | 'If you only knew how much I was holding nothing, but His means | back, you would commend me' everything. | - Charles Spurgeon, 19th century danielg@uncmed.med.unc.edu | evangelist (on humor in preaching)
awd@dbase.UUCP (Alastair Dallas) (09/07/89)
In article <3520010@hpindda.HP.COM>, keithb@hpindda.HP.COM (Keith Broussard) writes: > [good stuff about using memos on a multi-user system deleted] > > I AM CONVINCED that there are problems with dBase IV that MUST BE > ADDRESSED by A-T. I have had no indication that certain problems > which I and others have encountered are being addressed. Some of > these problems are discussed in the first response to this notes > string. We have addressed dozens if not hundreds of problems with 1.0 in the last 10 months. The worst of the problems we addressed have been documented as anomalies on CompuServe; the others were comparatively trivial. 1.0 fits very tightly in 640k and networks make the situation even worse. This may be the cause of occassional hard to reproduce errors, but as I mentioned in my last mail, 1.1 will ease the memory crunch somewhat. You need to provide a simple failing test case, however, if you expect action. Do this and this to data like this and it fails, see? Sweeping statements like "I lose data all the time that I'm sure was entered correctly" may make you feel better, but I can't help you and in the current Ashton-Tate-bashing atmosphere you're just adding fuel to the fire, inviting people to make wild claims like "FoxBase never crashes" <snicker> (Try pasting a MacVision grayscale image into a memo in FoxBase/Mac and watch it eat your hard disk before it dies--the hard disk errors are recoverable, but the entire .dbf is lost.) > Since I am sure that v 1.1 of dBase IV has had a change freeze for > many a month now, I guess I can only WAIT and HOPE for improvements in > v 1.1. I would like to see, however, some acknowledgement by A-T that > these problems exist and are being considered by A-T. > > Regards No, actually, we're doing things differently these days. I probably can't go into it in any detail, but we're experimenting with different software methodologies that let a lot of asynchronous tasks be done in parallel--the notion of a "change freeze" is history, for example. 1.1 will be done when it's done--it won't be shipped on any arbitrary schedule. As I said last time, tell me exactly what to do to make dBASE IV crash, and I can practically guarantee you that we'll hold 1.1 until the problem is fixed. But how can you ask for acknowledgement that these problems exist without explaining them so that we can see for ourselves? /alastair/ Disclaimer: My opinions only, as usual.
emuleomo@yes.rutgers.edu (Emuleomo) (09/07/89)
Path: paul.rutgers.edu!aramis.rutgers.edu!rutgers!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!awd Newsgroups: comp.databases Subject: Re: dBASE IV Problems Summary: Me again. Date: 6 Sep 89 17:22:49 GMT References: <205@cerc.wvu.wvnet.edu.edu> <3520010@hpindda.HP.COM> Organization: Ashton Tate Devlopment Center Glendale, Calif. Lines: 48 In article <208@dbase.UUCP> (Alastair Dallas) writes: >You need to provide a simple failing test case, however, if you expect >action. Do this and this to data like this and it fails, see? Sweeping >statements like "I lose data all the time that I'm sure was entered >correctly" may make you feel better, but I can't help you and in the >current Ashton-Tate-bashing atmosphere you're just adding fuel to the fire, >inviting people to make wild claims like "FoxBase never crashes" <snicker> >(Try pasting a MacVision grayscale image into a memo in FoxBase/Mac and >watch it eat your hard disk before it dies--the hard disk errors are >recoverable, but the entire .dbf is lost.) Thanx for pointing out that bug. I will check it out on my mac!! Seems that you guys over at A-T are now using FoxBase/Mac instead of dBASE/Mac Looks like a good move to me. I also thimk that is a good endorsement of the product. If you ask me, that is what A-T should have produced in the 1st place. BTW, are you guys using Fox 2.1 yet? If so, please post any bugs you come across. I can't seem to find any! Although FoxBase is an excellent product, I'm sure it's not perfect. Only Wordperfect makes that claim. They even changed their name to Word Perfect Corporation!! > Since I am sure that v 1.1 of dBase IV has had a change freeze for > many a month now, I guess I can only WAIT and HOPE for improvements in > v 1.1. I would like to see, however, some acknowledgement by A-T that > these problems exist and are being considered by A-T. > > Regards No, actually, we're doing things differently these days. I probably can't go into it in any detail, but we're experimenting with different software methodologies that let a lot of asynchronous tasks be done in parallel--the notion of a "change freeze" is history, for example. 1.1 will be done when it's done--it won't be shipped on any arbitrary schedule. As I said last time, tell me exactly what to do to make dBASE IV crash, and I can practically guarantee you that we'll hold 1.1 until the problem is fixed. But how can you ask for acknowledgement that these problems exist without explaining them so that we can see for ourselves? /alastair/ Disclaimer: My opinions only, as usual. -- ** Research is what I'm doing when I dont know what I'm doing! **
wew@naucse.UUCP (Bill Wilson) (09/19/89)
From article <Sep.7.05.14.16.1989.2843@yes.rutgers.edu>, by emuleomo@yes.rutgers.edu (Emuleomo): > Seems that you guys over at A-T are now using FoxBase/Mac instead of dBASE/Mac > Looks like a good move to me. I also thimk that is a good endorsement of > the product. If you ask me, that is what A-T should have produced in the 1st > place. > Gee, this is really funny. Can't a Software manufacturer have copies of other peoples work to see how they perform? I called Wordtech on a dBASE III Plus compatibility question and they tried out my problem on dBASE and dbXL. Does that mean that they are now moving over to dBASE? Get real! Although I prefer dbXL, it does not seem strange to me that they would own copies of other products. I don't want to see more flame wars. We all have our favorites! Each product has a niche and yes even Ashton-Tate deserves some credit. They started it all didn't they? Yes, they make mistakes, but I have seen some good ones in other products as well. Let's give some constructive criticism instead of being whiners. nuff' said..... -- Let sleeping dragons lie........ | The Bit Chaser ---------------------------------------------------------------- Bill Wilson (Bitnet: ucc2wew@nauvm | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011