Yeah I did add the 4 dlls, found in:
C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies
Which are these:
Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.SqlEnum.dll
And modified app config so it accepted the version the dlls had:
<startup useLegacyV2RuntimeActivationPolicy="true">
</startup>
And imported from VB.NET:
Imports Microsoft.SqlServer.Management.Smo
Imports Microsoft.SqlServer.Management.Common
And the program recognizes every word except Server:
Dim fileInfo As New FileInfo(fi.FullName)
Dim script As String = fileInfo.OpenText().ReadToEnd()
Dim connection As New SqlConnection(sqlConnectionString)
Dim server As New Server(New ServerConnection(connection))
server.ConnectionContext.ExecuteNonQuery(script)
It says:
'Type Server is not defined'
Thus the program fails. Any ideas of what is going on? I'm pretty sure an identical scenario is working on a test project on another computer, I don't know why this isn't working. Thanks.
UPDATE:
I tried bringing the dlls from the computer that has this program working to here, and Smo contained Server, so there were no errors. But when I built the program it's like the dlls changed during runtime or something, because suddenly Server is marked as an error again and Smo doesn't contain it anymore, why is this happening?
SMO is unfortunately not something that can be deployed by just copying the DLLs. We have this in our app (along with RMO and others), and it is a right pain to deploy to production. It needs the appropriate MS installers run.
You can get them from here:
http://www.microsoft.com/en-us/download/details.aspx?id=16978
Or, the 64bit installer:
http://go.microsoft.com/fwlink/?LinkID=188439&clcid=0x409
Related
I have recently installed SSMS 2022 V18 on my D: drive to conserve some space on the C:
When I try to execute the .dtsx file it says that there is no program available to execute it.
Is there some way to make this work or do I have to re install SSMS on the default C: drive.
10/27/22
Loaded SQL server 19 developer version. included the Integration service. Now I can import my dtsx files and execute them. So far so good. What I would like to do is run the .dtsx packages using DTexec.exe. I follow the example of executing dtexec running a file dtexec /f "d:\documents\sql\hits.dtsx" and it complains about the version numbers.
Package migration from version 8 to version 3 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.".
THe dtsx file was created while running sql server 19 SSMS v 18.12.1. Should I load the SSMS package from SQL19?
Any other info would great.
Thanks
SSIS packages are executed by
DTEXEC.exe for command line runs (requires installation of SQL Server Integration Services Service to pass a licensing check)
Custom code referencing the SQL Server assemblies
The managed object model in the SSISDB https://techcommunity.microsoft.com/t5/sql-server-integration-services/a-glimpse-of-the-ssis-catalog-managed-object-model/ba-p/387892
That's it, those are the three "runners" of SSIS packages. Using SSMS to run a package depends on "how" you were doing it versus what you're attempting now. Ultimately, you're connecting to a database and asking it to run a package.
If the package is in the SSISDB, it's using MOM.
It you were running a job, it's dtexec.exe
If you connected to the Integration Services connection node "thing" in SSMS, that's using dtexec, the 64 bit version I think?
If that's the case, changing SSMS likely also involved changing versions of SSMS which is version specific from what I can tell with that connector option.
OK so I came up with a solution for executing dtsx packages from another program.
the program that I want to run is DTExecUI.exe. In my case that's found in
"D:\Program Files\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn\DTExecUI.exe"
This program takes a parameter /f to indicate that is to get the data from a file and then the file location. example " /f D:\Documents\SQL\ipdata.dtsx.
Having figured all that out I wrote a little console app in VB that take the file name as a input parameter and launches DTExecUI to execute the file.
Imports System
Module Program
Sub Main(args As String())
Dim app As String = "D:\Program Files\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn\DTExecUI.exe"
Console.WriteLine(args(0))
Dim Arguments As String = "/f " & args(0)
LaunchProc(app, Arguments)
End Sub
Sub LaunchProc(fileNam As String, ByVal Optional arg As String = "",Optional wt As Boolean = True)
Dim p As New Process
p.StartInfo.FileName = fileNam
If arg > "" Then p.StartInfo.Arguments = arg
p.Start()
If wt Then p.WaitForExit()
End Sub
End Module
To make make it so I can run the dtsx file directly by double clicking on it. I associated the dtsx file extension with my little program. Works like a charm.
I have written a VB.Net application that uses an SQL Express DB file containing a single table and a handful of stored procedures.
I have successfully built and exported the application to my VPS.
The problem comes when knowing what to do concerning the database file, there is a wealth of stuff online but not specifically to suit my needs.
I plan to use LocalDB on the VPS but being commandline - it is hard to know if the scripts that I have run have been successful after creating an instance , starting it... etc,
I want to keep installation requirements to an absolute minimum on my VPS machine and (in time other end users machines)... hence using LocalDB and not SQL Express
So, what do I have to do on the VPS to enable my application to connect to the database.. ? This was simple when it was Access - (supply the MDB file and run the AccessDatabaseEngine(redistributable) - job done)
The connection on my devt. machine runs as expected.
The connection string in my code is:
Const strSQLConnection As String = "Data Source= (localdb)\v11.0;Database=SoccerTrader;Trusted_Connection=True"
Can anyone help please.. this is driving me around the bend.. surely it cant be that difficult..?
===========================
I have found the following in an MSDN blog which says:
Database as a File: LocalDB connection strings support AttachDbFileName property that allows attaching a database file during the connection process. This lets developers work directly with databases instead of the database server. Assuming a database file (*.MDF file with the corresponding *.LDF file) is stored at “C:\MyData\Database1.mdf” the developer can start working with it by simply using the following connection string: “Data Source=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyData\Database1.mdf”.
================ ADDED 12th June =====================
OK, this is really bugging me now... I have read around this till it is coming out of my ears and nothing specifically seems to target what I am trying to do. All the blogs I read refer to installing / running SQL Server and changing permissions etc.
As I have mentioned I am using a VPS and propose to use LocalDB on the VPS to access a simple/small database file for a VB.Net application I am writing.
This is the story so far.
1) I have built a working prototype on my development PC and connected using SQL Express to a database file SoccerTrader.mdf - no problem.
In the Visual Studio Project properties I have added a requirement to the project that checks for SQL Server ..and if it is missing, installs it...
2) I install the project on the VPS and as expected SQL Server 2012 LocalDB is installed .... see here..
3) I have copied the SoccerTrader.MDF and SoccerTrader.LDF files into "C:\BESTBETSoftware\SoccerBot" on the VPS
4) for practical reasons given the problems I am having getting this to work, I have implemented an inputbox for me to specify the connection string when the application runs.... the connection strings I have used give the following...
1]: http://i.stack.imgur.com/i2tro.png
I have not changed any file permissions on the development PC and the database state is NOT read only....
So, the question is where do I go from here...? What have I missed.. why is it not working..?
I have managed to sort the problem.
Seemingly, the connection string I was using was OK. It was my error handling that wasnt 'clean' enough. It transpired the connection was being made on my VPS but when the application attempted to update the table , the directory I had created and put the MDF file into, would not permit write access.
I moved the MDF into the C:\Users\Public\Documents folder and all works as it should.
You have to specify the full path of the Db file with folder name/ip-address
This is the biggest problem I've had with my project so far. Every time I try to publish it, I get hangups and crashes whenever the project tries to access a database file (which is fairly often).
I have two database objects, both created as part of my Visual Studio project under the main solution, as BUILDERDATA.mdf and CHARACTERS.mdf. When I access them during test builds, everything functions just fine. However, they always fail in the published project.
I get the feeling either they're not exporting correctly, or the act of publishing the project is breaking the connection strings, so I'm hoping someone can help me pinpoint the issue.
Under my project settings, I have a connection set up to each database. They're both Connection Strings, their scope is Application, and the value is this:
Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\BUILDERDATA.mdf;Integrated Security=True;Connect Timeout=30
Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\CHARACTERS.mdf;Integrated Security=True;Connect Timeout=30
Under Project Properties -> Publish -> Application Files, both databases and their log files are set to Data File (Auto) for Publish Status, Required for Download Group, and Include for Hash.
Under my Prerequisites, I have SQL Server 2012 Express LocalDB marked, as well as Microsoft .NET Framework 4. Part of my code uses .NET, so that's required anyway, and I included SQL Server Express so it can access the database files. However, 2012 is the newest version available for me to include, so I'm not sure if there's an issue with that version?
If there's anything else you guys would need to see, please let me know. I just want to get this figured out and fixed so I can have my friends start testing my program. :(
I'm getting an error when I try to compile or run the application.
Performing a simple tutorial, I worked at first but now when I generate the project F6 or try to run it, I always get the error
Error 1 Unable to copy
"C:\Projects\DatabaseExampleApp\DatabaseExampleApp\App_Data\northwnd.mdf"
to "bin\Debug\App_Data\northwnd.mdf". The process can not access the
file 'bin\Debug\App_Data\northwnd.mdf' because it is being used by
another process. DatabaseExampleApp
The first time when I run the app worked fine
I'm using:
Visual Studio 2010 Professional
SQL Server 2012 Express 64-bits
EDIT:
after:
kill the sqlservr.exe (is the file locker)
delete the files myself northwnd.* northwnd_log.*
generate project F6
run the app work fine
But I have a questions:
how kill or unload the file northwnd.mdf to avoid this problem?
The app compile after that but don't run
You're not showing us your connection string, but I'm assuming you're using some kind of AttachDbFileName=.... approach.
My recommendation for this would be: just don't do that. It's messy to fiddle around with .mdf files, specifying them directly by location, you're running into problems when Visual Studio wants to copy that file around - just forget about all that.
I would
create the database on the SQL Server Express instance (CREATE DATABASE ..... in Mgmt Studio)
talk to the database by its logical name - not a physical file name
So I would put my database onto the SQL Server Express server instance, and then use a connection string something like this:
Server=.\SQLEXPRESS;Database=MyShinyDatabase;Integrated Security=SSPI;
No messy file names, Visual Studio won't have to copy around files at runtime or anything, your data is on the server and can be used and administered there - seems like the much cleaner and much nicer approach to me.
I've got a web application that uses Microsoft Sql Management Objects (SMO) dll's. I'm wondering how I go about redistributing the libraries for a remote machine.
As I understand it, these come with SQL server or Sql express - which isn't on the remote (shared) webserver. Asking the host to install them, is probably out of the question, so is it possible to dynamically load them?
See below error-
Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Alternatively, if anyone can provide a workaround for the below snippet that would also be useful. The script variable is a SQL install script which has been read to the end. The nice thing about this is the outputting of each of the execute strings from SQL. I could of course just execute it all in one chunk, but that provides no visual feedback to the user line by line, that the sql is executing ok.
Is there a stored procedure that could perform this sort of thing? Or an alternative way to execute an install script without full permissions.
Dim connection As New SqlConnection(Me.ConnectionString)
connection.Open()
connection.Close()
Dim server As New Server(New ServerConnection(connection))
server.ConnectionContext.SqlExecutionModes = SqlExecutionModes.ExecuteAndCaptureSql
Dim commands As StringCollection = server.ConnectionContext.CapturedSql.Text
server.ConnectionContext.ExecuteNonQuery(script, ExecutionTypes.ContinueOnError)
Dim s As String
For Each s In server.ConnectionContext.CapturedSql.Text
AppendMessages(s)
Next
http://www.mattberther.com/2005/04/11/executing-a-sql-script-using-adonet/
from
http://coolthingoftheday.blogspot.com/2006/11/execute-t-sql-scripts-with-gos.html
Was what I was looking for, and did the trick.
you can try using sqlcmd utilty that comes with sql server
No, you can't dynamically load them, and no, you can't install them without permissions. Sorry about that, but no dice there.