Kinook Software Forum

Go Back   Kinook Software Forum > Ultra Recall > [UR] General Discussion

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 11-16-2007, 02:21 AM
grahamrhind grahamrhind is online now
Registered User
 
Join Date: 03-11-2007
Location: Amsterdam, NL
Posts: 37
Leading zero removed from string field

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
Reply With Quote
  #2  
Old 11-16-2007, 03:20 AM
quant's Avatar
quant quant is online now
Registered User
 
Join Date: 11-30-2006
Posts: 967
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.
Reply With Quote
  #3  
Old 11-16-2007, 10:24 AM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
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.
Reply With Quote
  #4  
Old 11-16-2007, 10:26 AM
grahamrhind grahamrhind is online now
Registered User
 
Join Date: 03-11-2007
Location: Amsterdam, NL
Posts: 37
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.
Reply With Quote
  #5  
Old 11-16-2007, 01:16 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,003
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.
Reply With Quote
  #6  
Old 11-16-2007, 01:44 PM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
Quote:
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.
Reply With Quote
  #7  
Old 11-16-2007, 02:05 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,003
Quote:
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)?
Reply With Quote
  #8  
Old 11-16-2007, 02:59 PM
grahamrhind grahamrhind is online now
Registered User
 
Join Date: 03-11-2007
Location: Amsterdam, NL
Posts: 37
Quote:
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.
Reply With Quote
  #9  
Old 11-16-2007, 03:13 PM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
Quote:
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)).


Last edited by ashwken; 11-19-2007 at 01:22 AM.
Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 04:30 PM.


Copyright © 1999-2023 Kinook Software, Inc.