'Passing a variable into SQL string
I'm modifying someone else's showershell script that's used within our database to try and have it do some extra steps behind the scenes: reject code, location code, and start date. It starts by asking for 3 values to pass as variables, but I want to add 2 additional values using a dictionary based on the location code. I don't want to share the entire batch - I know it works without this one specific part, but I'll include enough to illustrate my point.
The issue is with the variables $AREA1 and $AREA2 - these are what I'm trying to add. The "parameters" are being injected using one way where it asks for the user to supply them but i don't want the user to supply these, they're supposed to be a lookup. For instance, if the LOC was 5300 then AREA1 should be 101 and AREA 2 should be 111.
param(
[ImdsParameter(FullName = "REJ_CODE", Description = "Enter a 4 digit reject code to filter the data. Will not run without one.", Length = 4)]
[string] $REJ,
[ImdsParameter(FullName = "LOC", Description = "The Location code you want to run this against. Example 5300.", Length = 4)]
[string] $LOC,
[ImdsParameter(FullName = "STDTE", Description = "Start date. This is the start date from how back to run the report. Example 2021-01-01", Length = 10)]
[string] $STDTE
)
$areaStart = @{
5300 = 101 ;
5304 = 112 ;
5305 = 123 ;
5306 = 134 ;
//there’s well over 100 of these
}
$areaEnd = @{
5300 = 111 ;
5304 = 122 ;
5305 = 133 ;
5306 = 144 ;
//same
}
$AREA1 = $areaStart.Get_Item($LOC)
$AREA2 = $areaEnd.Get_Item($LOC)
$jobSql = @"
SELECT TB1.dataitem1,
TB1. Dataitem2,
TB1. Dataitem3,
TB2. Dataitem1
FROM firstTable AS TB1 INNER JOIN secondTable AS TB2
ON TB1. dataitem = TB2. dataitem
WHERE TB1.LOCATION = @LOC AND TB2.AREA BETWEEN '$($AREA1)' AND '$($AREA2)'
"@
$edbms = Get-Rdms -SQL $jobSql -Parameters @{LOC = $LOC; REJ = $REJ; STDTE = $STDTE; }
$edbms | ConvertTo-Csv -NoTypeInformation
EDIT: I need to add that the script will run, but returns no data. If I just plug the SQL in with all the values manually, it will run just fine.
Thank you for your time.
Solution 1:[1]
The values in the SQL were being treated as strings while the values in the dictionaries were being treated as numbers.
I changed this:
5300 = 101 ;
5304 = 112 ;
5305 = 123 ;
5306 = 134 ;
To this:
'5300' = '101' ;
'5304' = '112' ;
'5305' = '123' ;
'5306' = '134' ;
And it provided the data expected.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Ashley Kitsune |
