I recently discovered that when querying data views, case sensitivity in column names doesn’t make a difference; it consistently picks up the column when named correctly. Let’s explore where else column case sensitivity doesn’t play a significant role.
First let’s create a data extension with some columns so we can test following in Query studio, Automation Studio and in AMPScript.
We will attempt to execute the following query. As you can observe, I’ve referenced “FirstName” differently in the WHERE clause.
Select fIrStnAme,LaStName from mArCel_TeSts where FiRstnAmE = 'Marcel'
Column and even table names can be in random case, and the system still accurately retrieves the correct data.
I was initially skeptical about running the same query in the automation studio. However, when the query was successfully validated, I had no doubt that this case insensitivity is indeed functioning as expected.
Once we had provided the WHERE clause and all the required columns, the automation worked seamlessly and efficiently moved the data to another data extension.
AMPScript and SSJS
I had the most doubts about AMPScript and SSHS, but to my surprise, it works just as well as in other cases
%%[ SET @name = LOOKUP("marcel_tests","EmAiLADdresS","EmaIlAddResS","email@example.com") ]%% <pre> %%=v(@name)=%% </pre>
<script runat="server"> var name2 = Platform.Function.Lookup("maRcel_Tests","EmAiLAddreSs","EMaIlADDreSS","firstname.lastname@example.org"); Platform.Response.Write(name2); </script>