Database Reference
In-Depth Information
Limitations in SQL Azure
As you've seen so far, creating databases and users requires manual scripting and switching database
connections. The fundamental differences between SQL Server and SQL Azure lie in the basic design
principals of cloud computing, in which performance, ease of use, and scalability must be carefully
balanced. The fact that user databases can be located on different physical servers imposes natural
limitations. In addition, designing applications and services against SQL Azure requires you to have a
strong understanding of these limitations.
Security
Chapter 4 covers security in depth, but the following list summarizes important security considerations
before you deploy your SQL Azure databases. From a security standpoint, you need to consider the
following constraints:
•
Encryption.
Although SQL Azure uses SSL for data transfers, it doesn't support the
data-encryption functions available in SQL Server. However, SQL Azure provides
support for the existing hashing functions.
•
SSPI authentication.
SQL Azure only supports database logins. As a result,
network logins using Security Support Provider Interface (SSPI) aren't supported.
•
Connection constraints.
In certain cases, the database connection is closed for
one of the following reasons:
•
Excessive resource usage
•
Long-running query
•
Long-running single transaction
•
Idle connection
•
Failover due to server failure
•
Disallowed user names.
Certain user names can't be created for security reasons:
•
sa
•
admin
•
administrator
•
guest
•
root
•
Login name.
In certain cases, you may need to append the server name to the
login name to correctly log in, in this format: [loginName]@[servername]. So,
avoid using the arrobas character (@) in login names.
•
TCP port 1433
. Only TCP Port 1433 is allowed. It isn't possible to define another
listening port for SQL Azure.
