[RESOLVED] What is the benefit of fixed-length string (as string * 14)?

[MMock]

I am working on an issue with our live vb6 application.

A field used to be of the format nn/nn/nn. So the variable to store it was "as string * 8".

Then our data changed and could possibly be nnn/nnn/nnn so truncation is occurring. Perhaps the easiest thing to do is change the code to "as string * 11". But am I just postponing the same problem from occurring again later, when the data become nnnn/nnnn/nnnn? (A change was made to increase the length almost five years ago, and here we are again...)

So what is the difference between these - MyString As String * 10 vs MyString As String? And I guess more importantly, is it because MyString is a field in a user defined type that you have to declare the length explicitly? That is,

Private Type MyType
    MyStringOne As String * 8
    MyStringTwo As String * 3   
    MyStringThree As String * 5
End Type

Private udtMyType As MyType

[The Welshman]

I have come across two reasons for using fixed length strings.
Firstly, when a variable is declared as fixed length, then it only needs that much memory reserved for it. This is not really an issue now, it was something that needed to be considered when memory was smaller.
Second, is it prevents transfer errors if you are passing it into a size limited field in a database (which again is a memory saving tool).

If you check any database fields you are using that refer to it, then I doubt you'll have any problems moving to an unlimitted string.

However, there may me another reason I a unaware of.

[MMock]

Right - I was going to check on the database end, too, to see if the truncation might be occurring there as well. Thanks.

varchar(100) - no problem there!

[techgnome]

Nearly all of the times I've ever seen a fixed-length string in VB was due to file readings... where the fields in the file are at fixed points (as opposed to being character delimited by a comma, tab or what ever)...

-tg

[MMock]

Right, tg, which is not the case here.

I did ask the original programmer (because how often are you lucky enough to have the original programmer still around?!) just in case there is a reason - I know I don't really like to be second-guessed, so I'll let you know what we decide.

[MMock]

We decided to have them stay fixed. This is old code (obviously...it's VB6) which will be rewritten so a quick band-aid is good enough. However, I shouldn't say "we decided". He decided, and sometimes I feel like I need to keep my mouth shut and not challenge everything.

[MMock]

I am going to post a related thread in the Database Development forum. Because what was happening when this code was live, is a value such as 12345/12345/12 was getting saved to the database when really what the user had entered was 12345/12345/12345. So now I want to run a query that will find my truncated data. But, the column in the database is one humungous string which is the concatenation of a bunch of user input fields including this one. So I have to find strings that contain a substring like:

aaaaaaaaaaa: 200/400/600bbb; 60/40bbbb; 12000/24000/36bbb; 1000/2000/3000ccccccc

because

12000/24000/36bbb

got truncated. Get it?

[MMock]

No new thread was necessary. There weren't a lot of data with the issue, so I ran individual queries and eyeballed the results. Thanks for your help with this. Turned out to be fun - fixing bad data and changing code so bad data don't happen anymore is very rewarding!