"Abusing" ACDSee Metadata fields for diffrent Content

[Aderalia]

Hello!
I use ACDSee Pro 10 to keep track of a Image Archive (to quickly find images out of my stock etc.) All those Images are in zip archives (to reduce file count on the server which uses a file based parity system). To prefent clients from corrupting or modifing files the archive is a "Read Only" share.
Accessing the images is no problem but since the files are read only i cant use the IPTC and EXIF tags to catalog my Files, instead i am forced to use the ACDSee Metadata system (nothing wrong with that). My Problem now beeing i need to save some string type data for every image. This sadly cant be done with ACDs hierarchy tag system since its already used to describe a pictures content.
I found some information on the Forum that said i cant create any custom fields for ACD Metadata, so i need to reporpuse the existing ones. To do this i need to know which field can store what type of information (and how many of it).
For example: I notices the field called "Etikett" in German ("Tag" in english i gues? Its the one that gets used to store the red yellow blue green and purple colour Tags) can also store text, but how much? And will this cause any problems with database performance?

[Emil]

Etiketten are called 'Labels' in English versions of AC. They are text only and their maximum length is exactly 1,000 chars. If you want to misuse them be aware that they are displayed in the breadcrumbs and the title bar of AC.

I don't think that a larger number of different labels will slow down AC. Can it be worse than it already is?

You could also use the tag 'Anmerkungen' called 'Notes' in English. This also accepts quite rather lengthy strings. But by pasting very large amounts of text you will provoke a buffer overflow and can easily crash AC and also corrupt the database.

[Aderalia]

Thx for your answer!
I also did noticed that ACDSee was getting slower and slower over the releases, but i thought its due to the fact that im using more and more archives streamed from a remote server, but on the other hand 10 GBits shouldnt be a bottleneck Might actualy be the database...
Thousend characters is more then i need I would have been ok with even 255 Its just some Names going in there.
The Notes field is were stuff could (at least in theorie) reach the Neighborhood of 1k chars.

My current plan is the following:
Put a ID (Number that collects Images of the same "Set") into the Label field
Put the disclaimers and other legal stuff (can reach 1KByte in theorie) into the "Notes" Field since it kinda seems to be the biggest
Put Names (should stay way bellow 1KByte) in "Beschriftung" ("discription"?)

This way i hope im getting the least problems... The alternative would be to have a Access Database to go along with the image archive and put everything in there. (might be faster to search but less convinient)

Or even better would be a way to disable ACDSee from chaning any of the Images content apart from the IPTC Tag section (opening images read only). In that case i could drop the Read only file system and would not have that Problem.

[Aderalia]

Well turns put Emil was right... Filling the Fields with to much data does cause crashes, and lots of em too!
It worked fine for a time but seems to develop into a problem over time.
In the End i went for the Access method, im currently searching for a way to quary a search in ACDSee from something like a C# script i could attach to my access form, no luck so far tho.