This is more then likley going to be an easy fix, but at the moment I can not think straight. What I am tring to do is restrict the size of a string. I am in the process of migrating some data from one sql system to another and need to truncate some text in the process.
I need to convert a text field to a varchar(7989), to do this I need to make sure that the data from the text filed is striped so that only the first 7989n characters are returned. I have a data reader that I am going through and am adding it to a genieric collection that I am then going to process and re insert into the new system... all I need is a way to restrict the text returned from the data reader... all the rest is fine.
Restrict the size of a string
*KGy*
I have done a small workaround for the moment where I did the truncating in the TSQL... CONVERT(VARCHAR(xxx), <TextField), this got me by for the moment and has allowed me to move on... But I will try the string builder method..
GRiNSER
How is my code any less efficient than yours Consider what each of us is trying.
Yours: Take a long string. Copy it all of it into a StringBuilder . Truncate it at the new end, create a new string from the StringBuilder (though you do forget to include that necessary last step)
Mine: Take a long string. Copy just enough of it into a StringBuilder . create a new string from the StringBuilder .
The only difference is that you copy more data and explicitly use a StringBuilder, while I use the StringBuilder that built into String.Substring(). (*)
(*) To be strictly accurate, String.Substring doesn't use StringBuilder, but it does make use of the same primates that StringBuilder does, so it's actually even more efficent.
I don't bring this up to hassle you, but to challenge "lazy coding" practices of relying on common wisdom (ie, "StringBuilders are always better than strings"), and get people to think closely about their code and what it's really doing.
ItsMe&#33;&#33;&#33;
Appending data beyond the maximum declared capacity of a StringBuilder results in an exception.
The good news is that the Length property is read/write for StringBuilders, and it will effectively truncate the string contents.
For instance you could just write:
StringBuilder s = new StringBuilder (someLongString);
s.Length = Math.Min (s.Length, 7989);
HTH
--mc
salfmlcd
not at all :-) I take this as a challange and one of those "learning" curves - not to start a flame war or anything like that - that is not what I like to do but to help improve other people :-)
From experience thats what I would use anyway, and from what I have been told/taught. I guess each one has their own advantage. The reason I said it was ineffecient is because when using a string builder - it only uses as much storage/mem/whatever as it needs instead of just "string" - which uses everything.
I guess - whatever works
kelly_c
won't the following work for you
string someLongString = "......."
string myString = someLongString.Substring(0, Math.Min(7989, someLongString.Length));
mshvw
one way would be to create a datatable, create the columns and set the maxlength for each column and fill that column with data, I would think that it would truncate the characters that exceed the specified length. But I think this would be ineffecient.
The other way would probably be to use a StringBuilder, in the constructor there is a suggested capacity to start with parameter and also along with it the maximum size. I'm unsure if it will truncate the characters but worth a shot
johnbury