I believe Neil answered the issue, but without realising it, in his item # 6 (see below) Basically he said that an Int (max size ~32K) is used in arithmetic that involves added two index numbers together and dividing by 2. Hence the maximum size of a index number is half of ~32K, which is 16384. To be safe that would be 16383 In conclusion, Steve Patt's empirical observations seem to be entirely confirmed by Neil Rhodes' brief description of the sort logic. If this analysis holds up, Palm Inc. should issue the advice that the maximum number of records in a file is 16383, unless you never need to sort the file, in which case the maximum might be twice that. Roger Stringer Marietta Systems, Inc. ---------------------------------------------------------------------- >If I load 16368 records, and go to the application and perform a sort, >everything is fine. If I now add 22 more records, so I'm up to 16390 (and >past a magic? 16384 barrier), now when I try to sort I get the crash >halfway through the sort (I know from the time elapsed that the crash is >not occuring when the sort finishes and the program goes on to do >something else). This can't be a memory problem because, on the system >I'm trying this on, the database takes up 753K and there is only 505K >free memory, but those numbers don't change significantly between the >success at 16368 records and the failure at 16390. So I therefore >conclude that there is something in DmQuickSort which can't handle a sort >larger than 16384. Hopefully this isn't right, and there's a better >explanation, but I don't have one. > >Steve Patt >President, Stevens Creek Software > http://www.stevenscreek.com/palm ---------------------------------------------------------------------- Subject: Re: Database Sorting Problem From: "Neil Rhodes" <[EMAIL PROTECTED]> Date: Tue, 04 Apr 2000 09:08:46 -0700 >Here's some things I'd think about: >1) When you call DmQuickSort, does your comparison routine get called? How >many times? (If it isn't called any times, then the problem could be the >code at the beginning of DmQuickSort that locks every record). >2) Does DmInsertionSort work OK, or does it also fail. If it succeeds, it's >probably a logic error in DmQuickSort. >3) If you have a source license, you could copy DmQuickSort, along with any >routines it calls, into your own source files, and then set breakpoints, >etc. to figure out what's going wrong. >4) DmQuickSort isn't doing anything that you couldn't do as quick. You could >always write your own sorting routine. >5) Using PalmDebugger (or possibly even CodeWarrior in assembly mode), you >could look at the stack trace when this happens, and figure out what routine >you're in, what index is being passed, where it's being called from, and >relate that back to the source (again, assuming you have a source license). >6) I can see a bug if there are more than 64K/2 records: In the insertion >sort fallback case of PrvQuickSort, there's code that figures out a middle >index based on a left and right index by adding together the left and right >and then dividing by 2 (can't show the code, sorry). These indexes are >defined as Int, and therefore, when either of the indexes is more than >32767, there's a sign issue. Also, when the total is more than 64K, there'd >be a truncation problem. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
