TD-4048: Remove distinction String - Long String

[johi]

If a column longer than 254 chars is fetched into a normal String,

String is empty. If a column shorter than 254 chars is fetched into a Long String, an error message is triggered. Or was it the other way round?

Anyway, this is annoying and I do not understand why this distinction still exists in the new version.

[Mike Vandine]

There is a distinction because they are two entirely different data types.

1. A string can hold up to 254 bytes of data.
2. A long string is used for data columns that are > 254 bytes.

This is a simple thing, but there is *definitely* a distinction. Long strings are used like BLOBs, Long Varchars, etc.

See the Developer's Guide.

[johi]

My post was an enhancement request, maybe shared by other developers, may be not.

I know about the current distinction, but I hoped with my colleagues that TD 5.1 would hide this internal distinction from the application level: Make it possible to use String for all character data without length restriction, allow Long String for compatibility.

What do you mean by "See the developers guide." ? No chance that Unify would ever think about my enhancement request?

[Mike Vandine]

I'm sorry if I've offended you.

Thanks for the clarification about what you really would like to see. This forum is 'Enhancement Requests', but there are multiple products that we support that can be enhanced.

Please know that NO enhancement request is EVER dismissed offhand. With the additional information you've provided, we will certainly create an enhancement request on our tracking database and will certainly consider a change.

Best regards,

[johi]

communication Austria - Australia around the globe is still fascinating to me.

[AndreasWagner]

There is no difference in Team Developer between string and long string. Only when we use string as into variable then there is that restriction.
So this enhancement request is just comprehensible.

[GB]

I fully support johi's enhancement request!!

[Mike Vandine]

I have created enhancement request TD-4048 for this improvement suggestion.

Thanks!

[markus.essmayr]

Hi Mike,

I also fully agree with this request, that the distinction between these two string types is often confusing.
And especially if you change the datatypes of database columns, you may need to change your code too.
It would really be great if this distinction moves away some time.

Are there any news on this on your side?

Thanks!
Max

[tlauzi]

Yes, Yes, Yes , Yes, I support this too.

Often we got problems, when we made a column bigger and run over the border of 254 chars, we had to change the code and replace the into string with a into long string. Sometimes we forgot to change to long string ,and the application crashed then, because of the "wrong" datatype

Regards,
Thomas L.

[Dave Rabelink]

Yes, count me in for this enhancement request !

[Mike Vandine]

Look for this as a new feature in the TD5.2 release.

[Charlie]

Hello,

Before I add myself to the long string of folk (sorry, bad pun) who want this...

Could somebody explain why we ever needed both types of String to start with? Explain the design decision/reasons?

What are the trade-offs in making this enhancement? Sure, makes coding easier, but at what "cost"???

Thanks, much appreciated.

[Mike Vandine]

Currently the requirement is to bind fields above 254 bytes into long strings and fields below that number into standard strings. However, this is an artificial boundary and what really is a long string is not subject to an artificial boundary, but is a function of the data type, the database vendor and version, and the size of the column the user has declared. A long string may be as small as 255 bytes, or as large as 8,000 bytes, depending on the context.

So, the intent of this fix is to remove the 254-byte upper limit for the (non-long) String type, and allow users to bind strings to any column type or expression that is non-long.

The most important functional requirement of this change is that, while widening the size range that “short” strings will handle correctly, we do not change the current behavior of the product in other ways, especially if these changes will result in code changes for our customers. Read, 'backward compatible'!

So, there is no 'cost' to you of us making this improvement change.

[johi]

Hi Charlie, here are my thoughts about the reason for the original distinction.
In Windows 3.11, running on 16-bit CPU's, there was a huge performance advantage to keep data and local variables in one 64 KB segment. If you restrict string length to 254, you need to reserve only one byte in the string descriptor for the length.
So in 16-bit windows it made some sense to have a faster string data type for strings shorter than 254 characters.
The distinction could have been removed when SqlWindows was ported to 32-bit, maybe this was too complicated (modification of the SqlBase C-API and all underlying database routers) or nobody thought about it at Gupta/Centura.
Anyway, good news that the distinction will be removed in TD5.2!