String concatenation.
If a programming language supports strings, it's going to support concatenating them. The means of doing so are usually straightforward and often times involve a simple library call or even a one character operator such as "+" or "&."
Internal string representation typically follows one of two paradigms: either the string uses a unique terminator to signal the end of the string, or it includes within the type itself the length of the number of characters in the string. C is probably the best known language that follows the first paradigm and terminates its strings with the null character. Higher level languages with inherent string types, such as VisualBasic or C#, follow the second paradigm, though the actual implementation is typically unique to each language.
As a result, strings implemented in one language don't usually work with strings implemented from another language. So, for the times that one needs to move a string between different assemblies with unique string implementations, there are typically conversion methods. C++, for instance, supports both C-style strings and the Standard Template Library (STL) "string" type. Included in the STL is a method for converting the STL string to a C-style string.
Most of the time in a language that supports strings, the details of how that string is represented at the low level don't matter. The compiler takes care of all of that for you. You take "Foo" combine it with "Bar" and get "FooBar" and go on your merry way. But that assumes you hold the truth to be self-evident that all strings created in the same development environment are created equal. A not unreasonable assumption, but one that if always relied on can result in things being truly FooBar'ed.
Take strings stored in Siemens HMI Smart Tags, for example. These are represented internally the same way C-strings are--including the null terminator. When you access a string in a Smart Tag, that null terminator goes along with it. This can cause an issue if you are running a VBScript behind the scenes that will access that SmartTag. As mentioned above, Smart Tags and VBScript don't follow the same paradigm. The null that the Smart Tag treats as the terminator of that string is just another character in the string in VBScript's eyes. If we concatenate that Smart Tag into another string, for example a Transact-SQL statement which we will be passing along to SQL Server, we will have injected that null character into the middle of our statement. If we're lucky, our null has been injected at a point that renders the statement unparseable by the T-SQL interpreter and the error is readily apparent. If not, our SQL query executes in an unexpected way and results in a side-effect that is difficult to track down.
So what can we do to fix this problem? First copy the Smart Tag string in its own VBScript string. Then call the Left() function on that string and extract everything but the null terminator. The string is now safe to concatenate into the Transact-SQL statement, or any statement for that matter. And our wayward null character is relegated to the bit-bucket, where it should have ended up in the first place.
VBScript strings and Smart Tag strings may not like each other, but if they're going to live in the same environment, at least we've found a way for them to get along.
Learn more about DMC's HMI and SCADA system services.