As usual, continued to consider this issue. Will need to look at how the variable is used downstream, what was it page_key?, but I'm thinking that it would be okay to truncate it by one character if the last character is \. See ZC is properly formatting the string to prevent a problem, but if remember correctly the field is set to a specific length upon construction of the table. I'm not sure why it is the length that it is, but, also thinking that it's okay to be as short as it is. I will have to assess that before making a change to the table length, but if there is no effect on the program by truncating that and other fields that could potentially have an escaped character, then the fix will be to check the last character in the string if it is \ then delete it. So, generally speaking there is no reason for you to modify the content as you have described, this plug-in should be modified to support standard ZC functionality.
I do think that part of the reason that it is as "short" as it is, is because UT is collecting additional data and storing it without using reference to the rest of the database as the goal is to report exactly what was attempted instead of what the ZC database contains. So, this increases the amount of information in the database and increasing the field length may gain little in functionality/information, but will increase database size.



Reply With Quote
