Team Developer 7.5.x cumulative patch info (ONEOFF)

[Dave Rabelink]

Official updates for Team Developer are released every few months.
Between these updates, reported defects are addressed through cumulative patches, also referred to as ONEOFF releases.

The primary difference between official updates and cumulative patches lies in their distribution.
Unlike official updates, cumulative patches do not include a complete installation package. Instead, they consist of individual files that must be manually copied to the Team Developer installation or runtime folder.

It can be challenging for Team Developer users to identify when patches are released, understand their contents, and locate the appropriate download links.

This thread is dedicated to reporting newly released cumulative patches for Team Developer 7.5.x (RTM).
It provides direct links to relevant knowledge base articles on the OpenText website, as well as direct downloads of the associated readme files.
Additionally, this space serves as a platform to report issues with these patches, enabling us to track the latest updates and their status within the forum.

[Dave Rabelink]

Team Developer 7.5.2 cumulative patch:

KB Article KB0814471 (ONEOFF752.21b, 15.07.2024)
KB0814471 (latest patch)

README_ONEOFF752.21b.TXT

[Dave Rabelink]

Issues found on SalStrRightX, initial discussion here:

viewtopic.php?f=26&t=76529

[Dave Rabelink]

By the way, the next official update for TD 7.5 will be:
(current latest update is TD 7.5.2)

TD 7.5.3
Expected release September 2024

[Dave Rabelink]

Team Developer 7.5.2 cumulative patch:

KB Article KB0814471 (ONEOFF752.21c, 16.07.2024)
KB0814471 (latest patch)

README_ONEOFF752.21c.TXT

[RainerE]

It's interesting, this patch does not contain the faulty SalStrRightX fix any more.
Maybe SalStrRightX now works as before?

[Peter.Hugk]

Yes, with 21c SalStrRightX now works correctly again.
We will do more tests in the next days and post results if necessary.

Best regards,
Peter

[Peter.Hugk]

Regression using SqlPrepare + SqlExecute in .NET
There is OneOff 752.22 available for this.

[Peter.Hugk]

Important change by OneOff 752.21

The behaviour of SalStrLeft, SalStrMid, SalStrRight and SalStrScan changed in 752.21.
Opentext explained:

SalStr functions did not handle Unicode combining characters but this ONEOFF modified SalStr functions to handle them as one character. For example, attached sample application uses Thai string containing 3 combining characters like as follows.
ล์ \u0E25\u0E4C
พื่ \u0E1E\u0E37\u0E48
ดั \u0E14\u0E31
If SalStr functions does not handle these characters as single character, SalStr function could pick one of these combining characters and show unexpected character.

Therefore you need to use SalStrCharLength instead of SalStrLength in combination with the above functions from now on.
SalStrLength needs to be used in regard of buffer size or database field length. It counts in the same way like the SQL function @LENGTH does.

Kind regards,
Peter

[Dave Rabelink]

What is the download link to the new oneoff?
The existing KB article still has the old (previous) version.

[Peter.Hugk]

Sorry, but I got OneOff 752.22 as a direct download link in my support case:
https://support.opentext.com/sys_attach ... 900153af9e
Don't know, if this link still is valid.

Best regards,
Peter

[Peter.Hugk]

Important change by OneOff 752.21

The behaviour of SalStrLeft, SalStrMid, SalStrRight and SalStrScan changed in 752.21.
Opentext explained:

SalStr functions did not handle Unicode combining characters but this ONEOFF modified SalStr functions to handle them as one character. For example, attached sample application uses Thai string containing 3 combining characters like as follows.
ล์ \u0E25\u0E4C
พื่ \u0E1E\u0E37\u0E48
ดั \u0E14\u0E31
If SalStr functions does not handle these characters as single character, SalStr function could pick one of these combining characters and show unexpected character.

Therefore you need to use SalStrCharLength instead of SalStrLength in combination with the above functions from now on.
SalStrLength needs to be used in regard of buffer size or database field length. It counts in the same way like the SQL function @LENGTH does.

I got a question from opentext which I would like to share with the community. We have the opportunity to suggest the best way to handle above problem.

2.After discussing with the engineering team below is the update:

We already provided this ONEOFF [752.21c] to several customers and one of them expect to have this change. So, it's too late to back out this changes from ONEOFF. But we might implement some workaround for this issue if you can share the confirmation.
Are you expecting the Salstr functions(SalStrLeft, SalStrRight, SalStrScan and SalStrLength) should work as 7.3?

(Or)

Your request is to change the behavior of SalStrLength to be the same as SalStrCharLength, probably it's better to add one global variable to change its behavior for 7.5.2 ONEOFF.
We are not sure what's the best.
Probably we should change SalStrLength to be the same behavior with the SalStrCharLength, and add another function such as SalStrUniLength which is the same behavior with current SalStrLength. Because SalStrLength is used with string manipulation functions such as SalStrLeft/SalStrMid/SalStrRight in many cases.

Please let us know your view.

I discussed this with colleagues and we would prefer the last solution. That would leave 95 % of our sources working. The other 5 % are dealing with buffer size, file size or database field size und would need to be changed to the new function.

Please let me hear your comments.

Best regards,
Peter

[thomas.uttendorfer]

Hi Peter,
I would also prefer the last solution

Probably we should change SalStrLength to be the same behavior with the SalStrCharLength, and add another function such as SalStrUniLength which is the same behavior with current SalStrLength.

When we handle buffers we usually use

Code: Select all

SalGetBufferLength(..)

Regards Thomas

[RainerE]

We do not have that special UNICODE characters in our application.
But we use several external Dlls and have modified the from the A to the W functions (while migrating from TD 4.2 to TD 7.4).
For us the most important thing would be, that we do not need to change our application, which is large and has been implemented in the last 30 years.
Currently we are on TD 7.4.6 ONEOFF 12.

Rainer

[Peter.Hugk]

Rainer,
"not need to change our application" that would be nice and I would pefer that too.

But unfortunately the SalStr functions had to be changed since they could cut diacritical characters into pieces since Unicode was introduced in TD.
With TD 7.5.2 ONEOFF 21c they now work on letters instead of Unicode characters. This won't change anything as long as you have languages like German, English, Greek, Chinese where every letter uses one Unicode character to be stored. Except in languages with diacritical characters (letters) SalStrLength will count the letters instead of the Unicode chanacters in future. To count the used Unicode characters there will be a new function SalStrUniLength. This function will be needed in all cases where you deal with database column lenght (@LENGTH also counts Unicode characters), file I/O operations or buffer sizes and work with diacritical characters.
Since there was no option to go back to the old behaviour of the SalStr functions this was the smallest footprint. One death we have to die.

Here is a blog which explains the different ways to count the characters in a string:
https://www.meziantou.net/how-to-correc ... string.htm

Best regards,
Peter