This has to do with this kb item:

What we are trying to do is limit the size our image memo file gets by asking our users to archive their images. This involves extracting the image from the table's memo and storing it in a zip file off disk.

According to the article this does not mark the section for re-use, only for deletion. In the solution from the article it states to "Update the memo data in place". What exactly does that mean, and how can I do that during our archive process?

Thanks for your time, Dusten

asked 31 Oct '13, 15:38

FLDelphi's gravatar image

accept rate: 75%

edited 31 Oct '13, 15:42

Used memo blocks are orphaned if a memo is set to empty. The following code will orphan the memo blocks that used to be occupied by the memo fields.

AdsSetEmpty( hTable, "memo1" );
AdsSetNull( hTable, "memo2" );
AdsSetString( hTable, "memo3", "", 0 );
AdsSetBinary( hTable, "memo4", ADS_BINARY, 0, 0, NULL, 0 );
AdsWriteRecord( hTable );

I think what "Update the memo data in place" is meant to say when changing the content of a memo or blob field, do not set the memo field to empty first before replacing it with the new content. Instead, just set the memo/blob to the new content.

You can recover the orphaned memo blocks by packing the table.

There is also a kludge to reduce orphaned blocks. If memo/blob is update to contain a very short string or binary data (1 byte for example) and posting the record first, then update the field again to set it to empty. This will resulted in at most 1 memo block being orphaned.


answered 01 Nov '13, 07:46

Alex%20Wong's gravatar image

Alex Wong
accept rate: 42%

edited 01 Nov '13, 08:18

Thanks Alex. I'll give the kludge method a try.

(01 Nov '13, 08:16) FLDelphi

I should add that the kludge will introduce fragmentation that may still resulted in bloated memo file eventually. It should work well if the memo/blob data are not uniform in size. If the memo/blob are always the same size in general, then this will not help much.

(01 Nov '13, 08:27) Alex Wong

You were right about that. Sizes range from 71kb to 132kb. After adding about 46 MB worth of images, removing them via the kludge method, adding them back in, there is still a waste of 5MB.

During this testing I found something interesting.When I delete the entire record containing the memo, there doesn't seem to be any waste: If I add 46MB worth of images, and instead of nulling the memo, just delete the records, then add the same images right back into the table, the ADM file does not change in size.

This is exactly the behavior I need. Why/How is it different from nulling the memo field?

(13 Nov '13, 10:55) FLDelphi

When a record is deleted, the server does recover all memo blocks used by the record. The orphaning only happens when a memo/blog field is set to NULL or empty. In such case, the client does not tell the server that the memo/blob block are no longer in use. It is unclear to me what is the reason for this implementation but it has been this way since the beginning. If I have to guess, it was for simpler implementation. And the thinking was that memo/blob were rarely removed completely.

(13 Nov '13, 11:33) Alex Wong
Your answer to the original question.
If responding to a request for additional information, please edit the question or use the comment functionality.
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 31 Oct '13, 15:38

Seen: 1,517 times

Last updated: 13 Nov '13, 11:33

Advantage Developer Zone Contact Us Privacy Policy Copyright Info

Powered by Advantage Database Server and OSQA
Disclaimer: Opinions expressed here are those of the poster and do not necessarily reflect the views of the company.