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

Good morning, Peter,



I have had experience with strings being too long and the save operation failed because of it. The data server will not truncate automatically and I know SF does not do this.



If you do change the length of the column, then a visit to the BOM is in order. Definitely recompile.



It is quite odd that an nvarchar data type with a max length of 20 would allow a set of characters with a length of 22.



Hope you get this one figured out!

Bill

Hi Guys,



I ran the BO Mapper and all ok now, i.e. I can save strings over 20 (22? Characters). I would just like clarrification though. If SF didn't do the truncating to 22 characters and all that is changed is a rebuild using the BOM then a recompile then what has changed? Sorry Bill but it seems to me the truncating (to 22 characters - not 20 as it should have been) was done within SF - what do you (or the SF team) think?



Cheers, Peter

Bump...



I was hoping a SF guru could through some light on why the 22 character truncation and why a BOM rebuild fixed the problem.



Cheers, Peter

Well I am not a SF guru, but I would say that what you have seen has to do with the functionality of SF to adjust the max length for character fields (see the TextBox.AutoAdjustMaxLenght propery help).



The fact that by rebuilding the BO fixed the problem for you, it does reflect the behavior of having this property set to True.

Edhy Rijo

Hi Edhy,



I didn't know about that property but, in my case, I'm using a DevExpress grid and I can't see that the grid would be doing anything - ith is just shuffling data to/from the bo.



BTW - this isn't an issue for me I would just like to understand where the original (wrong) truncation was being performed.



Cheers, Peter

Hi Edhy,



I didn't know about that property but, in my case, I'm using a DevExpress grid and I can't see that the grid would be doing anything - ith is just shuffling data to/from the bo.



BTW - this isn't an issue for me I would just like to understand where the original (wrong) truncation was being performed.



Cheers, Peter

When you map a BO, the length of the field is actually stored off an used when building the UPDATE commands. So when you change the length of a field, it is best to rebuild the partial class to make sure that the field lengths are updated.







Yes. Just rebuild the partial class and you are good to go.







Actually, no. This could be a really long explanation, but this has to do with UNICODE values. I would have to go look up in our issues history and log, but several years ago, we had an issue with data being truncated, the reason was the parm value of unicode data. I would have to go and dig it out and get my head back into it to recall exactly what the issue was, but I remember fixing this on the data source.

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

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.