Is there a way to change SQL Server Agent history values. I would to modify limit size of job history log from the defaults. Is there a way to change without use GUI for AWS RDS Instance.
Generally speaking, anything you can do in the GUI can be scripted by selecting the "Script" button at the top of the dialog/window rather than selecting the OK button at the bottom right. For this case, you will get something like:
USE [msdb]
GO
EXEC msdb.dbo.sp_set_sqlagent_properties #jobhistory_max_rows=1001,
#jobhistory_max_rows_per_job=101
GO
Related
This is relatively similar to questions such as these:
How can I change my default database in SQL Server without using MS SQL Server Management Studio?
https://superuser.com/questions/364825/sql-server-management-studio-ignores-default-db
That being said, Management Studio is ignoring all the suggestions. I'm logging in as sa, and I can see that the default catalog for sa is being changed successfully, but Management Studio ignores these changes in the dropdown:
Even if I change it to specific_database_name, and even if I can look at the sa login Properties menu and see that it's set to specific_database_name, Management Studio will always default that combo box to master.
I've tried:
Exec sp_defaultdb #loginame='sa', #defdb='specific_database_name'
ALTER LOGIN sa
WITH DEFAULT_DATABASE = specific_database_name
Going into the Properties menu for login sa in Management Studio and setting it in the dropdown box there.
The OP in the second question eventually fell back to using a batch file to log in as a different user, but I'd personally just rather keep having master show up. Also he did mention being able to set this on the connection properties themselves, but it's greyed out on my system, and I seem to remember being able to set this for an individual user a long time ago on another machine.
How can this be set? Note that this is not using a Windows login, but a SQL Server one instead. Thanks.
I don't know why these methods are not working. Just to be sure I just did the following (on SQL Server 2012 enterprise)
1) Created Login test and assigned x1 as default database
2) Added login test to database x1 (and made test a member of datareaders)
3) Reopened SSMS - Logged in as Test
4) Opened query window - was placed in x1.
You really want to make users default to a database that is not a system database - otherwise they will attempt to create objects in Master which is something you really want to avoid.
I have a number of views in my SQL Server database.
How do I export these as CREATE VIEW scripts?
I tried to right click the database - script database as - create to - new query editor window, but it doesn't show my my views (or tables even for that matter).
Any ideas?
In SSMS, if you right click the DB -> Tasks -> Generate Scripts... - that will take you through a wizard.
You can run through the wizard and select your DB, then the views as AdaTheDev mentioned or you can right click on each query and generate a script directly.
I prefer another way, because always I edit the views to remove "not necessary script generated SQL syntax" (depends on the point of view :)).
Right click the view, Generate script, CREATE in, new window.
See screenshot below (sorry for german version, but should work anyway).
I tried to right click the db - script database as - create to - new query editor window, but it doesn't show my my views (or tables even for that matter).
The purpose of the menu you mentioned is only to create the empty database, without any tables, views or anything else.
If you want to script anything beyond the empty database, you have to use the wizard already mentioned in AdaTheDev's answer.
Maybe you receive empty page because source of VIEW was encrypted or removed.
In older SQL editions there was a trick - after creating VIEW (SQL Server compiled it) developer could remove source of VIEW statement to protect it from "deassemblation". In current editions there is possibility to encrypt source of VIEW statement.
Say I already created my database but forgot to save the sql commands do create it.
How could I reverse engineer the code from an already existing database?
I'm using Microsoft SQL Server Express 2008.
You can do this pretty easily by using SQL Server Management Studio (SSMS) - it's available for free if you don't already have it installed.
Connect to the database
Expand out Databases > YourDataBaseName.
Right-click on the database and select the option "Script database as" then "Create To" then finally "File".
That will create the necessary scripts to recreate your database.
To script out all the tables in your database:
Right-click on the database node
Select "Tasks" then "Generate Scripts".
When the wizard appears, click Next.
Select the database. At this point you can check the "Script all objects in the selected database" which does exactly what it says, or if you leave it unchecked you will get the option later in the process to pick which items are scripted.
Click next. Now you're given some scripting options.
I'd suggest scrolling down the list and checking the option to Script Indexes/Script Triggers. You can also script the data if necessary (though I wouldn't do this if you've got a lot of data in your database).
Modify any options you'd like and click Next.
Select the database types you'd like to script (Users/Tables/Views). Click Next.
Now you've got the opportunity to select more specific items. Hit Next and repeat the process of any of your other database types.
Hit next one more time, then select where you'd like the script written to. You get the chance to review your selections.
Click Finish.
Here's a link for the 2008 version SSMS Express 2008
Your RDBMS comes with some sort of "dump" tool that will give you the structure and content of your database, in the form of SQL statements.
As others have mentioned, if you have SQL Management Studio (you should, it's free as part of SQL Server Express). Fire it up, connect to your instance then expand the Database tree.
Right click on your database and select Tasks->Generate Scripts..
Click next, then Next again (which selects all objects in the database by default), pick an output option (defaults as "Save to File"), click next and voila!
If you also want to script the data as well as the schema, in the "Set Scripting Options" window, click on the Advanced button, scroll down to "Types of data to script" (just above the Table/View Options header) and select "schema and data".
[Edit] Tested - The Generate Scripts option exists and works in the (free) 2008 R2 edition of SSMS. See the link in my comment below for the URI for the R2 version.
I'm using DBDeploy.NET for change control management in my T-SQL codebase. DBDeploy works by the developer maintaining a numbered set of change scripts. When a deploy is triggered (via NAnt), DBDeploy looks at a changelog table and determines which patches need to be executed to bring the instance up to date.
The issue I have is with setting the required settings necessary to create an indexed view. QUOTED_IDENTIFIER, ANSI_NULLS, and ARITHABORT all need to be on. Yes, I can easily put these SET statements at the top of the change script that creates/alters the indexed view. But these settings are connection level. What if later I'm building a new instance from scratch? When I run DBDeploy on the new instance, these settings will bleed through to all subsequent change scripts, since all change scripts are effectively concatenated into a final SQL script to be executed on a single connection. What's worse are parse-time options like QUOTED_IDENTIFIER, which would be applied to all change scripts prior as well. So:
I'm on SQL Server 2000. Is my interpretation of connection-level settings correct? I.e. using GO to break the script into batches does nothing to limit the scope of these SET options. What about later versions, where connection-level settings have been renamed batch-level?
Is there any way to unSET the SET? As I understand it, connection-level settings are trinary - i.e. ON, OFF, and default, where default is interpreted based on the content of the SQL statement, instance settings, database settings, and persisted user settings. If I SET something to ON, I can't undo it simply undo it by setting it to OFF, because it would mask default, if that's what the setting was before.
Is there any way to save the state of the connection-level setting before setting it, so I can manually restore it after?
The alternatives suck:
I can wrap each create/alter statement for indexed views in dynamic SQL - with it's 4000/8000 char limitation on SS2K. That would limit the scope of SET statements quite well.
I can institute a policy of fixing the SET options to be used at the project level, and requiring all devs to place those SET options at the top of each change script to enforce it, since there's no telling until deploy time precisely which change scripts will be applied.
I can patch DBDeploy itself to always use a new connection for each change script, but that would require redesigning the way it handles undoing change scripts.
So what can be done, and what should I do?
Unfortunately I don't believe there's a way to source the current SET status in your connection.
I don't use DBDeploy.NET, but this does sound distinctly like a limitation with the tool. DBDeploy.NET should define within the project metadata (like in Visual Studio DB projects) what the SET predicate defaults should be for any database that it subsequently deploys.
To avoid "bleeding" between scripts, it should automatically add SET statements using those project-level defaults before each script it concatenates into the final script.
Having this kind of deterministic approach means the developers can clear about what state each of these SETs will be in when their script executes. Otherwise, the scripts will be subject to the whims of the various defaults that are present in the SQL client connection or server instance.
I have approximately 100 SQL views that are a variation of this:
select * from RTC.dbo.MyTable
...now I find I need to change the name of the RTC table to something else. Rather than edit one view at a time, is there a way to script out all their drop/create statements to a text file so that I can do a global replacement?
In SSMS right click the database, go to Tasks and select there 'Generate Scripts...'. Select 'Views', select the views you want exported, export.
I'd use PowerShell. If you're not using SQL 2008 Client Tools, install them. Then get the PowerShell client, add the registered snapins (plenty of information out there on how to do that), and then use the directory structure to get to the folder representing your Views.
Then script them using something like:
Get-ChildItems | % {$_.Script()}
Use ScriptOptions to tell it to use an Alter script.
And replace "RTC." with the new database name... and run them using sqlcmd.
PowerShell actually becomes a really nice deployment option too.