Category Archives: SQL

SQL CROSS JOIN (t-sql)

msdn link

A cross join that does not have a WHERE clause produces the Cartesian product of the tables involved in the join. The size of a Cartesian product result set is the number of rows in the first table multiplied by the number of rows in the second table. The following example shows a Transact-SQL cross join.

However, if a WHERE clause is added, the cross join behaves as an inner join. For example, the following Transact-SQL queries produce the same result set.

Advertisements

Using CROSS APPLY (t-sql)

Using CROSS APPLY (t-sql)
Given:

CREATE FUNCTION dbo.fn_GetTopOrders(@custid AS int, @n AS INT)
RETURNS TABLE
AS
RETURN
SELECT TOP(@n) *
FROM Sales.SalesOrderHeader
WHERE CustomerID = @custid
ORDER BY TotalDue DESC
GO

which returns the top n orders per customerID

SELECT C.CustomerID,
O.SalesOrderID,
O.TotalDue
FROM
AdventureWorks.Sales.Customer AS C
CROSS APPLY
AdventureWorks.dbo.fn_GetTopOrders(C.CustomerID, 3) AS O
ORDER BY
CustomerID ASC, TotalDue DESC

results in this…

CustomerID SalesOrderID TotalDue
———– ———— ———————
1 45283 37643.1378
1 46042 34722.9906
1 44501 26128.8674
2 46976 10184.0774
2 47997 5469.5941
2 57044 4537.8484
3 53616 92196.9738
3 47439 78578.9054
3 48378 56574.3871
4 47658 132199.8023
. . .

The APPLY clause acts like a JOIN without the ON clause comes in two flavors: CROSS and OUTER.
The OUTER APPLY clause returns all the rows on the left side (Customers)
whether they return any rows in the table-valued-function or not (the “LEFT JOIN” table).

The columns that the table-valued-function returns are null if no rows are returned.

The CROSS APPLY only returns rows from the left side (Customers)
if the table-valued-function returns rows.

Notice that I’m just passing in the CustomerID to the function.
It returns the TOP 3 rows based on the amount of the order.

Since I’m using CROSS APPLY a customer without orders won’t appear in the list.
I can also pass in a number other than 3 to easily return a different number of orders per customer.

Even better I can pass in a different number of orders for each customer.
So I could list the top 5 orders for one type of customer but the top 10 for another type of customer.

How cool is that?!?

And it gets even better.
Remember the function has an ORDER BY in it.
It will always return the top orders based on the amount.
However you can change the ORDER BY clause in the query that calls the function to display those rows in whatever order you want.
You could easily display the top 3 orders in ascending order instead.

[SQL] @@Identity, SCOPE_IDENTITY

[SQL] @@Identity, SCOPE_IDENTITY()
msdn link


SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY are similar functions because they return values that are inserted into identity columns.

IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the value generated for a specific table in any session and any scope. For more information, see IDENT_CURRENT (Transact-SQL).

SCOPE_IDENTITY and @@IDENTITY return the last identity values that are generated in any table in the current session. However, SCOPE_IDENTITY returns values inserted only within the current scope; @@IDENTITY is not limited to a specific scope.

For example, there are two tables, T1 and T2, and an INSERT trigger is defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 by the trigger.

Assuming that both T1 and T2 have identity columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1. @@IDENTITY will return the last identity column value inserted across any scope in the current session. This is the value inserted in T2. SCOPE_IDENTITY() will return the IDENTITY value inserted in T1. This was the last insert that occurred in the same scope. The SCOPE_IDENTITY() function will return the null value if the function is invoked before any INSERT statements into an identity column occur in the scope.

Failed statements and transactions can change the current identity for a table and create gaps in the identity column values. The identity value is never rolled back even though the transaction that tried to insert the value into the table is not committed. For example, if an INSERT statement fails because of an IGNORE_DUP_KEY violation, the current identity value for the table is still incremented.

SQL Server Logins and Users

Gleamed from akadia.com

SQL Server Logins and Users
Overview
Although the terms login and user are often used interchangeably, they are very different.

  • A login is used for user authentication
  • A database user account is used for database access and permissions validation.

    Logins are associated to users by the security identifier (SID).
    A login is required for access to the SQL Server server. The process of verifying that a particular login is valid is called “authentication”. This login must be associated to a SQL Server database user. You use the user account to control activities performed in the database. If no user account exists in a database for a specific login, the user that is using that login cannot access the database even though the user may be able to connect to SQL Server. The single exception to this situation is when the database contains the “guest” user account. A login that does not have an associated user account is mapped to the guest user. Conversely, if a database user exists but there is no login associated, the user is not able to log into SQL Server server.

    When a database is restored to a different server it contains a set of users and permissions but there may not be any corresponding logins or the logins may not be associated with the same users. This condition is known as having “orphaned users.”

    Troubleshooting Orphaned Users
    When you restore a database backup to another server, you may experience a problem with orphaned users. The following scenario illustrates the problem and shows how to resolve it.


    Use master
    sp_addlogin ‘test’, ‘password’, ‘Northwind’

    SELECT sid FROM dbo.sysxlogins WHERE name = ‘test’
    0xE5EFF2DB1688C246855B013148882E75


    Grant access to the user you just created
    Use Northwind
    sp_grantdbaccess ‘test’
    SELECT sid FROM dbo.sysusers WHERE name = ‘test’

    0xE5EFF2DB1688C246855B013148882E75

    As you can see, both SID’s are identical.

    Backup the database

    Use master
    BACKUP DATABASE Northwind
    TO DISK = ‘C:\Northwind.bak’

    Copy the Backupfile to another Maschine and SQL Server and restore it as follows:

    RESTORE FILELISTONLY
    FROM DISK = ‘C:\Users\Zahn\Work\Northwind.bak’

    Northwind
    Northwind_log

    RESTORE DATABASE TestDB
    FROM DISK = ‘C:\Users\Zahn\Work\Northwind.bak’
    WITH
     MOVE ‘Northwind’ TO ‘D:\DataMSSQL\Data\northwnd.mdf’,
     MOVE ‘Northwind_log’ TO ‘D:\DataMSSQL\Data\northwnd.ldf’

    The restored database contains a user named "test" without a corresponding login, which results in "test" being orphaned.

    Check the SID's

    Use master
    SELECT sid FROM dbo.sysxlogins WHERE name = ‘test’

    0x39EE98D37EAC2243B7833705EC1C60E3

    Use TestDB
    SELECT sid FROM dbo.sysusers WHERE name =’test’

    0xE5EFF2DB1688C246855B013148882E75

    Now, to detect orphaned users, run this code

    Use TestDB
    sp_change_users_login ‘report’

    test 0xE5EFF2DB1688C246855B013148882E75

    The output lists all the logins, which have a mismatch between the entries in the sysusers system table, of the TestDB database, and the sysxlogins system table in the master database.

    Resolve Orphaned Users

    Use TestDB
    sp_change_users_login ‘update_one’, ‘test’, ‘test’

    SELECT sid FROM dbo.sysusers WHERE name = ‘test’
    0x39EE98D37EAC2243B7833705EC1C60E3

    use master
    SELECT sid FROM dbo.sysxlogins WHERE name =’test’

    0x39EE98D37EAC2243B7833705EC1C60E3

    This relinks the server login “test” with the the TestDB database user “test”.
    The sp_change_users_login stored procedure can also perform an update of all orphaned users with the “auto_fix” parameter but this is not recommended because SQL Server attempts to match logins and users by name.
    For most cases this works; however, if the wrong login is associated with a user, a user may have incorrect permissions.

  • SQL SERVER SET TRANSACTION ISOLATION LEVEL

    Gleamed from MSDN library

    SET TRANSACTION ISOLATION LEVEL

    SQL Server 2000 Controls the default transaction locking behavior for all Microsoft® SQL Server™ SELECT statements issued by a connection.

    Syntax
    SET TRANSACTION ISOLATION LEVEL
    { READ COMMITTED
    | READ UNCOMMITTED
    | REPEATABLE READ
    | SERIALIZABLE
    }

    Arguments

  • READ COMMITTED
    Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

  • READ UNCOMMITTED
    Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels.

  • REPEATABLE READ
    Locks are placed on all data that is used in a query, preventing other users from updating the data, but new phantom rows can be inserted into the data set by another user and are included in later reads in the current transaction. Because concurrency is lower than the default isolation level, use this option only when necessary.

  • SERIALIZABLE
    Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.

    Remarks
    Only one of the options can be set at a time, and it remains set for that connection until it is explicitly changed. This becomes the default behavior unless an optimization option is specified at the table level in the FROM clause of the statement.

    The setting of SET TRANSACTION ISOLATION LEVEL is set at execute or run time and not at parse time.

    Examples
    This example sets the TRANSACTION ISOLATION LEVEL for the session. For each Transact-SQL statement that follows, SQL Server holds all of the shared locks until the end of the transaction.

    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
    GO
    BEGIN TRANSACTION
    SELECT * FROM publishers
    SELECT * FROM authors

    COMMIT TRANSACTION

  • SQL – Simple way to return messages at runtime instead of using PRINT

    Care of David Poole of SQLServerCentral: http://www.sqlservercentral.com/articles/Documentation/72473/

     

     

    RAISERROR ( ‘DATA DICTIONARY: %i tables & %i fields added’, 10, 1,

        @TableCount, @FieldCount ) WITH NOWAIT

    The “10” parameter is the SEVERITY of the error message raised.

    10 : this is more of a notice message, or minor alert

    16 : this is reserved for true error messages

    You can find more via:

    http://msdn.microsoft.com/en-us/library/ms178592.aspx

    INFORMATION_SCHEMA views

     

    Care of http://www.mssqltips.com/tutorial.asp?tutorial=179

    Overview
    The INFORMATION_SCHEMA views allow you to retrieve metadata about the objects within a database.  These views can be found in the master database under Views / System Views and be called from any database in your SQL Server instance.  The reason these were developed was so that they are standard across all database platforms.  In SQL 2005 and SQL 2008 these Information Schema views comply with the ISO standard.

    Following is a list of each of the views that exist.

    • INFORMATION_SCHEMA.CHECK_CONSTRAINTS
    • INFORMATION_SCHEMA.COLUMN_DOMAIN_USAGE
    • INFORMATION_SCHEMA.COLUMN_PRIVILEGES
    • INFORMATION_SCHEMA.COLUMNS
    • INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE
    • INFORMATION_SCHEMA.CONSTRAINT_TABLE_USAGE
    • INFORMATION_SCHEMA.DOMAIN_CONSTRAINTS
    • INFORMATION_SCHEMA.DOMAINS
    • INFORMATION_SCHEMA.KEY_COLUMN_USAGE
    • INFORMATION_SCHEMA.PARAMETERS
    • INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
    • INFORMATION_SCHEMA.ROUTINE_COLUMNS
    • INFORMATION_SCHEMA.ROUTINES
    • INFORMATION_SCHEMA.SCHEMATA
    • INFORMATION_SCHEMA.TABLE_CONSTRAINTS
    • INFORMATION_SCHEMA.TABLE_PRIVILEGES
    • INFORMATION_SCHEMA.TABLES
    • INFORMATION_SCHEMA.VIEW_COLUMN_USAGE
    • INFORMATION_SCHEMA.VIEW_TABLE_USAGE
    • INFORMATION_SCHEMA.VIEWS

    These views can be used from any of your databases.  So if you want to gather data about Tables from the AdventureWorks database you would issue the following in that database.

    USE AdventureWorks
    GO
    SELECT

    *
    FROM
    INFORMATION_SCHEMA.TABLES