none
Start a Job (Start-Job) from a PowerShell Runspace RRS feed

  • Question

  • I have a need to run an SQL query on a third party database (Actian Ingres) using a 32bit ODBC DSN. (32bit because the main user of the DSN is a 32bit application.

    This is working fine in testing from a 64bit powershell session using Start-Job and specifying -RunAs32.

    However, the parent script that will call this in production is actually running in a RunSpace (64bit) as a new thread started from a WPF form setup using Boe Prox's excellent techniques.

    It does not work and I wonder if I am asking the impossible - ie starting a process using Start-Job from a Runspace thread.

    Any ideas?

    Eric Whitchurch

    • Moved by Bill_Stewart Wednesday, May 30, 2018 6:42 PM This is not support forum for third party software
    Tuesday, March 27, 2018 4:39 AM

All replies

  • There is no necessity to run a 32 bit ODBC to attach to a database even if the DB is running as 32 bit.  "Bit-ness" only refers to the client.

    You will have to define what "does not work" means.

    Without more accurate and complete information there is no way to answer your question.

    If you did not write these scripts then I recommend contacting the author for assistance.


    \_(ツ)_/

    Tuesday, March 27, 2018 4:53 AM
  • Hi, The vendor software already installed at the customer site is only 32bit. It includes only a 32bit driver for ODBC. To install a 64bit driver will require an additional parallel installation of a full runtime just to get the driver and that is not a valid option for the vendor for whom I work.

    I have already tested the operation using 64bit PowerShell and can make the script work successfully as follows:

    Start-Job -FilePath $filePath -ArgumentList "$connString","$queryString" -RunAs32 -Name "GetJob" | Out-Null

    The script called is:

     [OutputType([System.Data.DataTable])] 
        [CmdletBinding()]
            param (
                [string]$connectionString,
                [string]$query
            )
            $connection = New-Object -TypeName System.Data.Odbc.odbcConnection
            $connection.ConnectionString = $connectionString
            $command = $connection.CreateCommand()
            $command.CommandText = $query
            $adapter = New-Object -TypeName System.Data.Odbc.OdbcDataAdapter $command
            $dataset = New-Object -TypeName System.Data.DataSet
            $adapter.Fill($dataset) | Out-Null
            Write-Output -NoEnumerate $dataset.Tables[0]

    This all works fine from a PowerShell session or from the ISE, and I get a datatable returned.

    When I try this as part of a RunSpace script (all 64bit), there is nothing returned. I have a try/catch block around the Start-Job but nothing is caught.

    My question is whether I can run a Start-Job from a PowerShell runspace. The Start-Job codeline is part of a very large script invoked in a runspace via a

    $syncHash.btnStart.Add_Click({
     

     script block  as part of the execution of a WPF window using Boe Prox's (and others') excellent techniques

    Eric

    Tuesday, March 27, 2018 5:29 AM
  • Using start-job in a runspace will work but the job will not exist outside of the runspace and will disappear when the runspace closes.

    A "runspace" is just another instance of PwoerShell run on a new thread.


    \_(ツ)_/

    Tuesday, March 27, 2018 5:36 AM
  • Thanks jrv. That was my understanding, so it should be working. I will just have to look a bit deeper at why it works when invoked from a session, but not from a runspace. Diagnostics and debugging require a bit of inventiveness in this multi-threaded environment.

    Eric

    Tuesday, March 27, 2018 7:30 AM
  • Ran out of testing time. Used a different technique involving creating a .cmd file that ran Native database client processes. (.cmd file created using PowerShell, run from the runspace using & call with result sent to a file, and data imported by Get-Content). All fine now,

    I will get back to testing with Start-Job or Invoke-Command later when I have more time.

    Wednesday, March 28, 2018 12:50 AM