SQL Server Profile Reusable Trace File - sql-server

I can create a Trace and get it up and running with SQL Server Profiler.
However, instead of going through the process of picking everything I want to trace including a particular database everytime, I just want to save the configuration, and reopen at a later time and on other computers.
I know I can save a template with the configuration in, but that is on a particular server.
Is this possible to save the configuration to a file and open on another computer?
I'm using SQL Server 2012.

Related

Creating an autoupdate for my program and its database

I've already an offline updater as a download but I want to make it automatically. It's a client/server software and a ms sql database.
3 parts have to be updated:
update of a proprietary software (setup.exe with next, next, type login/password for server service, finish) which delivers a WinClient and a Service for the server. Autoupdate is only needed for server, the autoupdate for clients by the server works already.
one .hug file which contains new customized program version. The path is a directory in the above software and can be determined with registry.
MS SQL database update with new content (in a .bak file) and structural changes. The database server is sometimes another server as application server. At the moment you have to type in the SQL instance when running the udpater.
My ideas are these:
a updater program in the tray on application server and database server
updater searches with a timer for newer versions on my ftp server and downloads the files if existing
on application server it runs the setup.exe and copies the .hug file. Maybe I could make it silent with command prompt commands. But still need to fill in login/password for the service user.
on database server I configure the autoupdater once with instance name. Updater downloads .bak-file and runs sql script with insert, update and alter statements.
but one big problem which can cause problems is when users are still logged in. Don't know in the moment how I could solve that.
So, how would you realise such a project? Or have you already done something similiar? Is its generally possible?

Not able to attach database in SQL Server 2008R2

I have SQL Server 2008R2 on my laptop, with a number of databases on it.
I detached one of my development databases today (I wanted to take a copy) using SSMS, and now I can't re-attach it. Whenever I try I get the following error
CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file
I have seen numerous similar questions on this, and they always seem to suggest the database being attached to another SQL Server instance. I have checked as to whether I have another SQL Server instance running, can't see anything even remotely like in Task manager. I even restarted the computer to clear any if they were there - no joy.
I read somewhere that if I change the Log On checkbox on the SQL Server Services properties Log On tab to Local System Account that should do it; it didn't.
I am at a complete loss as to where to go next.
Any ideas anyone?
Error 5 is Access Denied. It is a permissions issue. You do not have permissions to write to that location. You probably should be an Administrator on that machine.

TSQL and UNC Paths

I'm not an expert with TSQL so have patience with me please. So recently I was doing a project in TSQL on my local server using SQL Server 2008 R2 Management Studio. I was reading my files from a temp file on my C: drive and bulk inserting them into tables at the time.
Then I went and moved to a regular server instead of my local server on my machine.
It took me a bit to realize that I no longer had access to my local machine folders and files, and that is causing me issues.
I've read that one solution is to create a mapped drive on the server, but this is not an option for me.
So my question is what are other options for me? Could I use UNC paths to access my files or anything else?
The files I want to access are regular text files that are comma-delimited and newline terminated.
(I saw somewhat similar questions to mine, but there's seemed server specific or specific to their particular issues. Also none of their questions were answered.)
Actually a mapped drive won't work either because the account SQL runs under by default (local system if I recall) will not have network access.
So, the more reliable way to do this is definitely with a UNC path BUT there is more! (I've done this several times when I've needed to move database backups and log backups across servers for mirroring).
How?
On the SQL server machine AND the other server that will host the share, create a new user (same username and password on both machines) - assuming your not using AD. The user needs not be in any groups at all other than the users group but it must be called the same in both servers and the password must match.
On the SQL server machine change the account that SQL SERVER is running under. This is done in the SQL server configuration tool. Do not try to do this yourself via windows services. Choose the user that you created in no 1 above. Note you have to enter the pw. Restart SQL after you've changed it and verify SQL still runs fine. It should run just as before but now is running as a particular user with all the permissions of that user (which actually are very limited anyhow, but at least the user can access network resources).
On the remote server, make sure the new user has NTFS permissions on the folders that will host your share. Read/write perhaps or just read if SQL is only reading data.
On the remote server, create a share pointing to the appropriate folder that you set permissions for above. Make sure if you're using share permissions that the new user also has permissions on the share (not just on NTFS on the drive).
Once all of this is setup, your SQL scripts simply use the UNC path that points to the remote share and since SQL is running "as" a user with access to that share, SQL will see the files just fine!

Bulk Insert - Does the file need to be accessible to database server or local machine?

My question is about where I should put a file I need to use in a BULK INSERT command in MS SQL.
I have a database running on a server. I run queries on this through an ODBC connection from my machine on the same network. I want to create a stored procedure that will use Bulk Insert to import data from a .txt file and then execute this stored procedure from my machine (from clicking a button in an Excel sheet).
I'm no expert on how SQL Server actually works to say the least so I have what I imagine is a very basic question for someone who does. Does the .txt file used in the Bulk Insert need to be in a location that can be read by:
a) my machine e.g. on it's local hard disk
or
b) on a location that can be read by the database server e.g. somewhere on the network that it can access
I'm not sure if my local machine or the server is actually opening the file. I would assume it's the server, but I'd like to be sure!
Many thanks in advance for your help!
If the file is not on the server computer, then you will need to make sure SQL Server has access to the file. This becomes a permissions issue. In particular, the permission you need to look at is the log on account for the SQL Server service. Open the services control panel, locate the SQL Server service and check the log on account in the properties section.
As a general rule, it's not a good idea to give too many network permissions to the SQL Server service account because this can allow hackers access to resources outside the server computer.
If you mean the BULK INSERT command from T-SQL then the name of the 'data_file' can be a local filename or an UNC path, local that is to the SQL Server machine running the query. You can put the file to import from on a share hosted on the SQL Server machine or on any other share in the network the SQL Server has access to.

Changing connection to SQL Server in Microsoft Access 2003 ade file

I developed an Access 2003 application that is connected to SQL Server.
My problem is that I developed the software on my server, and the application runs on the client network on a different (identical) server.
As a result my executable file (Aka. .ADE) does not open on the client's computer, because of bad SQL Server connection.
My solution so far was to open the application file (.ADP) on the client's computer, changing the connection path from there and then creating there the executable file.
Now my client has only Access runtime environment, so I cannot do such thing.
I wonder if there is a way to determine the connection in an ADE file this way.
(I know I can change it through VBA, but when the connection is initially false, I don't even get to the VBA code stage.)
In the interest of keeping things simple, I'll say you need to set up a testing environment you control that mimics your client's environment. For instance, if they have a sql 2008 server named "SQL1", then you should install sql 2008 express on your machine, and rename your machine to "SQL1" so you can test. You'd also need to copy the schema of their database tables and put that same schema in your own test database, and fill it with test data that is similar to theirs. And you'll want to create duplicate logins as well.
With all that in place, I wouldn't think you'd need to update anything. Just copy the ADE file over to your client when you're done making changes. You could try to code your way though this scenario, but I've been there and done that. Having a test environment that apes your client's takes a lot of headaches out of the equation.

Resources