How to capture data from a PowerShell script that runs as part of a SQL Agent Job?

Question

I have a PowerShell script called from an Agent job which opens an Excel file, converts it to .CSV and saves the .CSV file in a particular location, ready for me to import it with BULK INSERT.

What I need to do is count the number of rows in the file before loading it. Where the file is above a certain number of rows, I want to load the file to a different table. This is simple to do in PowerShell, I can get the count into a PowerShell variable no problems.

However, I have no idea how to read that variable into SQL so I can use it in my BULK INSERT process.

So my question is this: When running PowerShell from a SQL Agent Job, how do I read values from the output of that PowerShell script, either into a table, temp table or variable, I don't really mind which?

• Dan Guzman: Do you mean read the variable value in T-SQL? Typically, one would pass the value as a parameter for use in a T-SQL query or stored procedure. Consider adding relevant PS and T-SQL code to your question for clarity.
• Tony Hinkle: invoke-sqlcmd -ServerInstance DBSERVER -Query "UPDATE Sometable SET CsvRows = $NumRows"
• Geoff Griswald: Thanks Tony, will give that a try.
• alroc: Can you perform the bulk insert from PowerShell?
• Geoff Griswald: Probably, but I don't want to. I want to do it in a Stored Procedure.

Answer 1

Thanks to @Tony Hinkle for giving an answer as a comment. Here it is promoted to an actual answer, so hopefully the next person with this question finds it:

I created a table in my "Automation" database named "ImportRowCount" with one column named "RowCount" and inserted a single row in there with the number 0

Next, I added this line to my Powershell script:

invoke-sqlcmd -ServerInstance SQLServerHostName -Query "UPDATE Automation.dbo.ImportRowCount SET RowCount = $NumRows"

(Replace "SQLServerHostName" with your actual server's hostname)

So now my Powershell script updates that single row with the value of the $NumRows variable each time it runs.

This is perfect, since I can read the contents of that table before I run the remaining process, and I can use it as a decision point to branch my code into various different paths depending on how many rows are in the file.