I'm trying to use Powershell V2.0 to programatically compact and repair MS Access 2007 (.accdb) databases. The code I've created below works as part of the final code (several backup procedures occur prior to this function running).
I'm running into trouble though as all the databases are password protected and I need to run the script without the user having to enter the passwords manually. Here's my code so far:
Param([string]$strDBPath,[string]$strBUPath,[string]$strPwd)
$ErrorActionPreference = "Stop"
function CompactAndRepairDB {
regsvr32 "C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll"
regsvr32 "C:\Program Files\Microsoft Office\Office12\Acedao.dll"
regsvr32 "C:\WINNT\assembly\Microsoft.Office.Interop.Access.Dao\12.0.0.__71e9bce111e9429c\Microsoft.Office.Interop.Access.Dao.dll"
$Database = New-Object -ComObject Microsoft.Office.Interop.Access.Dao.DBEngine
$Database.CompactRepair($strDBPath,$strBUPath,"","",";pwd=" + $strPwd)
Remove-Item $strDBPath
Rename-Item $strBUPath $strDBPath
}
CompactAndRepairDB
The code throws an error though as below:
Cannot load COM type Microsoft.Office.Interop.Access.Dao.DBEngine.
At U:\Scripts\CompactRepairDatabase.ps1:11 char:27
+ $Database = New-Object <<<< -ComObject Microsoft.Office.Interop.Access.Dao.DBEngine
+ CategoryInfo : InvalidType: (:) [New-Object], PSArgumentException
+ FullyQualifiedErrorId : CannotLoadComObjectType,Microsoft.PowerShell.Commands.NewObjectCommand
How do I load the correct library / COM object to complete the operation or is there an alternative method to achieve the .CompactRepair method using the password? Thanks
Remove the -ComObject from the line:
$Database = New-Object -ComObject Microsoft.Office.Interop.Access.Dao.DBEngine
Microsoft.Office.Interop.Access.Dao.DBEngine will be a managed interop wrapper around DAO.DBEngine so you don't need the -ComObject switch.
Try this:
Add-Type -AssemblyName Microsoft.Office.Interop.Access
$File = "Your.accdb"
$DbEng = new-object Microsoft.Office.Interop.Access.Dao.DBEngineClass # no square bracket []
$Db = $DbEng.OpenDatabase($File)
$Db
Related
I have the following code to upload a file to an FTP Server via powershell but it's giving me this error:
Code:
$Directory=”C:\test”
#FTP server configuration
$ftpserver = “ftp://ftpserver/”
$username = “user”
$password = “pw”
$webclient = New-Object System.Net.WebClient
$webclient.Credentials = New-Object System.Net.NetworkCredential($username,$password)
#Copy each file which type is *.tx*
foreach($file in (dir $Directory “*.txt*”)){
“Uploading $file…”
$uri = New-Object System.Uri($ftpserver+$file.Name)
$webclient.UploadFile($uri, $file.FullName)
}
Error:
Exception calling "UploadFile" with "2" argument(s): "Excepção durante um pedido WebClient."
At C:\Users\home\Desktop\test6.ps1:16 char:1
+ $webclient.UploadFile($uri, $file.FullName)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException
Try it like so:
$Directory = "C:\test"
#FTP server configuration
$ftpserver = "ftp://ftpserver/"
$username = "user"
$password = "pw"
$ftpserverURI = New-Object -TypeName System.Uri -ArgumentList $ftpserver, [System.UriKind]::Absolute
$webclient = New-Object System.Net.WebClient
$webclient.Credentials = New-Object -TypeName System.Net.NetworkCredential -ArgumentList $username, $password
#Copy each file which type is *.tx*
Get-ChildItem $Directory -Filter *.txt* | ForEach-Object {
Write-Host "Uploading $($_.FullName)..."
$uri = New-Object -TypeName System.Uri -ArgumentList $ftpserverURI, $_.Name
$webclient.UploadFile($uri, [System.Net.WebRequestMethods+Ftp]::UploadFile, $_.FullName)
}
The differences are that I'm making System.Uri combine the path instead of relying on string concatenation, and I'm telling WebClient.UploadFile() the method to use when uploading the file.
If this doesn't work, then I agree with the comments that you should examine the server logs. If you can't, then try it against a server that you can see the logs for. Alternately, you may want to try to use WinSCP, which is also scriptable with PowerShell or with a custom script file. WinSCP has the advantage of supporting FTP, FTPS, and SFTP, as well. The .Net WebClient only natively supports plain FTP, as far as I'm aware.
As far as smart quotes, they work just fine on Windows PowerShell (<= v5.x), but they don't work at all on PowerShell Core (v6+). I would avoid using them to make your code more portable and more future proof.
I have a PowerShell script that uses the WinSCP .Net library to get some files from a FTP server.
The script runs automatically over night on a server from a administrator account using Task Scheduler.
The problem is that sometimes (it does not have a pattern or at least I can't figure it out) it gives me an error : "Object reference not set to an instance of an object".
Error:
Exception calling "Open" with "1" argument(s): "Object reference not set to an
instance of an object."
At C:\user\blabla\powershellscript.ps1:47
char:5
+ $session.Open($sessionOptions)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : NullReferenceException
The actual line from the code (line 47) is : $session.Open($sessionOptions).
If I run the script or the task from Task Scheduler it runs smoothly and does not give me any error.
PowerShell script:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
$FileSourcePath = '/path_to_the_file'
Add-Type -Path "C:\WinSCP\WinSCPnet.dll"
# Set up session options
$sessionOptions = New-Object WinSCP.SessionOptions -Property #{
Protocol = [WinSCP.Protocol]::Sftp
HostName = "ip_to_the_server"
UserName = "correct_username"
Password = "correct_password"
SshHostKeyFingerprint = "correct_sshrsa_fingerprint"
}
$session = New-Object WinSCP.Session
try {
# Connect
$session.Open($sessionOptions)
# Transfer files
$session.GetFiles($FileSourcePath, $FileDestinationPath).Check()
} catch {
$_ | Out-File c:\blabla\errors.txt -Append
} finally {
$session.Dispose()
}
I fixed it by moving the scripts from Task Schedule to SQL Server Agent job. Now it works flawless.
Thank you for all the feedback and advices.
$wshell = New-Object -ComObject Wscript.Shell
$wshell.Popup("********Please Select the SOURCE Directory********",0,"Directory Selecter 5000",0x1)
Function Get-Folder($initialDirectory)
{
$foldername = New-Object System.Windows.Forms.FolderBrowserDialog
$foldername.rootfolder = "MyComputer"
if($foldername.ShowDialog() -eq "OK")
{
$folder += $foldername.SelectedPath
}
return $folder
}
$a = Get-Folder
$wshellb = New-Object -ComObject Wscript.Shell
$wshellb.Popup("********Please Select the DESTINATION Directory********",0,"Directory Selecter 5000",0x1)
Function Get-Folder($initialDirectory)
{
$foldername = New-Object System.Windows.Forms.FolderBrowserDialog
$foldername.rootfolder = "MyComputer"
if($foldername.ShowDialog() -eq "OK")
{
$folder += $foldername.SelectedPath
}
return $folder
}
$b = Get-Folder
Set-Content -Path "C:\script\scripts\script data.txt" -Value "$a" -Force
Set-Content -Path "C:\script\scripts\script data2.txt" -Value "$b" -Force
So this script works in ISE and if I copy/paste it into a CLI and that's it. If I navigate to the folder in the powershell CLI and run it from there it gives me this error:
New-Object : Cannot find type
[System.Windows.Forms.FolderBrowserDialog]: verify that the assembly
containing this type is loaded. At
C:\script\scripts\pathingworking.ps1:8 char:19
+ $foldername = New-Object System.Windows.Forms.FolderBrowserDialog
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidType: (:) [New-Object], PSArgumentException
+ FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommand
The property 'rootfolder' cannot be found on this object. Verify that
the property exists and can be set. At
C:\script\scripts\pathingworking.ps1:9 char:5
+ $foldername.rootfolder = "MyComputer"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : PropertyNotFound
You cannot call a method on a null-valued expression. At
C:\script\scripts\pathingworking.ps1:11 char:8
+ if($foldername.ShowDialog() -eq "OK")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
This error comes back twice, once for each instance of the folder selection window that is supposed to pop up.
I have tried -STA from run dialogue, shortcuts, and even from the CLI and it always gives me that error. I have verified using [System.Threading.Thread]::CurrentThread.GetApartmentState() that the open instance of powershell is STA. I can open a powershell CLI and navigate to the folder where the script is, invoke the script, it will give me the error, then I can copy\paste it in the same exact CLI and it works without issue. I have also right-clicked the file in Explorer and selected "run with powershell" and it also gives me the error. I have elevated the CLI to see if that helped with no success.
I fear this is some small oversight and hopefully someone can give me a hand.
using v1.0
windows 10
Cannot find type [System.Windows.Forms.FolderBrowserDialog] is due to the assembly not being loaded.
load the assembly with
Add-Type -AssemblyName "System.Windows.Forms"
rerun's answer solves the errors, but doesn't do a whole lot of explaining. Designing a script in the ISE (which is what I do almost exclusively) is convenient because it will automatically load types and modules for you. If you plan on running the script from another CLI (Command Line Interpreter) you should make it a habit of explicitly loading needed modules and assemblies early on in the script, so that when those things are called upon later PowerShell will know what you're asking for.
Unfortunately there's no easy way to tell what you will need to do that for when it comes to what types are going to be inherently available, but a little trial and error usually points it out rather quickly, or if you look at your script and see that you are making a new object with System.Kitchen.Pasta, then you probably need to load the assembly for System.Kitchen first, so that it has the Pasta type available when you want it, so you could just include a call to load that assembly near the top of the script with no harm done.
In your specific case, as has already been pointed out, you will need to load the assembly that contains the FolderBrowserDialog box that you want to display. Adding the following as the first line of your script will resolve the errors that you are seeing:
Add-Type -AssemblyName "System.Windows.Forms"
I have the following Powershell script I am trying to run:
add-type -path "C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.SqlServer.Dac.dll";
$d = new-object Microsoft.SqlServer.Dac.DacServices "server=localhost"
# Load dacpac from file & deploy to database named pubsnew
$dp = [microsoft.sqlserver.dac.dacpackage]::load("c:\deploy\MyDbDacPac.dacpac")
$d.deploy($dp, "MyDb", $true)
However, when it runs, I am getting the following error:
New-Object : Exception calling ".ctor" with "1" argument(s): "The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception."
At C:\Scripts\DeployDacPac.ps1:3 char:16
+ $d = new-object <<<< Microsoft.SqlServer.Dac.DacServices "server=localhost"
+ CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
+ FullyQualifiedErrorId : Cons tructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
I am trying to run this for an automated database deploy but cannot get past this weird error.
I have already set my execution policy to remotesigned and updated my runtime version for Powershell to .NET 4.0. Can't figure out what else could be wrong.
Any help would be greatly appreciated!
The problem here is that the default authentication method is SQL Server authentication which expects a username and password. You will need to either supply those parameters or explicitly specify that Windows authentication should be used. You can do this by replacing your connection string argument with the following.
"server=localhost;Integrated Security = True;"
Alternatively, you could use the following function to encapsulate this logic. Note that the default parameter set is 'WindowsAuthentication' which does not include the UserName or Password parameters. If you supply either of these, Powershell will use the 'SqlServerAuthentication' parameter set and the $PSCmdlet.ParameterSetName variable will be set appropriately.
function Get-DacServices()
{
[CmdletBinding(DefaultParameterSetName="WindowsAuthentication")]
Param(
[string]$ServerName = 'localhost',
[Parameter(ParameterSetName='SqlServerAuthentication')]
[string]$UserName,
[Parameter(ParameterSetName='SqlServerAuthentication')]
[string]$Password
)
$connectionString = "server=$serverName;";
if($PSCmdlet.ParameterSetName -eq 'SqlServerAuthentication')
{
$connectionString += "User ID=$databaseUsername;Password=$databasePassword;";
}
else
{
$connectionString += "Integrated Security = True;";
}
$result = new-object Microsoft.SqlServer.Dac.DacServices $connectionString;
return $result;
}
The following code throws an exception in Powershell V1 (Excel 2007):
$E = New-Object -COM "Excel.Application"
$E.Visible = $True
$wb = $E.Workbooks.Add() #<<<Exception here
The error says that the format might be old or that the type library is not valid (translated from Spanish). A similar script for Word works just fine.
Office interop assemblies seem to have this problem when the current culture is not en-US. The obvious workaround is to set the culture.
It's important to run the whole thing as a single command on the interactive console, since PowerShell V1 always creates a new thread for each command invocation.
PS C:\Users\jachymko> $e = new-object -com excel.application
PS C:\Users\jachymko> $e.workbooks.add()
Exception calling "Add" with "0" argument(s): "Old format or invalid type library. (Exception from HRESULT: 0x80028018 (TYPE_E_INVDATAREAD))"
At line:1 char:17
+ $e.workbooks.add <<<< ()
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ComMethodTargetInvocation
PS C:\Users\jachymko> & {
>> [threading.thread]::CurrentThread.CurrentCulture = 'en-US'
>> $e = new-object -com excel.application
>> $e.workbooks.add()
>> $e.visible=1
>> }
>>
Adapted to Powershell from one of the solutions proposed in MS Help and Support Article 320369.
$ci = new-object system.globalization.cultureinfo "en-US"
$e = New-Object -COM "Excel.Application"
$e.Visible = $True
$e.UserControl= $True
$books = $e.Workbooks
$books.PSBase.GetType().InvokeMember( `
"Add", `
[system.reflection.bindingflags]::InvokeMethod, `
$null, $books, $null, $ci)
From the same article:
When you use one of these workarounds for a computer where the regional settings
do not match the current language version of Office, you should be familiar with
how Excel behaves and how Excel will interpret data that might be formatted for
a specific locale.
I had this issue when trying to open a workbook. I added this line:
[threading.thread]::CurrentThread.CurrentCulture = 'en-US'