Just started getting my feet wet with interacting with SQL Server using PowerShell and have got this query:
For performing any sql server database operation, using .net framework based objects is my preferred choice mainly because of the reason that I come from C# background. For example:
$sqlCommand = New-Object System.Data.SqlClient.SqlCommand
However, I found that we can also use Invoke-SqlCmd cmdlet available in SqlServerCmdletSnapin100. As:
Add-PSSnapin SqlServerCmdletSnapin100
Set-Location SQLSERVER:\sql\DatabaseInstance\databases\TestDatabase
Invoke-SqlCmd -Query "SELECT * FROM [File]" -User "UserName" -Password "UserPassword"
Wondering, why one should ever go for using Invoke-SqlCmd instead of .net framework based objects?
Was Invoke-SqlCmd made available through PowerShell because some population out there is not familiar with .net framework.
Or
Are there any particular features offered by Invoke-SqlCmd for which we must use it.
Please guide.
Invoke-SqlCmd was made available through powershell by snapins, not by default. All it does is call the sqlcmd.exe, which existed before powershell, and was used to send sql commands through cmd. Now that we have direct access to .Net, we don't need it. There is nothing Invoke-sqlcmd can do that you can't do with .Net, SqlClient will always be the better choice IMO, because it is faster and you'll never get this "different behavior" Microsoft refers to.
http://technet.microsoft.com/en-us/library/ms162773.aspx
SQL Server Management Studio uses the Microsoft .NET Framework
SqlClient for execution in regular and SQLCMD mode in Query Editor.
When sqlcmd is run from the command line, sqlcmd uses the ODBC driver.
Because different default options may apply, you might see different
behavior when you execute the same query in SQL Server Management
Studio in SQLCMD Mode and in the sqlcmd utility.
Related
Has anyone had any luck publishing a VS Database Project over Babelfish? There is nothing on the net related to publishing .dacpac over BabelFish.
I can connect and query via new query in SSMS, however, connection fails while attempting to publish a DB project?
I am assuming there is missing functionality in TDS translation, and this does not fall with Babelfish's "most" tds commands are supported. Also, I am thinking that a Data-tier Application relies on more than just tds translation, there are server-side binaries that are part of the process which may be outside of the babel fish realm.
Would like confirmation from someone who has been down this road though.
I am using Rational Doors 9.6 as client. I try to integrate a feature in my C# program such is using Doors C API, to open a view and get some data in memory for further using. This includes login to Doors server with windows credentials.
Actually, I have to start Doors Client, open that view, do a excel export, then do a C# import which is not quite the elegant way.
I am not Doors expert so all I need is a opinion, since API is in C and I'm not sure this is the way, or just using DXL server (or both?)
I have been using un-managed C dll's in C# in the past, so if proper declared, should be no problems.
The DOORS C API is a very old artifact and not usable for your purpose.
You have to use a DXL script to perform the actions inside DOORS that you want (export). To launch the script you have three options:
invoke the DXL script in batch mode
The most stable approach. You should write the information to a file from your DXL and read it back from your c#. All "professional" DOORS interfaces (like MDWorkbench) use this approach.
invoke the DXL script in "interactive batch" (see below)
See below. You need to use this if you want to automate an existing GUI DXL script. See an example here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014305335&ps=25
invoke the DXL script over COM
For this you need to start the client in interactive mode and then connect to it over COM. For a discussion on that see here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014458173&ps=25
For the export itself there are many scripts on the rational forum. The fastest way to go, is to perform a CSV export yourself. See here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014627043&ps=25
Can PowerShell be automated? I.e. is there a COM interface to PowerShell that can be imported into Delphi as a type-library interface to automate it, and if so, what is the relevant file name(s)?
Googling, etc, I've found numerous references to automating things from within a PowerShell script, but I haven't been able to find anything to say whether or not I could control PowerShell itself via COM as I could it it were MS Word or whatever, and maybe receive events from it. What I'm wanting to do is to hand it a command from within a Delphi app to execute some arbitrary CmdLet and get status information back from it while it's executing the script (otherwise I'd make do with doing a ShellExecute on it).
I'm not sure whether the fact that I have been able to find anything is because PowerShell is by design not automatable or because I haven't managed to frame an effective query that filters out all the automation that can be done using PowerShell as a script host.
This is using XE8 on Win7 64-bit or its Win10 upgrade, btw.
Elaborating on RaelB's suggestion of http://delphidabbler.com/software/consoleapp:
This worked for me since Powershell itself can be run as a console app. If you wanted to run CmdLet "abc -param", then you would call the Execute method of a TPJConsoleApp instance:
app.Execute ('powershell -command abc -param')
Peter Johnson (delphiDabbler) provides several examples for interacting with the console app via pipes, files, etc. to get your status information back from the Cmdlet's stdOut (stdIn and stdErr are also available). Working code can be quickly derived from the most appropriate example.
Optionally you may want to provide additional parameters for powershell:
https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help
I would like to access the work items in our TFS programmatically. Shouldn't there be an obvious command line tool to extract such information? Or a WebService I can just call? I already have checked into using Excel - this is neat, but I want more hardcore...
Take a look at the TFS API (http://msdn.microsoft.com/en-us/library/bb130146(VS.80).aspx). Access to the same code used by Microsoft to create the Visual Studio integration and their version control command line tool (tf.exe).
You can also take a look at the power tools. tfpt.exe is the power tool command line and has many other advanced features. That said - you can do pretty much what you want with the SDK.
The new version of the power tools will be out soon, and that looks to have Powershell support coming
Enjoy!
If you download tfs power tools you can use "tfpt query" to your advantage.
I would like to include CLR stored procedure deployment in our deployment script (powershell at the moment), however I can't figure out a nice way to do this automatically.
I would have thought there would be a nice command line option to do the same as right-click deploy in Visual studio
Well, PowerShell itself won't give you much in the way of extra help. You don't mention which version of SQL, so I'll be a bit generic.
Really, all you need to do is have your script file copy the necessary DLLs for your CLR stored procs - PowerShell can copy files like a maniac, so no problem there. Then you need to execute the CREATE ASSEMBLY statement in SQL. PowerShell natively cannot help with this. If you're using SQL 2008, your script can Add-PSSnapin the SQL cmdlet provider, which will give you a cmdlet capable of executing SQL queries - so that gets you your CREATE statement.
If you don't have 2008, you'll have to write a short .NET routine to create a SqlConnection and SqlCommand - not difficult, and entirely possibly in PowerShell.
Next, use the same technique to execute your CREATE PROC statement to actually create the stored proc using the aforementioned assembly.
Zat help? Pity there's nothing more automated, true. MS hasn't spent a lot of brainpower simplifying complex SQL deployment stuff of this nature, I don't think, and CLR stuff adds a bit of extra spice since you have to make the assembly available.
One can use techniques described at http://msdn.microsoft.com/en-us/library/ms345099.aspx to generate deployment script from SSMS. At least this addresses the tedious part of generating a ton of CREATE PROCEDURE statements.
The SQL Server Publishing Wizard can script CLR stored procs as text. Looks like it converts the binary source of CLR stored procs as some kind of hex encoded text.