I created a load test repository in my local machine SQL DB using loadtestresultsrepository.sql script. Then changed connection string from the default SQL Server Express local db to the one I wanted to store the test results using Manage Test Controllers window. Then I ran the test using VS ,MSTest command line and Powershell locally and results were written to the DB successfully.
I wanted to achieve the same outcome on TFS 2015 build agent so that I could run the load and performance test on the CI server. When I ran the load test on CI server using a build definition that uses command line mstest task /TestContainer:$(build.sourcesDirectory)\$(Component)\LoadTests\20_Users.loadtest, it did not write any data to default (localdb)\v11.0 server. But the load test ran successfully. I RDP to the build agent, open the solution from previously copied build artifacts and again set the connection string to the SQL server DB on the build agent using Manage Test Controllers window. Also created load test repository on build agent as well. But load test results are not written to the DB when I am running the tests using build definition.If I execute the same mstest command using powershell or cmd prompt on build agent, it writes the results. Can someone help me. How can I get the build definition / test controller to write the data to the DB I have configured in build agent ?
Related
I have one package which loads data from excel using ace.oledb.12.0 driver to SQL server(same server where SQL agent service is running.).
When I ran this Step from SQL Agent using Infrastructure Service account it succeed.
When I ran this step using a credential account it is stopping the job as a failure 'Unexpected Termination'.
Funny part is this is running exactly fine for files with data size low(100kb-300kb) when run from both Infrastructure Service account and a Credential account.
But for my current file having size 4.5 mb it is failing via Credential account.
Is there a way I can capture why the job is getting terminated?
Disclaimer: I work for ZappySys
Looks like you need to find out detailed error message to know more. Did you deploy package using SSIS Project Mode in SSISDB or running as File System Package? When you run SSIS Package via Agent Job you will see very limited error message and many times its useless. So better to run package under SSIS Catalog so you see full execution log. If that is not possible then try to Add Some SSIS Log Provider (see below) for better logging on error messages.
How to add SSIS Log Provider in your package
How to view execution log in SSIS Catalog (See Step#10 in this link)
I have an SSIS package that creates 2 text files using a data flow component. It connects to an SQL database and if the query returns data, the 2 files are created.
After that, a script task loops through the folder where the 2 files are written into, determines the oldest file and moves it to another folder.
Everything moves smoothly when I execute the package on the server. No errors and all functions are executed. Perfect.
However, when I schedule the SSIS package in a job, the said script task only gets executed when the SQL query (data flow component) returns no results and therefore no files are created. The script then moves the 2nd file from the last run to the other folder.
If the data flow does create 2 new files, the script task does not do anything.
Any ideas how to change this behavior?
Again, this only happens when executed through a job, not when run locally.
Thanks,
Daniel
When SSIS packages are executed from SQL Server they access file system using the SQL Server Service Account NT SERVICE\MSSQL$<Instance Name> (Where <Instance Name> should be replaced by the installed instance name). You have to Grant this account to access the selected directories or run the SQL job using a proxy account:
SQL Server Service account Permissions:
Configure File System Permissions for Database Engine Access
Setting proxy account:
Running a SSIS Package from SQL Server Agent Using a Proxy Account
Create a SQL Server Agent Proxy
The package is running using a proxy account. All the other package are running and saved in the same folder. In this one the file saved in this folder has to move to a different one which saves to differnt application which uses third party dll.
I am calling the library using reflection. But the dll is not registered in sql. Will that be a issue?
I have multiple C Unit Test programs that connects to a REST Server and sends/receives some data. I usually open a new terminal and start the server by typing mvn jetty:run and in a different terminal I do perform the Unit Tests by entering make test. The problems is that the Code is tested by a Jenkins server and the Unit Tests fail because they can't connect to a REST Server. I tried opening the REST Server with a CMake execute_process(COMMAND mvn jetty:run), but then the Unit Tests never ends because the server is waiting for input. I also tried opening the server with mvn jetty:start, but the Server doesn't seem to remain active after the command finishes. It just tells "Jetty Server started", but I can't see any running REST Server nor make a connection with it and mvn jetty:stop says there is no active server running. I also tried opening the server in parallel using the &, but Maven blocks it. The attempt to open the Jetty Server in parallel using a ShellScript that I would execute using the & didn't work either. Also the problem is that when I execute the Server in parallel I don't know when the server has started up and is ready for the Unit Tests to begin.
The best solution would be if I could open the server, perform the Unit Tests and close the server afterwards fully automated with CMake.
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
I have an SSIS package that I have deployed to the file system. The owner for the package is my Windows Login. The reason for this is that it needs to write files to another server. If I make the owner NT SERVICE\SQLSERVERAGENT the error that I get is that the files on the remote server cannot be accessed.
The package itself runs under my account. The package normally takes about 5 minutes to run and works when run directly (double click, click Execute and enter decryption password). I can tell the package has run because it writes a number of logs to the file system.
I've set up a SQL Server job to run the package. The job says it's run successfully but there are no logs being written. I'm not sure where I've gone astray other than there's some account that I'm likely missing.
Has anyone else ever run into this?
The issue was that I needed to set up a proxy Account to run the SQL Server agent.