Ooops, I stated that last point wrong. You can only declare a record of size 65K and therefore are limited to 32768 stored indexes per record (if you were to implement 1 lookup table per record as I have).
Sorry 'bout that. Brad "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}