If you read the Microsoft White Paper on SQL Server 2019, there’s a gem buried on page 17. It mentions a trace flag, which some of you might appreciate.
Here’s a little repro:
As you can see, the plee I made has actually been heard. I don’t know if they listened to me, or if the collective complaints over the year grew to the point that this got fixed.
In any case, thank you, Microsoft. This is a very nice enhancement.
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
I haven’t had the need to move an object from one schema to another in years. Really since SQL Server 2000. I wrote about deleting a user that owns a schema recently, but that’s often a first step. The next thing I might need to do is actually move objects from that schema to a new one.
I actually ran across this command when I was looking how to move the schema to a new user. There’s actually a parameter for ALTER SCHEMA that will move objects. This is the TRANSFER argument and it works like this.
I need a new schema for the object. In this case, I’ve got a table called SallyDev.Class. I want to move this to a new schema, and I’ll choose dbo for this example. I often have had developers build in their own schema and then I’ll transfer to the dbo schema, which is almost like a merge of code from one branch (SallyDev) to another (dbo).
The format of the command is: ALTER SCHEMA <newschema> TRANSFER <object>
The new schema name is just the name, with brackets if needed. Hint, if you need brackets, rename your schema, please.
The object is the qualified name of the object, with the old schema. In this case, the command I’ll use is:
ALTER SCHEMA dbo TRANSFER SallyDev.Class
Here’s my before look:
When I run the code, it works:
Now my object is moved. Success!
This is a quick view of a specific skill that can be handy. I won’t use this often, but if my team worked in this flow, or we had an issue, this not only shows how to resolve a single item move, but also helps me remember the command. I hadn’t seen this before, so a quick 10 minute blog is useful.
This also gives me ideas for other blogs, like how to automate this for a number of objects.
I’m off in the UK and buried with other work, so a republish today.
Since I took over the T-SQL Tuesday a few months ago, I decided I ought to host again. Especially since I’ve done it twice, but Wayne Sheffield got his third spot last month. Gotta keep up with Mr. Sheffield.
I’ve been working with SQL Server and T-SQL a long time, and across many jobs, I think I’ve ended up using triggers in 0.01% of my tables or less. They can be a useful and helpful construct, but they can also be problematic and difficult, especially in the age of changing business models and rules.
Since I’ve found triggers to be both helpful and hurtful, I decided to ask you to write about an experience you’ve had with triggers. Either good or bad, but let me know this month what stands out in your mind.
As always, the rules for this month are simple.
Voice of the DBA 