You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
4. In the **Database Details** section, type or select the following values:
35
+
5. In the **Database Details** section, type or select the following values:
35
36
36
37
-**Database name**: Enter `mySampleDatabase`.
37
38
-**Server**: Select **Create new**, enter the following values and then select **Select**.
@@ -58,18 +59,22 @@ Create your resource group and single database using the Azure portal.
58
59
- Optionally, you can also select **Change configuration** to change the hardware generation.
59
60
- Select **Apply**.
60
61
61
-
5. Select the **Additional settings** tab.
62
-
6. In the **Data source** section, under **Use existing data**, select `Sample`.
62
+
6. Select the **Networking** tab and decide if you want to [**Allow Azure services and resources to access this server**](../sql-database-networkaccess-overview.md), or add a [private endpoint](../../private-link/private-endpoint-overview.md).
8. In the **Data source** section, under **Use existing data**, select `Sample`.
63
68
64
69

65
70
66
71
> [!IMPORTANT]
67
72
> Make sure to select the **Sample (AdventureWorksLT)** data so you can follow easily this and other Azure SQL Database quickstarts that use this data.
68
73
69
-
7. Leave the rest of the values as default and select **Review + Create** at the bottom of the form.
70
-
8. Review the final settings and select **Create**.
74
+
9. Leave the rest of the values as default and select **Review + Create** at the bottom of the form.
75
+
10. Review the final settings and select **Create**.
71
76
72
-
9. On the **SQL Database** form, select **Create** to deploy and provision the resource group, server, and database.
77
+
11. On the **SQL Database** form, select **Create** to deploy and provision the resource group, server, and database.
Copy file name to clipboardExpand all lines: articles/sql-database/sql-database-networkaccess-overview.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -109,7 +109,7 @@ Be aware of the following Azure Networking terms as you explore Virtual Network
109
109
110
110
**Subnet:** A virtual network contains **subnets**. Any Azure virtual machines (VMs) that you have are assigned to subnets. One subnet can contain multiple VMs or other compute nodes. Compute nodes that are outside of your virtual network cannot access your virtual network unless you configure your security to allow access.
111
111
112
-
**Virtual Network service endpoint:** A [Virtual Network service endpoint][vm-virtual-network-service-endpoints-overview-649d] is a subnet whose property values include one or more formal Azure service type names. In this article we are interested in the type name of **Microsoft.Sql**, which refers to the Azure service named SQL Database.
112
+
**Virtual Network service endpoint:** A [Virtual Network service endpoint](../virtual-network/virtual-network-service-endpoints-overview.md) is a subnet whose property values include one or more formal Azure service type names. In this article we are interested in the type name of **Microsoft.Sql**, which refers to the Azure service named SQL Database.
113
113
114
114
**Virtual network rule:** A virtual network rule for your SQL Database server is a subnet that is listed in the access control list (ACL) of your SQL Database server. To be in the ACL for your SQL Database, the subnet must contain the **Microsoft.Sql** type name. A virtual network rule tells your SQL Database server to accept communications from every node that is on the subnet.
115
115
@@ -118,7 +118,7 @@ Be aware of the following Azure Networking terms as you explore Virtual Network
118
118
119
119
The Azure SQL Server firewall allows you to specify IP address ranges from which communications are accepted into SQL Database. This approach is fine for stable IP addresses that are outside the Azure private network. However, virtual machines (VMs) within the Azure private network are configured with *dynamic* IP addresses. Dynamic IP addresses can change when your VM is restarted and in turn invalidate the IP-based firewall rule. It would be folly to specify a dynamic IP address in a firewall rule, in a production environment.
120
120
121
-
You can work around this limitation by obtaining a *static* IP address for your VM. For details, see [Configure private IP addresses for a virtual machine by using the Azure portal][vm-configure-private-ip-addresses-for-a-virtual-machine-using-the-azure-portal-321w].However, the static IP approach can become difficult to manage, and it is costly when done at scale.
121
+
You can work around this limitation by obtaining a *static* IP address for your VM. For details, see [Configure private IP addresses for a virtual machine by using the Azure portal](../virtual-network/virtual-networks-static-private-ip-arm-pportal.md). However, the static IP approach can become difficult to manage, and it is costly when done at scale.
122
122
123
123
Virtual network rules are easier alternative to establish and to manage access from a specific subnet that contains your VMs.
0 commit comments