4 of 4 people found this helpful
Regarding the three fields highlighted where the column size is 4x the metadata definition - this is due to the field property "Length Units". In these cases it is changed from the default of BYTES to CHARACTERS. See section in Field Properties - Documentation for Remedy Action Request System 9.1 - BMC Documentation
Where it says....
In Regular forms, specifies whether the Input Length of a character field is calculated in Bytes or Characters. The default is Bytes, which is the Input Length unit for all character fields in BMC Remedy AR System server release 7.1.00 and earlier. Because character sets use varying numbers of bytes to represent a single character, setting the Length Units property to Characters allows better control of character field sizes in the database. When creating or resizing a database column corresponding to a field with a Length Units value of Characters, BMC Remedy AR System server applies a multiplier to calculate the column size for the field. The multiplier is determined by the server character set and the database code unit. The server uses the following multiplier values:
- 1 — WESTERN character set.
- 2 — UTF-8 with Microsoft SQL Server, GB2312, Big-5, EUC-CN, Shift-JIS, KSC-5601, and EUC-KR character sets.
- 3 — EUC-JP character set.
- 4 — UTF-8 (except Microsoft SQL Server), EUC-TW.
For example, when you create a character field with a Length Units value of Characters and an Input Length of 100 on a UTF-8 platform, the corresponding column is 200 nvarchar in a Microsoft SQL Server database (multiplier value of 2), or 400 char in other databases (multiplier value of 4).
Note: For the core fields Request ID, Submitter, Assigned To, and Last Modified By, you can only set Length Units to Bytes. The Short Description field can use either Bytes or Characters. For Bytes, it is limited to an Input Length of 255; for Characters it is limited to Input Length 63.
BMC Remedy Developer Studio does not display the Length Units property if the BMC Remedy AR System server is release 7.1.00 or earlier. To configure the default value of this property, in BMC Remedy Developer Studio, select Window > Preferences > Form, and set the Input Length Units value. In Display Only and Vendor forms, this property works with the Data Length field to restrict the length of the information to display. In Join forms and View forms, this property reflects the setting for the mapped field in the underlying form or database table.
and to follow on (for bonus points?), you can identify these fields by the value of the LENGTHUNITS column in the field_char table - 0 for bytes (metadata/column match - but see below) and 1 for characters.
There are circumstances where the metadata length and database column size may be different as a result of resizing the field - see Table updates when changing character field lengths - Documentation for Remedy Action Request System 9.1 - BMC Documenta…
OK, thanks for the inside view. I'll take a look at everything tomorrow.
Do you have any idea how I can figure out the real, bad differences? The cause and the BMC workaround is in the KA, but all the updates before 19.08 that left faulty traces.
What does a checkdb say? If it's not highlighted by this report it's most likely benign. Hmm, actually many of the discrepancies thrown up by the check are also harmless so it may not help too much. Can you provide some examples of fields where this is a problem? It shouldn't be an issue for cases where the column is greater than the metadata size, only the opposite, which would lead to a SQL error when trying to insert more data than would fit. The installers should only be making changes which would lead to the former (part of the zero down time upgrade support) in current releases.
Being able to use UTF-8 characters and have them displayed correctly even in those core fields is (hopefully) appreciated by those aware of it; it would be nice if strings of multi-byte characters were limited to database rather than metadata length, though -- it could increase storage efficiency by up to three times and perhaps limit impact of post-upgrade round-off errors. (I'd say that when dimensioning fields, one usually considers how much space is enough, not necessarily how much is too much, so defining something as being able to contain at least a certain number of elements (and up to as much as a quadruple of that amount) could sound reasonable.)
I'm probably being a bit stupid right now, but I can't start arserver.jar with the dbcheck option.
I follow the BMC Documentation for linux, then I see a hint "arserverport = null" and then a meaningless exception. We do not use a port mapper, but I can' t specify a port. Could this be the reason?
1 of 1 people found this helpful
you have to define the environment variable "ARSERVERPORT" if you are not using the port mapper.
I think that's normal for this use case - the port number reference is the one used when the server is started by ARMonitor and allows the server to report its status back to the parent. Can you provide the command line you're using and output?
2 of 2 people found this helpful
Hi Uwe Ryczek,
Thanks for the tip, now he seems to be taking the port. Unfortunately there is still a java.lang.NullPointerException after that: null. The statement is not very helpful and there are no more logs, also no start trace file. So it must happen very early.
HI Mark Walters,
gladly > java -jar ./arserver.jar --unicode -checkdb "/opt/bmc/dbceck.log" -s "arsserver" -i "/opt/bmc/ARSystem" -l "/etc/arsytem/arsserver"
There is a bug in version 20.02 for dbcheck... at least on windows.
Try this with linux equivalent
1. Open cmd as "run as administrator"
2. Go AR Install DIR
3. Run below command and let us know the result and check if checkdb logs are generating or not in Db folder.
4. ardbutils.bat -dbCheckOnly
Unfortunately same result I will check the linked Information at Monday