Author Topic: Limit of 255 characters removed for tags in .qea (SQLite) files?  (Read 1386 times)

Heidi V.

  • EA User
  • **
  • Posts: 23
  • Karma: +0/-0
    • View Profile
It seems that the limit of 255 characters is removed for tags in .qea (SQLite) files. The documentation of e.g. the TaggedValue class says that the Value field “has a 255 character limit. If the value is greater than 255 characters long, set the value to “<memo>” and insert the body of text in the 'Notes' attribute.”. See also https://sparxsystems.com/enterprise_architect_user_guide/16.1/add-ins___scripting/taggedvalue.html

I tested this with a string longer than 255 characters, and the text was saved without being cut off. In an exported XMI file, the full text was present as well.

As I understand it, the main difference between normal tags and the so-called memo-tags is that normal tags cannot contain end of line characters or newline characters (or at the least the user interface does not support entering those characters), whereas memo-tags can contain end of line characters and newline characters.

It would be great to have an official confirmation regarding the removal of this limit (and optimally, this would of course be reflected in the documentation).

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13226
  • Karma: +550/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Limit of 255 characters removed for tags in .qea (SQLite) files?
« Reply #1 on: January 15, 2024, 03:40:00 am »
I wouldn't recommend using tagged values longer than 255 characters.
You won't be able to transfer to other database formats.

Geert

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8595
  • Karma: +256/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Limit of 255 characters removed for tags in .qea (SQLite) files?
« Reply #2 on: January 15, 2024, 01:19:01 pm »
I wouldn't recommend using tagged values longer than 255 characters.
You won't be able to transfer to other database formats.

Geert
Wot 'e sed!
We often transfer between different DB formats, and keeping the notion of a non-memo tag as defined for (originally MS _ACCESS) string vs memo is vital for transfers to work sucessfully.

We have had issues with (unwelcome) newline and end-of-line characters being injected into our non-memo fields occasionally, so they can be stored if required.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!