Suggested Maximum length for a field
Dawn Wolthuis
Property Comment As %String(MAXLEN = "", ...);
We have a dataBinding in Zen to a textarea. If a user enters a huge
amount of text (~3.4 million chars was the test), the end user
experience was that their information was not saved. The record was
there. However, it had issues. When executing an SQL query, for
example, we got the following message on a Zen tablePane
ERROR #5540: SQLCODE: -400 Message: Unexpected error occurred:
<MAXSTRING>%0AmDuncommitted+1^CacheSql13
We will either add MAXLEN=<some integer>, TRUNCATE=1 back into the
file and/or perform at last a client-side validation for a max length.
So, here is a bit of a flaky question -- if we would be good with a
large comment, but do not need it to be larger than what can be
handled nicely with %Save() and bindings to Zen textareas, what would
be a sweet number to use? For example, would a MAXLEN of 10,000
20,000, 32,000 and 100,000 all be the same to Cache' while 256,000
would be different (just pulling numbers out of a hat)? For those who
know the innards or have tested this out, what size would you pick for
a long comment field if you really didn't care how large it got
"within reason"?
Thanks. --dawn
--
Dawn M. Wolthuis
Take and give some delight today
Michael Cohen
"Caché supports the use of extremely long strings on an optional, per-instance basis.
With long strings enabled, the maximum length of a string is 3,641,144 characters; without long strings enabled (the default), the maximum length of a string is 32 KB."
Since we recommend for MV users that "Enable long strings" be set via SMP, this is consistent with your result.
I don't know if there is a performance difference between say a 100KB string and a 2MB string, and leave that to others to comment.
But can't imagine wanting to enter or read text comments of that size, and suspect that a reasonable limit makes sense.
Streams are available if really large text or binary data needs to be stored.
--
You received this message because you are subscribed to the Google Groups "InterSystems: MV Community" group.
To post to this group, send email to Cac...@googlegroups.com
To unsubscribe from this group, send email to CacheMV-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/CacheMV?hl=en
Dawn Wolthuis
doing the %Save(), truncating it and moving on. We could open the
record in the editor afterwards, so the MV side might have been
handled just fine this way, but there was something amiss from the
user experience side in our software as the user did not see their
comment on the next screen where it was specified with a dataBinding
to a label (so no doubt somewhere there is a limit on the label I
should be able to track down, but it didn't show a truncated version,
it left it off completely using Zen MVC)
<label id="Comment" name="Comment"
dataBinding="Comment"
label="Comment made while signing up, if there is one"
readOnly="true"
controlClass="labelTextArea" enclosingClass="labelArea"
controlStyle="background: #FFFFFF;border: none"
/>
Then the user got the SQL error on the next screen where the comment
should have shown in a table (currently without any truncation
specified for the table cell, which needs correction for sure).
I want to permit reasonably long text strings here, but they need not
be so long as to become streams.
What is the max size string that MVC and SQL can handle gracefully
(even if not showing the entire thing, at least not choking)?
It isn't clear to me that hard-coding 3,641,144 (which is longer than
needed, no doubt) as a maximum length before saving would solve the
problem. I suspect that number needs to be smaller to make all IO
approaches (e.g. MVC, SQL) happy. Instead of just grabbing a number
out of the air, I would be pleased as punch to hear suggestions (with
rationale if possible).
Thanks a bunch. --dawn
Ross Ferris
Speaking from a position of absolutely no experience with Cache, I would suggest setting the figure at 10-20K
In the real world, I would imagine that 100-200 might be sufficient, 1-2K might get used if people were really keen, and if someone WANTS to enter 10 pages of textual data in, then 20K would be sufficient. Sure, there may be a 1 in a million situation were there is a legitimate reason for more, but the other 999,999 people will be as happy as pigs in .... well, as happy as pigs NOT in a bacon factory!!
I'd always truncate the data --> this will avoid the possibility of exploits through buffer overruns, and your user experience would be crap anyway if they had to wait for 1Mb text to be transmitted AND RENDERED in a txt area!!
Thee is nothing wrong with giving people limits .... and if this as going to be a dynamic label that you were displaying on the screen, if they couldn't describe "it" in 500 chars or less, there is something wrong with "it"
Just my AUD 0.02
Ross Ferris
Stamina Software
Visage > Better by Design!
>> For more options, visit this group at
>http://groups.google.com/group/CacheMV?hl=en
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "InterSystems: MV Community" group.
>> To post to this group, send email to Cac...@googlegroups.com
>> To unsubscribe from this group, send email to CacheMV-
>> For more options, visit this group at
>http://groups.google.com/group/CacheMV?hl=en
>
>
>
>--
>Dawn M. Wolthuis
>
>Take and give some delight today
>
>--
>You received this message because you are subscribed to the Google
>Groups "InterSystems: MV Community" group.
>To post to this group, send email to Cac...@googlegroups.com
>To unsubscribe from this group, send email to CacheMV-