Voice of the DBA

Tag: Redgate

  • Setting FK Constraints in Data Modeler

    One of the things a customer asked recently about Redgate Data Modeler was how to set a FK constraint between two tables. The tool seemed to make it easy, but they encountered a few errors. Here is how this worked for me.

    This is part of a series on Redgate Data Modeler.

    Adding a Constraint

    This might make more sense in the video walkthrough, but here’s the text version. I want to add a constraint to my model that links the Organization and User tables shown below. This is a 1 (Organization) to many (User) FK.

    2026-02_0104

    I don’t have a good FK yet in the child table (User), but that’s OK. I’ll click the Add new reference icon in the upper left of the design surface.

    2026-02_0105

    Once I do this, I can click on the Organization table and drag to the User table. That will give me this view. Note that this defaults as a 1:n relationship, so you want to start with the parent. There also is a new “Organization_OrganizationID” column added as a FK.

    2026-02_0106

    That’s not a bad pattern, especially with modern Intellisense, where I don’t need to type everything out. This lets me know where the join should be. However, for many of us, we prefer having something simpler, like OrganizationID as the column in the child.

    If I want to change this, I can look to the right for the Reference Properties. Note the default name below is User_Organization, which I definitely don’t like.

    2026-02_0107

    I can adjust the name to meet my standard, which I’ll do. I can also adjust the FK column, but I’ll need to go to the child table, User, to do this. If I rename that column there, I see this.

    2026-02_0108

    When I click back on the reference, I see this. My change for the FK table is there, but the Primary has defaulted to OrganizationName. Fortunately, there’s a drop down where I can change this.

    2026-02_0109

    Below this, I have other properties. There’s a color (if you care), but also I can set cascading actions. See the drop down below and the options. These can be set for update or delete. There is also the additional property to set this as not for replication.

    2026-02_0112

    Once I do this, the changes are saved. If I generate the SQL script, I can see my FK exists inside the script. You can see the relevant portion below.

    2026-02_0113

    Summary

    Setting accurate FK constraints is an important part of data modeling. I certainly see the reasons why some people don’t like FKs, but if you set them, you want them to be accurate. Redgate Data Modeler supports this, but it’s not as straightforward as I like. Hopefully that changes over time.

    I don’t know that the names matter that much, but in case you are concerned about naming, you can customize this.

    Give Redgate Data Modeler a try and see if it helps you and your team get a handle on your database.

  • Webinar: Navigating the Database Landscape in 2026

    For a number of years, we’ve produced the State of the Database Landscape report, based on surveys and research we do every year. I have found it very interesting to see how people respond and what we learn from the report each year.

    This year is no different, with one change; we’re doing a webinar. Register to hear the advocates talk about navigating the database landscape in 2026. Grant, Kellyn, Pat, and myself are set to sit down and discuss the findings on Feb 18 at 1200pm EST.

    We reviewed the report and now each of us is digging in to those areas we are most interested, and we’ll express our thoughts in the webinar. With over 100 years of database experience between us, we hope you’ll enjoy it.

    And we are ready to take your questions and discuss and debate the future of our industry.

    Register today and I’ll see you on Feb 18.

  • The 2026 Redgate Summit Series

    The last few years, Redgate has run a few Redgate Summits in different places. We’ve done one every year in London and added a few other cities along the way.

    This year, we have 4 scheduled (so far). The schedule is listed here, and I’d love to meet some of you at the events. I always enjoy hearing about people’s challenges as well as their complements and criticisms of our software. I find it invaluable hearing both.

    There may be another one or two coming, with plans up in the air, but we’ll see. Personally I like these events and I’d like to see us add one more in the late summer or fall.

    We run these Summits for customers to better get to know us and become closer partners. We want to meet our customers’ needs and ensure we are approaching our development in a way that helps customers get more value from our tools.

    A few of our tracks are generic, not necessarily related to Redgate, but they are full of topics that we think are important, and we present them based on our knowledge, research, and success. The advocates often run these tracks to bring our expertise to the presentations. We also have a Redgate track, where you can see specific solutions or ask detailed questions of our engineers.

    Hopefully you can join us at one of these events this year (or next year).

  • Monday Monitor Tips: SQL Auditing Preview

    One of the features we advocates have been advocating for is a better way to track security changes in your SQL Server instances. The first slice of this work is in preview (as of 12 Jan 2026) and this post looks at what’s available.

    This is part of a series of posts on Redgate Monitor. Click to see the other posts.

    Tracking Security Changes

    The first iteration of tracking security changes queried instances and databases for information, stored it, and then compared it with other queries to determine what had changed. This was done hourly, and worked well, but it could not determine exactly when a change was made.

    SQL Audit is made to capture this information in a lightweight way This works well, although the tooling (IMHO) is poor and hard to work with. Redgate Monitor is going to overlay this and make it easy for DBAs, InfoSec, and auditors to better understand what is happening in a SQL Server Environment.

    There is a new tab in Redgate Monitor Enterprise Permissions page that contains this data. This is listed as “SQL Audit” and you can see this below.

    2026-01_0105

    Each row in here gives the time of the change, as detected by SQL Audit. If I expand the first column, I can see the details. In this case, we have a regular workload running to change these so that the demo site has data, hence you are likely to see the same data every day on monitor.red-gate.com.

    2026-01_0233

    The last column in the right has the command captured, with PII redacted, as you can see here. The reason you may see only the CREATE LOGIN items and not DROP LOGIN is this first slice of work is just getting the additions, so you can catch those hackers trying to add accounts.

    2026-01_0234

    The SQL Audit documentation page explains how this works, and keep checking this as there is a team enhancing these features on a regular basis and adding more events.

    As with most of the pages in Redgate Monitor, you can filter and customize what data is displayed. You can also export your data as an csv file you can give to others. You have the option to get all data or just filtered data.

    2026-01_0235

    Summary

    This post shows how a new preview feature in Redgate Monitor Enterprise uses SQL Audit to gather data on specific actions that are being taken on your SQL Server instances. This is a useful feature many customers have requested and it is being actively enhanced, so feedback is appreciated.

    If you have feedback, please let us know as we value your opinions and comments on how we shape the future of Redgate Monitor.

    Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.