Path: utzoo!mnetor!uunet!husc6!bbn!rochester!ur-tut!sunybcs!boulder!ncar!oddjob!gargoyle!ddsw1!karl From: karl@ddsw1.UUCP (Karl Denninger) Newsgroups: comp.sys.ibm.pc Subject: Re: dBase III+ (was dBSAE Fat Kil (was Re: corrupt FATs?)) Message-ID: <888@ddsw1.UUCP> Date: 20 Mar 88 20:12:04 GMT References: <9765@shemp.CS.UCLA.EDU> <315@wsccs.UUCP> <966@bingvaxu.cc.binghamton.edu> <1218@silver.bacs.indiana.edu> Reply-To: karl@ddsw1.UUCP (Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 36 Summary: Two things... In article <1218@silver.bacs.indiana.edu> regoli@silver.UUCP (michael regoli) writes: >In article (Cliff Joslyn) writes: >-In article (Bill Housley) writes: >->Once I did the famous DBaseIII-editor-file to big-fry >->your fat-#@$^&*#$ mistake and spent 4 hours finding a disk utility that >->would help me re-construct it. >- >-Uh, could you *please* tell us what this was again? > >yes, please elaborate on this problem! how does it happen? > >and, while on the subject of dbase, can someone tell me about the >maximum record size for a .dbf file? i heard after 2,500 records, >an indexed database file it begins to act flaky... >...ihnp4!iuvax!silver!regoli I don't know about the FAT killer, but I do know about wierd index file problems and dBase III. Seems as though your index expressions should be an exact multiple of 4 bytes. Never did figure out exactly what the failure mode was, but things got really wierd if we violated this assumption. We saw problems way before 2500 records, though -- like immediately. Then again, our products do some rather "interesting" things with index files :-) Right now we have 3500+ records in a couple of dBase III databases (on clipper and foxbase) and see no trouble at all... Both the Clipper and Foxbase + do not exhibit the 4-byte anomoly (guess what we do our development under now :-). ---- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"