lily@haydn.kulesat.uucp (04/25/89)
Hi there,
Are there any Clipper-guru's around to help me with a small problem ?
Yes indeed, I do have a problem with Clipper. I also have found a way
to work around it, but i'm not really satisfied.
In an accounting application I wrote some time ago, the DBF-files
have become very big (several hundreds of Kbytes). Accordingly
the NTX-files are also rather big. Now, sometimes when SEEK-ing a
record (with the right index file opened) Clipper can't find it.
Found() becomes .F. although I'm perfectly sure that the record is
in the database. I tried solving the problem by REINDEX-ing, but
it didn't work. Next I tried LOCATE-ing the record. This workes
fine, but it takes a very long time. For the moment I've put up a
construction like this :
.
.
.
SEEK a_certain_index_value
IF .NOT. found()
**
** I'm pretty sure the record is in the database, so look again
**
@ 23, 20 SAY "Trying to locate the record ..."
LOCATE FOR index_field = a_certain_index_value
IF .NOT. found()
@ 23, 20 SAY "Sorry record not in database."
.
.
.
ENDIF
ENDIF
.
.
.
It seems very funny, but sometimes the LOCATE-message appears, and
sometimes the SEEK seems to work. Now this is very annoying, and I would
like to know if you know of a good solution. This all happens when using
Clipper version Autumn '86. HELP !!!
Dirk.
LILY.
Katholieke Universiteit Leuven
E.S.A.T. -- M.I.2
BELGIUM
UUCP : kulesat!lily
BITNET : lily%kulesat.uucp@blekul60alanj@ibmpcug.UUCP (Alan Jay) (04/28/89)
Hi, I hope this helps I have been using Clipper for some time but have never had your particular problem. I now use Summer 87 (which works pretty well as a programming language even if the environment's not great). Now your problem: In article <1081@haydn.kulesat.uucp> lily@haydn.kulesat.uucp writes: >Now, sometimes when SEEK-ing a >record (with the right index file opened) Clipper can't find it. >Found() becomes .F. although I'm perfectly sure that the record is >in the database. I have had problems seeking the solutions iahve used are along the following lines: Check that the item you are seeking can be found TRIM the variable is EXACT ON etc. This can be quite important even with simple keys. Even if you think its right test it out with dBASE III, Fox or DBXL they should give give the same results (if you can get access to a copy). (This is one of the gripes with using Clipper bad development environment). If the construct works then the index may be corrupt. >I tried solving the problem by REINDEX-ing, but >it didn't work. I thought by now everyone had had someone tell them the REINDEX can seriously damage your health, wealth and beauty sleep. I now always use INDEX to recreate index files. I have recently had it sugessted that one should even go so far as to delete the index file before INDEX ON (ah well it makes life interesting). Alan Jay PS Does any one have any other views on the INDEX, REINDEX, delete before INDEX problem. It all seems like its rather circumstantial. -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. -- Alan Jay @ The IBM PC User Group, PO Box 360, Harrow HA1 4LQ ENGLAND Phone: +44 -1- 863 1191 Email: alanj@ibmpcug.CO.UK Path: ...!ukc!slxsys!ibmpcug!alanj Fax: +44 -1- 863 6095 Disclaimer: All statements made in good faith for information only.
bruce@mdi386.UUCP (Bruce A. McIntyre) (04/29/89)
In article <10660@ibmpcug.UUCP>, alanj@ibmpcug.UUCP (Alan Jay) writes: > In article <1081@haydn.kulesat.uucp> lily@haydn.kulesat.uucp writes: > >Now, sometimes when SEEK-ing a > >record (with the right index file opened) Clipper can't find it. > >Found() becomes .F. although I'm perfectly sure that the record is > >in the database. > Check that the item you are seeking can be found TRIM the variable > is EXACT ON etc. This can be quite important even with simple keys. Even > if you think its right test it with dBASE III, Fox or DBXL they should give > give the same results (if you can get access to a copy). (This is one of > the gripes with using Clipper bad development environment). If the construct > works then the index may be corrupt. > >I tried solving the problem by REINDEX-ing, but > >it didn't work. > I now always use INDEX to recreate index files. I have recently had it > suggested that one should even go so far as to delete the index file > before INDEX ON (ah well it makes life interesting). > > Alan Jay @ The IBM PC User Group, PO Box 360, Harrow HA1 4LQ ENGLAND > Phone:+44 -1- 863 1191 Email: alanj@ibmpcug.CO.UK > Path: ...!ukc!slxsys!ibmpcug!alanj Fax: +44 -1- 863 6095 I know that this may seem strange, but if your index has a high number of duplicates, then you may find it may miss one. The algorithyms are good, but not perfect. It sounds to me more like the TRIM problem, but it wouldn't match on LOCATE then either. Clipper .NTX files are sensitive (but no more so than dBASE), and a periodic INDEX ON is called for. Also make sure that the database was created with the correct version of CLIPPER. There are some problems with record pointer references when mixing files between diff- erent versions of dBASE and/or CLIPPER. If you PACK the file with dBASE, Clipper says the records are still there..., etc. The best answer sometimes is to copy "COPY TO xxx" and then "INDEX ON" from the new file. If you are running in clipper, you may want to check the NETERR() function to make sure that the file was readable and the find didn't fail because of an error reading the .NTX file( this even if you are running single user!!!). Clipper will do a certain number of search file operations on a bad file, returning only the "false" without generating a runtime error... bruce -- ========================================================================= Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895 143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915 {wells|lgnp1|prapc2}!mdi386!bruce bruce@wells tbit+ Unix, Xenix, Netware and PC-DOS Applications development. Specializing in Database Applications since 1980.
alexis@ccnysci.UUCP (Alexis Rosen) (05/04/89)
In article <gYK=wvy00WB7AiCG93@andrew.cmu.edu> dp22+@andrew.cmu.edu (David Bruce Pinkus) writes: > Has anybody had any success using the Multi-User version of FoxBase >with TOPS? I haven't seen the Multi-user version, but if it can be done, >I'd appreciate some advice/info. TOPS does not support AFP, and will therefore not support Fox. In fact, as far as I can determine from lengthy discussions with TOPS tech types, TOPS does not support any kind of byte-range or record locking whatsoever. (This is why 4D tends to crash more frequently under TOPS than AppleShare or single-user: It knows it's not getting AFP so it does some bogus page-locking instead.) Fox chose not to do it at all rather than do it wrong. As far as I know TOPS is the ONLY file server product for the Mac for which this is true (of course MacServe and SilverServer, which are both volume servers, don't support it either). TOPS claims that they will support the byte-range locking features of AFP by the end of the year. This would make them compatible with FoxBase. It is my carefully considered opinion that TOPS is in the same position now that MacServe was in three years ago: They currently dominate the market, and they're throwing it all away through marketing stupidity and bad technological decisions. I expect to see TOPS dwindle to a small minority of the market within 24 months. Followups to comp.protocols.appletalk. --- Alexis Rosen alexis@ccnysci.{uucp,bitnet} alexis@rascal.ics.utexas.edu (last resort)
news@uncmed.med.unc.edu (The News Administrator) (05/06/89)
>Alan Jay > >PS Does any one have any other views on the INDEX, REINDEX, delete before INDEX >problem. It all seems like its rather circumstantial. > >-- >Alan Jay @ The IBM PC User Group, PO Box 360, Harrow HA1 4LQ ENGLAND From: danielg@earl.med.unc.edu (Daniel Gene Sinclair) Path: earl!danielg Why use reindex at all? Does it do something special? It's two extra letters to type in. $0.02 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)