At 10:13 2001/05/28 -0400, you wrote:
>Erik Blake wrote:
>
> > Now you only have to search for the patient (DmQueryNextInCategory) and
>presto,
> > you can get the teeth (with DmGetRecord or DmFindRecordByID).
>
>Erik, if I knew how to search for the patient, I wouldn't be asking how to
>search for the tooth! ;-)
>
>I have the exact same problem with searching for the patient as I do with
>searching for the tooth - every search seems to need to know something about
>the item being searched for - the index or the ID - and I don't HAVE those
>values.
My idea was to limit the amount of searching you need to do by storing the
tooth indexes in the patient record.
>Perhaps the answer is this: in order to find a record in a database, if you
>don't know the index or unique ID of that record, you have to do a "brute
>force" search - start at the top, read the record with index 0, and compare
>a value in that record (such as a patient ID number) to the value you're
>searching for, and iterate thru all the records, top to bottom (index 0 thru
>DmNumRecords), until you find a match. Is that it?
Yes. Faster if you sort the DB by ID number and do a binary search (I
assume you know what that means). Typically, you will first built a
selection list for the user to choose a patient from. Since this entails
extracting the name or whatever other human-readable info is relevant, you
might as well also save the index of the patient record in the data field
of the table you are displaying (for instance). That way, the search work
is only done once. Then when the user selects the patient you DO know the
index.
>I'm used to having DB files with searchable "keys" - in my example, the
>patient ID would be a keyed field - so it's very easy to go right to a
>record with a known key value. But I guess that's not possible in a Palm DB,
>because it seems the DB is just a text file - no supporting "keys" for rapid
>searching. Is that right?
Yes. The searches are all in RAM, though, so they are fast.
The DB structure is rather low level in this sense - you are responsible
for creating the key and the appropriate search mechanism. I think the
reason this is so is that if Palm had included a system flexible enough to
handle all possible database contents/formats/indexing schemes, the code
would have been too large (and half the people would want to do it
themselves anyway to keep the response time up).
Erik
-------------------------------------------------------------------
Icefield Tools Corporation tel: (867) 633-4264
3C Glacier Road fax: (867) 633-4217
Whitehorse, Yukon CANADA e-mail: [EMAIL PROTECTED]
Y1A 5S7 internet: http://www.icefieldtools.com/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
