Truncating string values on Save


Author
Message
Peter Jones
Peter Jones
Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)
Group: Forum Members
Posts: 386, Visits: 2.1K
Hi,



We had a curious issue today. A form exceptioned because column length value (by mistake) in the database was too short - just 20 characters when it should have been 100.



The database was corrected but in testing I noted that when I entered 40 characters what is saved to the database is 22 characters. If enter 40 characters in EM then no problems so it is something in the form. So, I assume the truncation must be happening in the BO and what I didn't do is remap and compile the BO after I changed the column length.



So, a few questions:



1) Does SF trim form data to the maximum a column can accept during the Save operation.



2) If 1 is true then after changing column lengths does the associated BO need to be recompiled.



3) If 2) is true then it would appear there may be a bug in the SF code in that a nvarChar(20) column is being saved with 22 characters not the 20 as was originally mapped.



BTW we use DevExpress but I can't see how that would effect things.



Cheers, Peter
Replies
Peter Jones
Peter Jones
Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)Advanced StrataFrame User (718 reputation)
Group: Forum Members
Posts: 386, Visits: 2.1K
Hi Trent,



Thanks for the response. It's good to hear that SF does truncate but the unicode side of things is unclear. We are using unicode characters but SF certainly seems to truncate to a value higher than that defined in the BOM, i.e. in the case in question the original database column was nvarChar(20) which was changed to nvarChar(100) and, without a BOM rebuild, SF was truncating whatever value was entered to 22 characters. Also, keep in mind we went down this path because a user reported an exception when he entered a value greater than 20 characters.



Cheers, Peter
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
Well, this value that I am talking about is actually seamless to you.  If you enter 20 in the DDT then it will be 20 when truncated on the INSERT/UPDATE.  If you turn on debug mode, however, you will see these extra characters.  That was what I was referring to.  So let's backup then.  Can you give me a sample with the following so I can see what you are referring to otherwise I feel that we may go round-and-round out here on the forum?

  1. A backup or MDF of the sample database.
  2. A very simple sample showing just this once piece that is breaking on you.

Thanks.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search