This question already has answers here:
How can you use an object's property in a double-quoted string?
(5 answers)
Closed 4 years ago.
I am importing a .csv into a variable $user. I can then access each field using $user.ARN (for example). This works fine.
But then I need to build a string using this variable.
$SQLQuery = "USE Cardpresso INSERT INTO dbo.students (Name, ARN, CardNumber, isPrinted) VALUES('$DisplayName', $User.ARN , $CardNumber, 0);"
When I check what is inside the $SQLQuery variable, it holds the whole csv row inplace of $User.ARN.
USE Cardpresso INSERT INTO dbo.students (Name, ARN, CardNumber, isPrinted) VALUES('%%% %%%', #{FirstName=%%%; LastName=%%%; ARN=%%%; Group=%%%; Email=unknown#unknow.com; Pass=%%%; Site=%%%; CardNumber=}.ARN , 508, 0);
(The %%% are real data, just removed)
Why is the $User.ARN not just been replaced with the data from just that field, instead it is inputting the whole row?
Thanks
For a file "sample.csv" with contents:
name,age,gender
billy,22,M
suzie,26,F
mikey,19,M
Tez,22,F
I'm importing the CSV, and I'm crafting insert statements from each record:
$stuff = Import-Csv -Delimiter ',' -Path .\sample.csv
foreach ($thing in $stuff) {
echo "INSERT INTO Cardpresso.dbo.students (Name, Age, Gender) VALUES ('$(${thing}.name), $(${thing}.age), '$(${thing}.gender)');"
}
Live example...
Good luck.
Related
I am loading a DataTable with data from SQL Server as such:
$queryStr = "SELECT TOP 10 ID, QueryText FROM dbo.DatabaseName";
$dataRows = Invoke-DbaQuery -SqlInstance instance.name -Database databasename -Query $queryStr -As DataSet;
In SQL Server the QueryText is nvarchar(max). In PowerShell, this becomes a string datatype, equal to varchar I think. I think this because when I try to calculate the hash in PowerShell with Get-FileHash, and in SQL Server I calculate the hash on the nvarchar column with SELECT (CONVERT([varchar](70),hashbytes('SHA2_256', QueryText),(1))), the hashes do not match.
They DO match however, if I convert the nvarchar to a varchar(max) in SQL Server.
So the question is, in PowerShell how can I convert the string datatype to match the nvarchar datatype in SQL Server? Because as far as I know, PowerShell does not have a nvarchar datatype, just the generic string datatype.
Added this part after reading comments.
In the DataTable that I retrieve from SQL Server as per the above code I add an extra column to hold the hash that I calculate in PowerShell.
Add extra column to DataTable:
$HashColumn = [System.Data.DataColumn]::new('QueryHashString', [string]);
$dataRows.Tables[0].Columns.Add($HashColumn);
Now I do a foreach to fill this column I just added:
foreach($row in $dataRows.Tables[0]) {
$stringAsStream = [System.IO.MemoryStream]::new()
$writer = [System.IO.StreamWriter]::new($stringAsStream)
$writer.write("$($row.QueryText)")
$writer.Flush()
$stringAsStream.Position = 0
$row.QueryHashString = (Get-FileHash -InputStream $stringAsStream | Select-Object -ExpandProperty Hash)
}
Your code uses StreamWriter that uses the default UTF-8 encoding, which matches what you get with hashing a VARCHAR -- if you stick to ASCII characters. To hash Unicode instead (and for variation, let's use SHA256 directly instead of going through Get-FileHash, and throw in an emoji so we have to deal with surrogates):
$s = "Hello, world! I 💖 you"
$sha256 = [System.Security.Cryptography.SHA256]::Create()
[BitConverter]::ToString(
$sha256.ComputeHash([System.Text.Encoding]::Unicode.GetBytes($s))
).Replace("-", "")
This yields the same result as
SELECT CONVERT(CHAR(64), HASHBYTES('SHA2_256', N'Hello, world! I 💖 you'), 2)
I'm learning PowerShell scripting & want to extract tableName from SQL Query String. For example, I've this query -
$q = "SELECT * FROM [TestDB].[dbo].Invoice_Details where Clientname='ABC'"
where I want to extract table name i.e. it should output this - Invoice_Details
Currently, I'm doing this with following working code -
$q1 = $q -split '\[dbo\]\.'
$q2 = $q1[1] -split ' where '
write-host $q2[0] #here I get it right (Invoice_Details)
But, sometimes the query may/ may not have bracketed names like - [TestDB].[dbo].
So, I want to optimize this code so that it will work even if query containing any combination of bracketed/ bracketless tableNames
Try something like this:
$res = ([regex]'(?is)\b(?:from|into|update)\s+(\[?.+\]?\.)?\[?(\[?\w+)\]?').Matches($q)
write-host $res[0].Groups[2].Value
I am able to replace a single string in a SQL file using PowerShell as follows:
$newPrefix = "foo'
$dbUserMappingScriptPath = "C:\MySQL_Template.sql"
$updatedDbUserMapingScriptPath = "C:\MySQL.sql"
(gc $dbUserMappingScriptPath).Replace('DBPrefix_',$newPrefix) | sc $updatedDbUserMapingScriptPath
This is great for single scenarios, but I need to replace multiple strings. I have tried the following, but it doesn't perform the replace operation beyond replacing the first string of 'DBPrefix_' with $newPrefix. It does not perform the replacements for 'MDFDatabasePath' and 'LDFDatabasePath'.
How do I replace multiple strings given the following snippet? Note that this is wrapped in a Foreach-Object for the $.MDFDatabasePath and $.LDFDatabasePath values.
$dbUserMappingScriptPath = "C:\MySQL_Template.sql"
$updatedDbUserMapingScriptPath = "C:\MySQL.sql"
(gc $dbUserMappingScriptPath).Replace('DBPrefix_',$newPrefix).Replace('MDFDatabasePath',$_.MDFDatabasePath).Replace('LDFDatabasePath',$_.LDFDatabasePath) | sc $updatedDbUserMapingScriptPath
Here is a snippet of my SQL:
USE [master]
GO
CREATE DATABASE [DBPrefix_mydb] ON
( FILENAME = N'MDFDatabasePath\DBPrefix_mydb.MDF' ),
( FILENAME = N'LDFDatabasePath\DBPrefix_mydb.ldf' )
FOR ATTACH
GO
UPDATE: I had a mismatch in my PowerShell script in that I was running the replace on the wrong SQL script. The code above with an extra .Replace works like a charm
Long story short, I have an admin section where the user can choose from multiple dropdown lists the tables and fields that must be queries in order to get some values. Therefore, the query in ZEND is performed by concatenating the strings
$query = "SELECT $fieldName1, $fieldName2 from $tableName where $fieldName1 = $value";
How can I escape the above using ZEND approach to avoid sql injection? I tried adding them all as ? and calling quoteinto but it seems this does not work on some of the variables (like table names or field names)
ZF has quoteIdentifier() specifically for this purpose:
$query = "SELECT ".$db->quoteIdentifier($fieldName1).","...
In your case you might (also) want to check against a white list of valid column names.
Use quoteInto() or Zend_db_Select::where() for the values, and for the table and column names, I would simply strip any non alpha characters and then wrap them in ` quotes prior to using them in your SQL.
Example:
// Strip non alpha and quote
$fieldName1 = '`' . preg_replace('/[^A-Za-z]/', '', $fieldName1) . '`';
$tableName = '`' . preg_replace('/[^A-Za-z]/', '', $tableName) . '`';
// ....
// Build the SQL using Zend Db Select
$db->select()->from($tableName, array($fieldName1, $fieldName2))
->where($fieldName1 . ' = ?', $value);
In SafeMysql you can make it as simple, as
$sql = "SELECT ?n, ?n from ?n where ?n = ?s";
$data = $db->getAll($sql,$fieldName1,$fieldName2, $tableName, $fieldName1, $value);
though I understand that you won't change your ZF to SafeMysql.
Nevertheless, there is one essential thing that is ought to be done manually:
I doubt you want to let users to browse users table or financial table or whatever.
So, you have to verify a passed table name against an allowed tables array.
like
$allowed = ('test1','test2');
if (!in_array($tableName, $allowed)) {
throw new _403();
}
I am writing a Perl script that is using the DBI module and is connecting to a Sybase DB. I am calling a stored procedure (one that I don't have access to so I cannot post sample code) and when I get data back I get an error that reads "error_handler: Data-conversion resulted in overflow". I still get data back and after doing some intensive research it seems that some data types in the columns (such as BigInt, nvarchar, etc) are the culprits. Now the question is, how can I fix this? Can this be fixed on the client side or can it only be fixed on the server side?
my $dbh = DBI->connect("DBI:Sybase:server=$server", $username, $password, {PrintError => 0}) or die;
$dbh->do("use $database") or die;
my $sql = &getQuery;
my $sth = $dbh->prepare($sql) or die;
$sth->execute() or die;
while ($rowRef = $sth->fetchrow_arrayref) #Error seems to occur here
{
#Parse through each row
}
Part of the FreeTDS 0.82 log that explains the problem:
_ct_bind_data(): column 7 is type 38 and has length 8
_ct_get_server_type(0)
_ct_get_client_type(type 38, user 0, size 8)
cs_convert(0x18dfed40, 0x7fff73216050, 0x18e44250, 0x7fff73215fa0, 0x18e387c0, 0x18e45a64)
_ct_get_server_type(30)
_ct_get_server_type(0)
converting type 127 (8 bytes) to type = 47 (9 bytes)
cs_convert() calling tds_convert
cs_convert() tds_convert returned 10
cs_prretcode(0)
cs_convert() returning CS_FAIL
cs_convert-result = 1
The problem is on the FreeTDS side. I've had the same problem before and successfully fixed it by converting the returned fields to varchar in the select statement.
Given you don't have access to modify the original query, you can do some regex search and replace on the returned $sql variable in your code. In particular, if the original query has a part that looks like
SELECT field1, field2, field3 FROM ...
After you retrieve the query statement, you may run
my $new_sql;
if ($sql =~ /SELECT\s+(.*)\s+FROM/i) { # match selected field string
my $field_str = $1;
my #fields = split ",", $field_str; # parse individual fields
map s/\s//g, #fields; # get rid of spaces
my $new_str = join ", ", (map {sprintf "convert(varchar, $_)"} #fields); # construct new query string
my $quoted_field_str = quotemeta($field_str); # prepare regex replacement string
$new_sql = $sql;
$new_sql =~ s/$quoted_field_str/$new_str/i # actual replacement
}
print $new_sql;
Of course, if your original statement is more complex, you should print it out and check how to modify it with a generic replacement bearing the same spirit. Alternatively, you can ask your DBA (or whoever has access to the stored procedure) to modify the actual query directly.
Hope this helps.