Leading zero removed from string field

[grahamrhind]

In URp 3.2.6 I have created a new string attribute to contain serial numbers, and then added that to a form. When I add data which contains a leading 0 (zero) the data is accepted without problem or change. However, the next time I check that record the leading zero is always parsed off.

Again this is a string attribute, not a numeric one. Is this a bug or am I missing a switch somewhere?

Thanks

[quant]

My UR doesn't exhibit the behaviour described ...

From help:

Note: The String, Number and Money Attribute Types allow direct entry of the value, without a specialized value editor. For these Attribute Types, you are allowed to enter data that does not match the type (a good example is entering 56 bps for a Number Attribute Type value). For Attributes using the Number and Money Attribute Types, Ultra Recall will use the leading numeric part of the value for search and sorting purposes.

[ashwken]

Running v.3.2.6.2

For a custom Form that contains an Attribute of the Type String - zipcode.

If I enter a zipcode with a leading zero and either move focus off the Form, or do an F5 before moving focus, the leading zero is stripped.

If, after doing the F5, I re-enter the zipcode the leading zero is retained.

If I do an explicit Save before moving focus off the Form the leading zero is not stripped, but upon return to the Form it is stripped. Re-entery of the data retians the desired info.

[grahamrhind]

Thanks for confirming this.

I had noticed also that if I edit the form after the 0 has been stripped to re-add it, it is retained.

[kinook]

This behavior only occurs if the attribute did not already exist for an item, so you can avoid it by adding the attribute (with a blank value) to the item template.

[ashwken]

Originally posted by kinook
This behavior only occurs if the attribute did not already exist for an item, so you can avoid it by adding the attribute (with a blank value) to the item template.

Boy, do you have me confused.

When I was testing the behavior I was using a new Item (derived from a Template) that had a Form assigned, the Form had a number of Attributes where the Attribute Type is String.

Now, one thing I have noticed is that if I start from a new Item (with Form assigned) and expose the Attribute Pane (Ctrl-4), and make the data entry in the Attribute Pane the data is preserved as entered - w/o having to do anything else.

Seems to point to the way that data is being read from the Form and written to the database.

[kinook]

Originally posted by ashwken
When I was testing the behavior I was using a new Item (derived from a Template) that had a Form assigned, the Form had a number of Attributes where the Attribute Type is String.

Did you also add these attributes to the Item Attributes pane for your custom template item (the item in which you assigned the Form attribute for your custom form)?

[grahamrhind]

Originally posted by kinook
This behavior only occurs if the attribute did not already exist for an item, so you can avoid it by adding the attribute (with a blank value) to the item template.

I don't understand this or any of the comments from Kinook which follow, I'm afraid. Can we take it as read that this is not what should be happening and that it will be corrected?

Thanks.

[ashwken]

Originally posted by kinook
Did you also add these attributes to the Item Attributes pane for your custom template item (the item in which you assigned the Form attribute for your custom form)?

Oh, OK, this does reslove the issue, but it brings up the question of why I should need to.

This behavior is only affecting text strings that begin with zero(s), no other beginning character is stripped and any Atrribute that is not envisioned to have a leading zero(s) does not need to be added to the Item's Template Attribute Pane.

Update
Never sure whether to bump or update...

It would appear that when UR reads inital data from a Form's field, it writes the data under the conditions noted in the second post by quant. Under these conditions a text String value that contains leading zeros is seen as a Number, and the leading zeros are stripped.

Re-entry of the data forces UR to read the data based on the Attribute Type setting (String (text)), thereby accepting the leading zeros.

The work-around suggested by Kinook:

goto the Template that contains the Form with the Attributes that will contain leading zeros (US Zipcode, Int'l dialing, part numbers...), expose the Attribute Pane (Ctrl-4), Insert (add) the Attributes that will contain leading zeros, close the Attribute Pane.

It would appear that this forces UR to read the initial data (from the Form) based on the Attribute Type setting (String (text)).