Thanks for the great info Brad. It was definately worth posting, I really appreciate it. I think it's real world examples like this that really enrich the forum. One shoe never fits all, but we call all learn alot from what each other is doing.
Happy coding, -Ron "Brad Figler" <[EMAIL PROTECTED]> wrote in message news:97185@palm-dev-forum... > > I guess I left out the fact that I do not need to use the conduit to do any > type of syncronization. The product that we are developing lives on the > PDA. For what is worth, I will explain how I do it. I don't know if this > can be adapted to work with hotsync. I have not done too much reading on > that subject (yet!) > > Here is what I did. > > I have my own little database header that stores > NumberOfRecords > NextAvaialableIndex > > Both are 0 when the database is created. > When you add a record, both get incremented. > After adding 5 records my header is as follows > NumberOfRecords = 5 > NextAvailableIndex = 5. > > Whenever I need to delete a record, I store the next available position in > that record (assuming your record is atleast 2 bytes in size. You could > always resize the record if needed). For example, if I delete the third > record, my header would be as follows: > NumberOfRecords = 5 > NextAvailableIndex = 2 (zero based). > > The records break down as > Record1 = <data> > Record2 = <data> > Record3 = 5 <--- Next available index pointes here. > Record4 = <data> > Record5 = <data> > > Now, if I delete record 1, my header would be as follows > NumberOfRecords = 5 > NextAvaialbeIndex = 0 (zero based) > > The records break down as follows: > Record1 = 2 <-- Next Avaialbe index points here > Record2 = <data> > Record3 = 5 > Record4 = <data> > Record5 = <data> > > Now, when ever I add another record, it goes in the next avaiable index slot > and updates the header to point to the index that the *deleted* record > pointed at. > > The obvious trade-off for implementing this is that your database never > shrinks in size as records are deleted. However, you can create index > tables that sort by the record index. In my app, I create a separate > database to store the header as well as the index tables that I need (1 > index table per record). Oh, yeah, one more limitation. You can only > support databases with 32,768 records because an actual database can only > store 65565 and each index is two bytes.... > > This probably does not help your dilema with the hotsync. I hope it was > worth something =) > > Brad > > "Ron Clabo" <[EMAIL PROTECTED]> wrote in message news:97084@palm-dev-forum... > > > > Brad, thanks for the response! > > > > If you use the record index as the *Unique ID* how do you deal with > > deletions? I saw that you mentioned that you handle deletions yourself, > but > > that leaves me wondering...How? Do you have need to propogate your > > deletions through a conduit to a desktop app? If so, I'd love to know how > > you are pulling that off while preserving the index numbers of all you > > records. > > > > -Ron > > > > > > > > "Brad Figler" <[EMAIL PROTECTED]> wrote in message > > news:97060@palm-dev-forum... > > > > > > I implemented lookup tables so that I can sort my records in multiple > > orders > > > without changing the record indexes. I needed to do this because I have > > > relational data that stores the actual record index as a *unique ID*. > > > Ofcourse, I have to handle adding, inserting, and deleting myself. > > > > > > It runs great on my m515 and fixed a problem in my owner draw list where > I > > > was displaying text from a record that was being "looked up" by > > > DmFindRecordByID() and was causing the display to be very choppy when > > > scrolling. The records get looked up lightning fast now (actually O(log > > n) > > > time). > > > > > > I would recommend Henk's idea if you are really looking for performance. > > > > > > Brad > > > > > > > > > "Henk Jonas" <[EMAIL PROTECTED]> wrote in message > > > news:97029@palm-dev-forum... > > > > > > > > I did, I stored the unique IDs for 3 different sortings, but I figured > > > > out that it was slower to use them than a standart QuickSort. Maybe it > > > > would be better not to sort at all, but have a sorted list of indexes > as > > > > a kind of lookup table. > > > > > > > > Henk > > > > > > > > Ron Clabo wrote: > > > > > > > > > Seems like this my be a seldom used aspect of the palm database > > > > > architecture. Anyone using the sort info block to boost search > > > performance? > > > > > Any tips? > > > > > > > > > > -Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > ------------------------------------------------------------------------- > > > > [EMAIL PROTECTED] > > www.metaviewsoft.de > > > > > > > > <A > > HREF="http://www.handango.com/PlatformTopSoftware.jsp?authorId=95946";> > > > > <IMG SRC="http://user.cs.tu-berlin.de/~jonash/werbung.jpg";></A> > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
![http://user.cs.tu-berlin.de/~jonash/werbung.jpg"](http://user.cs.tu-berlin.de/~jonash/werbung.jpg"){kind=link}