Access 97 - 2000 DAO Differences

[Francis]

I have an application that uses DAO and I have just upgraded from Access 97 to 2000 and DAO 3.51 to DAO 3.6.
The application stores files in memo fields in a database using AppendChunk.
In the DAO 3.6 version the fields are twice the size as those in the previous version.
If I step thru the code I can see that using AppendChunk to append 32k actually increases the field size by 64k when before it was 32k. This applies whether the database is 97 or 2000.
Any suggestions?

 

[PCLewis]

Unicode was changed from 1 to 2 characters I belive.

You can change the setting in table design. But I think that regardless of the compression setting, if the memo field in aany given record has less than 4k of data (after compression), it will not be compressed. So, if you have compression off OR compression is on AND a lot of records with a large amount of data in the MEMO fields, then you will notice the increase in size.

The good thing is that now you can store Chinese (and other non-Latin text) in your memo field natively

 

[Francis]

Thank you that explains a bit. Is there a Microsoft reference to this somewhere?
More information - the data that I am putting in the memo fields is compressed, so I can't see why Chinese or other would make any difference.
By the way am experimenting with changing to OLE fields instead of memos, but it seems the same so far. Have already tried changing the unicode compression setting, to no avail.
Also, the databases when zipped are not that different in size, 10% instead of 100% bigger. It seems inefficient and I don't like files being so much bigger!

 

[PCLewis]

Try F1 Help for a start. I just checked and confirmed what I remember readin in Access help. If you have less than 4k of compressed data in your memo field, which for you means that if you pull it into a string, there are less than 4096 bytes, then the setting of the UNICOD Compression will not save you any space because according to the MS help, if the compressed data is less than 4k, Access won't bother compressing it at all.

Because your database is storing two bytes for every character in your memo field, and because the first is 0 (it's always 0 for Latin character sets), your file compression tool will make some size gains because of this I think.

If you were to use appendChunk to get a bytestream into an OLE field I believe you would get around the problem. Of course then, you would have to treat your data before displaying it - i..e you can't just whack a text field ona form and bind it to your OLE data field and expect to be able to see and edit text data.

I'd stick with the Memo field myself. It's a fact of life that Windows are bringin multi-language support into all of their products. It just can't be helped.

Hmmm I think from memory, a string as stored in VB is also Unicode by default. So 4096 characters stored will take 8192 (+ string descriptor) bytes to store.

 

[Francis]

appendChunk to get a bytestream into an OLE field I believe you would get around the problem"
And indeed that works, thanks.
In fact I was storing picture files in memo fields before, and was compressing them first (using ZLIB).
It seems in DAO 3.51 the memo fields are treated differently to that in DAO 3.6
So have now changed the memo fields to OLE type (although they are not storing OLE objects, just data.
Francis

 

[ZmrAbdulla]

You might have read this

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnardao/html/daotoado.asp

________________________________________________________
Zameer Abdulla
Help to find Missing people
You may be the boss' pet; but you are still an animal

 

[Francis]

Zameer
That is only about porting DAO and ADO - but I am still talking only about DAO
Francis