Yes, there is a magic formula and it differs between OS 2.x and 3.x
Both OS versions have a DB overhead of 84 bytes
Both OS versions allocate DB memory in 4 byte chunks (so a record of 2 bytes
will have an actual size of 4)
Here's where they differ:
OS 2.x has a record overhead of 14 bytes so my record of a UINT, INT and 2
floats (4+ 2 + 8 + 8 = 22 bytes / 4 = 5.5 =>24bytes) will have a record size
of 38 bytes
OS 3.x has a record overhead of 16 bytes so my record of a UINT, INT and 2
floats (4+ 2 + 8 + 8 = 22 bytes / 4 = 5.5 =>24bytes) will have a record size
of 40 bytes
My DB with 2 records in OS 2.0 is 84 (DB Overhead) + 2 * 38 = 160 bytes
In OS 2.0 with 2 records is 84 + 2*40 = 164 bytes
I haven't checked these numbers, I'll look for my notes and verify
everything is correct. I am using this method in a program and predicting
the size of my data with 100% accuracy in both OS 2.x and OS 3.0
Dave
-----Original Message-----
From: Christopher Hunt <[EMAIL PROTECTED]>
To: PalmOS Developer Forum <[EMAIL PROTECTED]>
Date: Monday, June 21, 1999 6:55 PM
Subject: Q: True Recordsize
>Does anybody know how to obtain the true record size of a record in a
>database?
>
>I have a scenario where DmNewRecord allocates successfully and returns a
>handle. If I then subsequently obtain the handle's size I sometimes find
>that the Data Manager has reused some previously allocated space
>(possibly from a deleted record). Consequently the handle size is larger
>than what I previously declared to DmNewRecord.
>
>I acknowledge that other things could be causing the above behaviour but
>I have looked long and hard and this is what I finally conclude. Any
>validation of my observations would be greatly appreciated.
>
>Regards,
>--
>Christopher Hunt
>Class Action Pty. Ltd.
>
>Are you a time zone traveler that owns a Palm(tm) connected organizer?
>Check out http://www.classactionpl.com/TimeTraveler/index.htm
>
>
