Load Sqlanywhere data provider in powershell - powershell

In Powershell v5 I'm Trying to load the ianywhere provider dll. I'm getting this loader exception:
 : The term 'Â' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
Weird, right?
My load command is
Add-Type -path "C:\Temp\sa\iAnywhere.Data.SQLAnywhere.v4.0.dll"
The ianywhere dll requires accompanying native dlls, which I have placed in the same folder. Those come in two versions, 32bit and 64 bit. I've tried both, and I've tried 32bit powershell and 64bit powershell. My shell is running as admin as well.

Related

Getting error when I try using Sharepoint Online power shell commands

When I try to execute Powershell command, it gives the error:
Connect-SPOService : The term 'Connect-SPOService' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Tried uninstalling and reiinstalling S P Online Management shell. None of the SPO commands are working.
On my system this came down to a conflicting .dll (different versions) that was found in both the SharePoint PowerShell module folder and the Global Assembly Cache.
I deleted the following file from the GAC:
C:\Program Files\WindowsPowerShell\tmp\Microsoft.SharePoint.Client.Publishing\v4.0_16.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Client.Publishing.dll
After that everything was running smoothly. Full details on research leading to this is found here:
https://www.easy365manager.com/the-term-connect-sposervice-is-not-recognized/
Are you using the cmdlet in the SharePoint Online Management Shell or in the PowerShell? If you are using it in PowerShell, still you need to import the module with
Install-Module -Name Microsoft.Online.SharePoint.PowerShell
Besides, ensure you are running the management shell under administrator privilege.
Here is a doc which may be helpful:https://learn.microsoft.com/en-us/powershell/sharepoint/sharepoint-online/connect-sharepoint-online?view=sharepoint-ps
On mac run the following command:
rm -rf Users/<username>/.local/share/powershell/Modules/Microsoft.Online.SharePoint.PowerShell/16.0.22810.12000/Microsoft.SharePoint.Client.Publishing.dll
PS: replace with username

Write-SqlTableData is giving error in powershell

I often use Write-SqlTableData on my computer but for some reasons I cant make it work on a different pc. I have tried to do this before:Install-Module SqlServer and Import-Module SQLPs but I still get the error below:
Write-SqlTableData : The term 'Write-SqlTableData' is not recognized as the name of a cmdlet, function, script file,
or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and
try again.
Is there anything am doing wrong here?
I have upgraded from powershell 4 to 5 and installed (install-module sqlserver) it then worked.
You can also check solution here: Time to Upgrade Windows PowerShell to Version 5.0

Powershell Webjob fails to run

I have created a Powershell Webjob for use in the Azure Logic App. The code is trying to generate a signed URI so the end user can download the file when its available. To do that I created a simple Powershell Webjob.
New-AzureStorageContext : The term 'New-AzureStorageContext' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
CommandNotFoundException New-AzureStorageBlobSASToken : The term 'New-AzureStorageBlobSASToken' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I know these are part of the Azure Powershell. But is there an alternative for them to run? Or would I need to resolve to a separate console application?
After a lot of google searching, I found that Azure Powershell jobs do not support Azure commands. They have a plan to allow for that, but currently you cannot run Azure PowerShell Jobs on WebApps Webjob.

Powershell- NewAcceptedDomain Command is not working in not working in visual studio. But it works fine in powershell

I am trying to run this powershell command from visual studio.
My command is
add-pssnapin microsoft.exchange.management.powershell.snapin; New-accepteddomain –name domain123.com –domainname domain123.com
It always give me an error.
The error is:
"The term 'New-AcceptedDomain' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again."
But when i tried this command in powershell it works fine. But every time when i had try to run this command from my code it gives me error that i mentioned above.
IIRC the Exchange snapin is 64-bit therefore it is not available to the 32-bit PowerShell engine hosted in the 32-bit devenv.exe (Visual Studio) process. From the Nuget Package Manager console, execute:
Get-PSSnapin -Registered
To see if the Exchange snapin shows up.

Running Powershell script from SSIS with OnTap cmdlets throws error, but not when run from PS Cmd Line?

We are trying to run a Poweshell Script that uses the OnTap PS Modules, from SSIS, when we do, an error is issued:
Error: The term 'Connect-NaController' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
But when we run the same script from the Powershell Command Line, then the script runs just fine. So I think the scripts are fine.
So I'm wondering if the security context is different or we have to do something more explicitly in our call from SSIS?
When we call the script from SSIS we use: -ExecutionPolicy ByPass
Thanks!
In SSIS i had to set the FULL PATH of the script instead of ./scriptfile