In article <[EMAIL PROTECTED]>, "Danny Epstein" <[EMAIL PROTECTED]> wrote:
> How was the app info block created in the first place? If it was created as > a handle, then it can be resized later. If it was created as a pointer, then > you might not be able to grow it. You can always create a new app info > block, free the old one, and make the database point to the new one. How can you create an app info block as a pointer in the first place? There is no DmNewPtr (only DmNewHandle) and MemPtrNew always allocates in the dynamic heap. On a similar topic: if I want to copy a database with a app info block (or sort info) set ( != 0), is it correct to asume that this value represents a localId of a memory block (on the same card)? Or is an application free to (legaly) store any 32 bit value in this field? How does the OS deal with a database having an app info block not representing a memory block during backup, beaming, deleting etc.? -- Remo <[EMAIL PROTECTED]> / / / / ----------------------------------------- -===(o<0=0=0=0=0=0=0=0>===- Do NOT remove .nospam from email address! \ \ \ -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
