I am currently building an application in .NET 4.0 that will use SSIS 2008R2 packages to do its job. The packages are located on a separate SQL Server. The SQL server has an account proxy that has all the permissions needed for the packages to execute (call Reporting services, access disk, etc).
My question is: what is the best way to run those packages from C#?
I read about using SQL Agent to run the packages through jobs but my concern is this - what account will the job and packages use? Will it be the account under which the application is running or I can use the proxy account that I have in SQL Server? How can I configure this?
Thanks in advance!
You can configure the user that each job step is run under in SQL Server agent. It is common to use the proxy user here.
An easy way to start the jobs in case you need SQL Server database access anyway is via calling the SQL Server Agent system stored procedures. But note that starting a job via dbo.sp_start_job is asynchronous: It just starts the job and then returns. You will have to poll other methods to check the job status or outcome.
And the database user that you are using to connect to the database (or your local user in case you use integrated login to SQL Server) must have the permission to call the stored procedure.
Related
I am executing a SSIS Package from a C# WinForm project. It executes and runs about halfway when it tries to create/write a file (An Expression in the Flat File Manager).
When I check the SSISDB Catalog on the SQL Server, I see the following errors for the package:
Flat File Destination failed the pre-execute phase and returned error
code 0xC020200E.
PO Header:Error: Cannot open the datafile "\Server\path\Admin Shared
Folders\Information
Systems\Projects\projectPath\filepath\636943168325507712-1070-15175.txt".
Based on the path and filename, the expression resolved fine. When I run the SSIS package directly it runs fine, so it appears to be a permission issue.
I am using Integration Services (MS SQL Server 2014) and right now I am using windows authentication in my connect string:
Integrated Security=SSPI;
However, the group who will be using the app will not have full permissions, so a specific user account will be created in SQL Server that I will use to connect. That said, assuming that this is a permission issue, how does the SQL Server account need to be created / what permissions and considerations need to be applied? What other permission issues/considerations need to be taken into account?
ie, we have no idea how to create the account to make this work and need help!
I think you are ask for run with SQL agent and hit permission issue, you can do this, in Windows service there are a service name call SQL Server Agent, and Log on with a special account, likely you create a individual account, and give this account to your folder permission.
Make sure that SQL service account can access to this path and has needed permissions:
Configure File System Permissions for Database Engine Access
I have a disk top application made by c# visual studio. My question is do I have to setup SQL server on each client to use my application? or there is another way to attach my database with my application and compress it as one and send to each client and those just extract that file and use the application correctly?
On a real scenario, your database should be placed on a remote server and the clients should only access the database through your API (that will need to support authentication or any other identity based systems).
If your application only needs to store some local information (relevant only for your client app), then you can just use LocalDB or AppSettings, depending on your data structure.
Otherwise, if your application contains more complex features, then you will need an API and a remote DB managed only by you.
To conclude, you only need to setup Sql Server once, when you want to create the design of it (tables, columns, links). The clients will only have to connect to it and pull their data. And this task can be done without installing SqlServer. This link shows you that you only need System. Data assembly to connect to a Sql Server DB.
Yes you need to instal SQL server on each machine or if you go for LocalDB then also u need to instal SQL server engine ,and you have a better option u need to buy sqlserver from AZURE (it's free for one month try if want click here AZURE)
On one side I have a Windows service that uses Entity Framework to connect to a SQL Server instance and work with a database there.
On the other side I have a WIX based installer which has a bootstrapper .NET based GUI in which the user can enter connection details to be used in the connection string by the service. In this installer GUI I am also performing a check on the user provided data and check the database connection (using SqlConnection.Open() and even creating/dropping a database).
The issue appears in a workgroup environment, no domain controller present, and when the user chooses Integrated Security as an option. The bootstrapper application successfully connects to the SQL server and performs some operations with it, but then the Windows service fails to connect to the SQL server using Integrated Security. If I follow up by changing that to user and password authentication, the service works correctly.
Is there any way to have the bootstrapper fail connection if the service would fail, or the other way around?
Thanks.
The most likely cause is the user the service is running under and the user the installer is running under are different.
If the User running the installer has access to SQL Server through windows authentication the connection would succeed. Then if the service runs under a different account (Say LocalSystem) the user the service is running under does not have permissions to use integrated security.
The way around this to use a service account which has permissions on the server or use SQL Authentication.
I ran into this recently when deploying a service. The only way to fail the bootstrapper connection would be to run it as the account the service will run under (impersonation is one way to accomplish this) otherwise there is no way you can test the connection correctly.
Since you mention workgroups and no domain controller there may be some pass through going on with the user names and passwords. At one place I worked, on one of the SQL boxes (off the domain) each developer had a local windows account with the same password as their domain account. This allowed a pass through authentication (due to the username and passwords matching) and access to SQL Server. That may be what is going on.
I have a windows application which is uses SQL Server as its database. For this application I want to create a setup file for other desktops, but I don't want to install SQL Server on each and every client.
Can you please suggest how to create Windows application with local storage setup file without installing any databases or framework libraries?
You can use SQL Server Compact. The database is stored in a file that you carry with the product rather than requiring a database server.
If this is just for "settings" then consider storing it in the user's application data as a simple XML file.
You don't need to install SQL Server on each client - you can simply install it on a central server then all the clients can connect to and use the same instance.
If this is not a good option because each client must have its own storage locally then you can look to use something like SQL Server Compact, which is a very cut down version of SQL Server that doesn't require installation and runs inproc.
How can I make a program use a SQL Server database, and have that program work on whatever computer it's installed on.
If you've been following my string of questions today, you'd know that I'm making an open source and free Help Desk suite for small and medium businesses.
The client application.
The client application is a Windows Forms app. On installation and first launch on every client machine, it'll ask for the address of the main Help Desk server.
The server.
Here I plan to handle all incoming help requests, show them to the IT guys, and provide WCF services for the Client application to consume.
My dilemma lies in that, I know how to make the program run on my local machine; but I'm really stumped on how to make this work for everyone who wants to download and install the server bit on their Windows Server.
Would I have to make an SQL Script and have it run on the MS SQL server when a user wants to install the 'server' application?
Many thanks to all for your valuable time and effort to teach me. It's really really appreciated. :)
Edit:
To clarify, each business will have their server completely separate from me. I will have no access whatsoever to them nor will they be in any way connected to me. (I don't know why I should clarify this :P )
So, assuming the have ABSOLUTELY NO DATABASE SERVER installed; what can I do?
Ok, part of the answer, dealing with the SQL Server Database (and frankly SQL Server Express will take you a long way - 4Gb of data) and the server install elements.
Firstly make installation of the SQL an SEP, make it a pre-requisite possibly tweak your installers to test (challenging) but substantially point them at the links to SQL Server express and let them get on with it).
Secondly separate installers, as suggested, for your client and your server elements.
Finally, how to build the database - I'd suggest using code to create and maintain (update) the schema i.e. once you have a connection to a server you can run code that calls DDL that does what is necessary (something like suggested here: How to create "embedded" SQL 2008 database file if it doesn't exist?)
A question - are you intending all communications from the clients to go through you WCF service?
Your install application should:
Obtain a SQL Server name, a username (with apprpriate rights to create a database) and password.
Either run SQL scripts using the locally installed command line tool or from code using SMO (for instance), against the user supplied server with the supplied credentials.
BTW, Before you expend effort writing an open-source help desk, have you checked what is already available? Also, Open Source Helpdesk
It is not so straightforward to deploy a client/server solution with an automatic installation.
You probably would then be better off to deploy your server installation together with a database engine and a skeleton database already setup according to your wishes. This is to avoid tampering too much with the existing server - who knows whats on it.
Also you say you want to install WCF services, well this would probably mean installing them on a customer server, in theory this shouldn't be a problem however in reality it could be, depending on what is previously on the server.
Do you want a single SQL Server instance running on your machine, or one on each of your customers' servers? If it's the latter, you'll want to install a SQL Server instance - anything from the (free, but limited and not open-source) SQL Server Express to a more expensive SKU - on each server. You can include this step in your server installation package; MSI installs make it very easy to bundle a MSSQL install.
Then you'll need to drop a schema, and maybe data, on the instance. You could do this as a step in your installer, or as part of your application setup process. It possible that a SQL Server instance, or more than one, might already be installed on the server, and your post-install step should allow the user to specify which instance on which to install your pieces.
Then, include a database configuration piece in your client application. Ask the user - or take from a configuration file at client install time, to allow for unattended or unprompted client installs - server connection details, like server name and authentication information.
A word on authentication - since you appear to be building Windows-based tools, use Windows integrated (domain-managed) authentication if at all possible. Don't get in the business of storing logins, but instead rely on the existing domain to manage logins. A good strategy is to use active directory groups to manage access. Grant access to a particular group in SQL Server, and defer group membership to Active Directory itself. If you can't gain the access necessary to do this, then grant permissions to AD user accounts themselves. Avoid creating SQL Server logins, the use of which open the door to some possible security problems.
I understand what you are trying to do. If I were you, I'd do the following:
Provide 2 downloads - 1 for client and 1 for server.
Forget about MS SQL Server and perhaps go with MySQL, since it really is open source. You could probably get away with using MS SQL Server Express Edition, but if your data set gets gigantic large (which is common with help desk databases), you'd be stuck.
As other people pointed out, on very first run (or at setup time), I'd have the client app locate the server.