http://www.mssqltips.com/tip.asp?tip=1015

Bumped into this while looking for  IGNORE_DUP_KEY

Also realized you can't put this as part of a table creation unlike SQL Server 2005.

DOWNLOAD

DOWNLOAD

If the user wants a more friendly password I just issue an sp_password to put a more memorable password.

/* To avoid disclosure of passwords, the password is generated in script. */
declare @idx as int
declare @randomPwd as nvarchar(64)
declare @rnd as float
select @idx = 0
select @randomPwd = N''
select @rnd = rand((@@CPU_BUSY % 100) + ((@@IDLE % 100) * 100) +
(DATEPART(ss, GETDATE()) * 10000) + ((cast(DATEPART(ms, GETDATE()) as int) % 100) * 1000000))
while @idx < 64
begin
select @randomPwd = @randomPwd + char((cast((@rnd * 83) as int) + 43))
select @idx = @idx + 1
select @rnd = rand()
end
SELECT CAST(@randomPwd AS NVARCHAR(8))


I would simply search for the column name using the following dictionary query that i wrote.

DECLARE @SearchString VARCHAR(100)
SET @SearchString = 'email'
SELECT
o.id [Object Id]
,o.type
,CASE o.type
WHEN 'C'   THEN 'CHECK CONSTRAINT                    '
WHEN 'D'   THEN 'DEFAULT OR DEFAULT CONSTRAINT       '
WHEN 'F'   THEN 'FOREIGN KEY CONSTRAINT              '
WHEN 'K'   THEN 'PRIMARY KEY OR UNIQUE CONSTRAINT    '
WHEN 'L'   THEN 'LOG                                 '
WHEN 'P'   THEN 'STORED PROCEDURE                    '
WHEN 'R'   THEN 'RULE                                '
WHEN 'RF'  THEN 'REPLICATION FILTER STORED PROCEDURE '
WHEN 'S'   THEN 'SYSTEM TABLE                        '
WHEN 'TR'  THEN 'TRIGGER                             '
WHEN 'U'   THEN 'USER TABLE                          '
WHEN 'V'   THEN 'VIEW                                '
WHEN 'X'   THEN 'EXTENDED STORED PROCEDURE           '
ELSE o.type
END [Object Type]
,o.name [Object Name]
,c.name [Column Name]
,c.colOrder
,t.name [Column Type]
,CASE
WHEN t.xtype IN (175,239,231,167) THEN '('+ CAST(c.length AS VARCHAR) +')'
WHEN t.xtype IN  (106,60,108,59) AND c.scale IS NOT NULL THEN '('+CAST(c.prec AS VARCHAR)+','+ CAST(c.scale AS VARCHAR)+')'
ELSE '' END [Length]
FROM
dbo.sysColumns c WITH(NOLOCK) INNER JOIN
dbo.sysObjects o WITH(NOLOCK) ON (o.id = c.id) INNER JOIN
dbo.sysTypes t WITH(NOLOCK) ON (t.xtype = c.xtype)
WHERE
1 = 1
--AND o.type IN ('P','S','U','V')
--

AND o.type IN ('U')
-- AND c.name  LIKE '%'+@SearchString+'%'
AND ( c.name  LIKE '%'+@SearchString+'%' OR o.name  LIKE '%'+@SearchString+'%')
ORDER BY
o.type, o.name,c.colOrder

/*

WHEN 'C'   THEN 'CHECK CONSTRAINT                    '
WHEN 'D'   THEN 'DEFAULT OR DEFAULT CONSTRAINT       '
WHEN 'F'   THEN 'FOREIGN KEY CONSTRAINT              '
WHEN 'K'   THEN 'PRIMARY KEY OR UNIQUE CONSTRAINT    '
WHEN 'L'   THEN 'LOG                                 '
WHEN 'P'   THEN 'STORED PROCEDURE                    '
WHEN 'R'   THEN 'RULE                                '
WHEN 'RF'  THEN ' REPLICATION FILTER STORED PROCEDURE'
WHEN 'S'   THEN 'SYSTEM TABLE                        '
WHEN 'TR'  THEN ' TRIGGER                            '
WHEN 'U'   THEN 'USER TABLE                          '
WHEN 'V'   THEN 'VIEW                                '
WHEN 'X'   THEN 'EXTENDED STORED PROCEDURE           '

When any exception is raised then @@ERROR will be set to a non zero value. If you want to check whether exception has araised you should check

@@ERROR <>0      -> Exception occurred

@@ERROR =0        -> No Exception

To handle exceptions in sql server 2000 we need to check the condition @@ERROR <>0 for every insert/update/delete statement and based on that we need to roll back the transaction if used.

Example:

BEGIN TRAN

DELETE EMP WHERE EmployeeType = 'ProjectManager'

IF (@@ERROR <>0)

GOTO HandleError;

UPDATE EMP SET Salary = Salary * 1.30, EmployeeType = 'ProjectManager' WHERE EmployeeType = 'TeamLead'

IF (@@ERROR <>0)

GOTO HandleError;

COMMIT TRANS

RETURN;

HandleError:

ROLLBACK TRAN

RETURN;

Public conn As Connection

Posteriormente declaramos una función Pública que contendrá la cadena de conexión a nuestra BD en SQL Server 2000

Public Sub ConectaBD()

Set conn = New ADODB.Connection
conn.CursorLocation = adUseClient
conn.ConnectionString = "Driver={SQL Server};Server=SERVIDOR;Database=BD;Uid=user;Pwd=password;"
conn.Open
End Sub

No SQL Server 2005 temos os novos campos do tipo VAR...(MAX) que vieram aliviar o trabalho de muita gente. Um dos problemas mais comuns na versão anterior (2000) é quando precisamos comparar dados de campos do tipo text ou ntext, aí nos deparamos com um erro do tipo:

Server: Msg 306, Level 16, State 1, Line 1

The text, ntext, and image data types cannot be compared or sorted, except when using IS NULL or LIKE operator.

Eu já vivi essa situação algumas vezes e deixo aqui a forma como tentei resolver (Se tiverem outras sugestões fiquem a vontade para expor, ok?).

(Não fiz testes de perfomance nessa solução, o foco está somente em comparar as colunas tipo text / ntext.)

Imagine que eu tenha duas tabelas:

CREATE TABLE #tb_msg_tela
(id INT IDENTITY(1,1), texto TEXT)

GO

CREATE TABLE #tb_msg_impressao
(id INT IDENTITY(1,1), texto TEXT)

Com os seguintes dados:

INSERT INTO #tb_msg_tela VALUES (NULL)
INSERT INTO #tb_msg_tela VALUES ('Campo text')
INSERT INTO #tb_msg_tela VALUES ('Teste comparação')
INSERT INTO #tb_msg_tela VALUES ('Se caísse para o exterior, para o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?')

INSERT INTO #tb_msg_impressao VALUES ('')
INSERT INTO #tb_msg_impressao VALUES ('Campo text')
INSERT INTO #tb_msg_impressao VALUES ('Teste comparacao')
INSERT INTO #tb_msg_impressao VALUES ('Se caisse para o esterior, p/ o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?')

Observe que existem diferenças em alguns textos (em vermelho).

Para realizar o relacionamento das duas tabelas e encontrar os campos diferentes não podemos simplesmente utilizar:

SELECT * FROM #tb_msg_tela a, #tb_msg_impressao b
WHERE a.id = b.id AND a.texto <> b.texto

Essa consulta retornará um erro porque estamos comparando os campos text utilizando o <>.

Então o primeiro passo é encontrar o maior texto nessa coluna, para isso podemos usar as funções DATALENGHT e MAX:

SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_tela
SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_impressao

O resultado será:

-----------

658

-----------

656

Então sabemos que o maior texto dessa coluna não ultrapassa 700 caracteres, logo, podemos utilizar esse número como apoio no próximo passo, onde utilizaremos a função SUBSTRING:

SELECT
                *
FROM  
                #tb_msg_tela a,
                #tb_msg_impressao b
WHERE
                a.id = b.id
                AND ISNULL(SUBSTRING(a.texto, 0, 700),'') <> ISNULL(SUBSTRING(b.texto, 0, 700),'')

A função ISNULL é importante pois sem ela os campos Nulos serão ignorados.

Veja que a consulta só ira retornar os campos com as diferenças.

É um processo simples, mas que pode dar dor de cabeça por conta das limitações do tipo de dados. Pra quem ta iniciando o desenvolvimento utilizando o SQL Server 2005 a recomendação é: substitua os datatypes ntext, text, image por nvarchar(Max), varchar(Max) e varbinary(Max). Além de outras vantagens, com os novos datatypes não existem as antigas diferenças entre varchar e text.

Error 14274: Cannot delete a job that originated from an MSX server

This error message has two possible causes: either

1. the SQL server is not a standalone server, and this message is appropriate, or
2. the name of the SQL server has changed since the scheduled job was created.

In my case, the scheduled job had been around for over 6 years, and the server had been renamed about 5 years ago.  The job has continued to run and noone needed to make changes to it.

I looked in the sysjobs table in the msdb database and noticed that in the originating_server field, the old server name was still there.  I updated each of them with the following statement:

UPDATE sysjobs SET originating_server='yourNewServerName'

and all was well.

...download here: mssqlserver2000_setup_maintenance

Scope
The scope of this discussion describes if a user wants to move a database resides in MS SQL 2000 to MS SQL 2005 by backing up a database in MS SQL 2000 and restore it in MS SQL 2005. Along with the database backup which specific configurations and settings pertaining to a database, needs to backup and restore, will determined by the user.

Intended Audience
The intended audiences for this discussion are a technical group or a user who is willing to perform this task and having basic knowledge of MS SQL Server.

Moving Database
Moving a particular database from MS SQL 2000 to 2005 can be performed in following two steps.
1. Backup a database from SQL 2000
2. Restore a backup copy into SQL 2005

Let's see one by one.

Backup a database from SQL 2000
Backing up a database can be further divided into two steps.

• Locate a database
• Backup the actual database

Locate a database
To locate a database in SQL 2000 open the enterprise manager by performing following steps

1. Go to Start in the windows OS
2. Select Programs
3. Locate Microsoft Sql Server
4. Once sub menu pops up click on the Enterprise Manager

5. Once Enterprise Manager Window opens, expand the tree and select Databases and then select your application specific database as shown below.

Backup the actual database
To backup the actual database now execute following steps

1. Right click on the database located in the above steps
2. Select All tasks >> Backup database as shown in above image
3. SQL Server backup window will open >> Select Complete in backup
4. For the Destination click on Add button
5. The Destination window will open to give the file name and to decide the location of the backup file. Generally it should be C:\Program Files\Microsoft SQL Server\MSSQL\Backup
6. Click on the button with ellipsis “…” which will open to select the folder and to give a name to the backup file (Here In the image I have selected the default Backup folder path of Sql server)
7. Give the backup file name. Generally it should be <>Give .bak as an extension to the file (All the steps shown below in the image). One can decide its own backup copy name.
8. Click OK twice
9. Select Overwrite option (Whether to append or overwrite)
10. Now on the top select Options tab and check the necessary options for your database
11. Click OK to backup the database
12. Once the message comes which shows the backup operation has been completed successfully, click OK.

Restore backup copy to SQL 2005
Restoring the database can be divided into following steps

• Moving a backup copy
• Open SQL 2005 and Restore

Moving a backup copy
Now we have backup copy of our SQL 2000 database and its time to move it to a server where SQL 2005 has installed or to the desired location from where you can restore the database in SQL 2005. Generally it is recommended to move it to the backup folder of SQL 2005 installation which is by default C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup

Open SQL 2005 and Restore
Follow these steps to open and start restoration

1. Go to Start in the windows OS
2. Select Programs >> Microsoft Sql Server 2005 >> Sql Server Management Studio
3. It may ask the authentication details based on the installation configuration, please provide it
4. Once it connects to the Sql server expand the tree and select Databases
5. Now right click on the Databases and click Restore Database
6. The Restore Database window will open
7. Give the database name by which you want to restore it (Here I have given Northwind Generally it would be same because the connection string in the application refers this name)
8. Select From devices as to locate the source and backup copy
9. Click ellipsis “…” button it will open the window to specify backup
10. Click Add button to specify backup copy and location
11. Select the .bak file as shown in the image
12. Click OK twice

13. Now the in the restore list you can see one row with empty check box
14. Check the box and select the options as shown in the image
15. Check the particular restore options which suites your needs
16. You can change the path of the database to restore at particular location
17. Select one of the Recovery state
18. Click OK and wait for restoration (It may take time based on the size of the database)
19. One green progress bar at the bottom left will show the progress of restoration in %
20. Once it will restore the database it will show you the confirmation message, click OK
21. Now under database tree you can see the Northwind database restored successfully

Users and permissions
Once you restore the database it may require inserting users or giving specific permission to a particular user.
To insert new user specific to a database

1. Expand the database
2. Selects users >> Right click and add new user
3. While creating user you can choose the its role

To insert new user at the SQL server level

1. Select Security folder
2. Select and expand logins >> Double click on particular user and set its role

Potential problems
When a user move the database from 2000 to 2005 user dose not have to write any scripts for if it is doing backup and restore because it will move everything tables, stored procedures, views, user defined functions to 2005.
User need not to write another connection string to connect to Sql 2005.
To insert IIS_WPG user follow these steps

1. Login to Sql 2005
2. Locate the application specific database
3. Expand the database tree node and select security >> Users
4. Right click the Users and click New User
5. Give the name of the user to IIS_WPG

Note : - If user can not found IIS_WPG group while adding as a database user first insert it in the Sql Server security >> logins and then try to add specific to database

6. Click on ellipsis button which will open the Select login window
7. Now use browse button or Advance to locate IIS_WPG group or user and select it
8. Once IIS_WPG is selected give the Schema (application specific Database) and Membership to db_Owner

IIS_WPG is a group not a user and basically it includes following three users

1. NT AUTHORITY\NETWORK SERVICE
2. NT AUTHORITY\SERVICE
3. NT AUTHORITY\SYSTEM

Basically moving database from Sql 2000 to 2005 is wide topic which can’t fit in single discussion but backup and restore is easy to use technique for quick results.

Link which helps to better understand the movement from Sql 2000 to 2005

select DATEDIFF(D, 0, [campoDateTime]) From [Tabella]

But you will get this error message:
Server: Msg 443, Level 16, State 1, Procedure addDay, Line 6
Invalid use of 'getdate' within a function.

So, instead, you should handle it so that you pass non-deterministic values into the function, for example:
CREATE FUNCTION dbo.addDay
(
@dt DATETIME
)
RETURNS DATETIME
AS
BEGIN
SET @dt = DATEADD(DAY, 1, @dt)
RETURN @dt
END

Then you can call it like this:
DECLARE @dt DATETIME
SET @dt = GETDATE() -- or CURRENT_TIMESTAMP
SELECT dbo.addDay(GETDATE())

Another idea is to use OPENQUERY as follows:
CREATE FUNCTION dbo.addDay()
RETURNS DATETIME
AS
BEGIN
DECLARE @dt DATETIME
SELECT @dt = dt + 1
FROM OPENQUERY
(
YourServer,
'SELECT dt = GETDATE()'
)
RETURN @dt
END
GO

If YourServer is not configured for Data Access, you will get this error:
Server: Msg 7411, Level 16, State 1, Procedure addDay, Line 6
Server 'YourServer' is not configured for DATA ACCESS.

You will need to set the local linked server to allow data access in order to accept calls through OPENQUERY. You can do this using sp_serveroption:
EXEC sp_serveroption 'YourServer', 'DATA ACCESS', TRUE

A less efficient (and less accurate) workaround is to use an intermediate view. This simplifies your coding a bit, since you no longer have to pass GETDATE() into the function. First, create the view:
CREATE VIEW dbo.vGETDATE
AS
BEGIN
SELECT vGETDATE = GETDATE()
END

Then, create the function:
CREATE FUNCTION dbo.addDay()
RETURNS DATETIME
AS
BEGIN
DECLARE @dt DATETIME
SELECT @dt = [vgetdate]+1 FROM vGETDATE
RETURN @dt
END

And you can call it like this:
PRINT dbo.addDay()

However, this has been proven to produce inconsistent results, such as this issue that Tibor Karaszi has pointed out:
USE Northwind
GO
CREATE VIEW dbo.vCurrentDateTime
AS
SELECT gd = GETDATE()
GO
CREATE FUNCTION dbo.getFromView()
RETURNS DATETIME
AS
BEGIN
RETURN (SELECT gd FROM vCurrentDateTime)
END
GO
CREATE FUNCTION dbo.getFromSelf()
(
@dt DATETIME
)
RETURNS DATETIME
AS
BEGIN
RETURN @dt
END
GO
DECLARE @dt datetime
SET @dt = GETDATE()
SELECT DISTINCT dbo.getFromView()
FROM Orders o
INNER JOIN [Order Details] od
ON o.OrderId = od.OrderID
SELECT DISTINCT dbo.getFromSelf(@dt)
FROM Orders o
INNER JOIN [Order Details] od
ON o.OrderId = od.OrderID
GO
DROP FUNCTION dbo.getFromView(), dbo.getFromSelf()
DROP VIEW vCurrentDateTime

On my machine, the first query produced anywhere from 8 to 10 rows (and this changed with every refresh), while the second query *always* produced exactly one. This is because using a non-deterministic function within the view leads to GETDATE() being evaluated multiple times as the query runs. Now, this is a contrived example, and is unlikely to resemble anything you're doing in the real world; however, I wanted to include this discrepancy for completeness, and in support of using other methods to getting GETDATE() passed into your function. My preference is to use a local variable and pass it into the function from the calling script...
The difference between a deterministic and non-deterministic function is that the former always produces the same output (given the same input), whereas the latter can produce a different output each time they are called (again, with the same input). This is why system functions like GETDATE() are non-deterministic; they will produce different results each time you call them.

article source

update: here real sample

USE aspg
go
if exists(select name from sysobjects where name='_ufn_Since' and type = 'FN')
drop function dbo._ufn_Since
go
create function dbo._ufn_Since(@today datetime, @fromdate datetime) returns varchar(100)
as
begin
declare @since Nvarchar(100)
select @since = 'С момента регистрации: '+ case when datediff(mi,@fromdate,@today) < 60 then cast(datediff(mi,@fromdate,@today) as varchar ) + ' [мин]'
when datediff(mi,@fromdate,@today) < 1440 then cast(datediff(mi,@fromdate,@today)/60 as varchar ) + ' [час] ' +
cast(datediff(mi,@fromdate,@today)%60 as varchar ) + ' [мин]'
when datediff(mi,@fromdate,@today) > 1440 then cast(datediff(dd,@fromdate,@today) as varchar ) + ' [день] ' +
cast(datediff(hh,@fromdate,@today)%24 as varchar) + ' [час] ' +
cast(datediff(mi,@fromdate,@today)%60 as varchar ) + ' [мин]'
else ''
END
if (@since='') set @since = 'error'
return @since
end
go
select dbo._ufn_Since(getdate(),data) from reg
go

result set looks like as:

С момента регистрации: 48 [день] 5 [час] 39 [мин]
С момента регистрации: 48 [день] 5 [час] 39 [мин]
С момента регистрации: 18 [день] 4 [час] 22 [мин]
С момента регистрации: 18 [день] 4 [час] 5 [мин]
С момента регистрации: 18 [день] 4 [час] 5 [мин]
С момента регистрации: 18 [день] 4 [час] 4 [мин]
С момента регистрации: 7 [день] 3 [час] 57 [мин]
С момента регистрации: 4 [час] 31 [мин]
С момента регистрации: 3 [час] 59 [мин]
С момента регистрации: 3 [час] 13 [мин]

SELECT
BB.*
FROM
(
SELECT TOP 50
AA.*
FROM
(
SELECT TOP 80
*
FROM
Foo.dbo.Bar
ORDER BY
ColonnaA ASC
) AA
ORDER BY AA.ColonnaA DESC
) BB
ORDER BY BB.ColonnaA ASC

M.R.

The content database of SharePoint Portal Server 2003 ends with 1_SITE like Abc1_SITE and for MOSS 2007 the convention is WSS_Content_ (followed by large string of numbers).

In order to take the backup of this database either it is in SQL Server 2000 or SQL Server 2005 follows the steps:

For SQL Server 2000

1.     On your database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.

2.     In SQL Server Enterprise Manager, click the plus sign next to Microsoft SQL Servers.

3.     Click the plus sign next to SQL Server Group.

4.     Click the plus sign next to (local) (Windows NT).

5.     Click the plus sign next to Databases.

6.     Right-click the database you want to back up, point to All Tasks, and then click Backup Database.

7.     In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then in the Backup area, select Database - complete.

8.     In the Destination area, either select an existing destination, or:

a.     Click Add.

b.     In the Select Backup Destination box, select File Name, and then next to the File Name box, click the Browse button.

c.      In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.

d.     Click OK again to close the Select Backup Destination dialog box.

9.     Click OK to start the backup process.

10.    Click OK to acknowledge that the backup process has completed.

Repeat these steps to back up the databases that are used by SharePoint Portal Server 2003 in your environment, except for the configuration and component settings (search) databases.

For SQL Server 2005

1.     On your database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.

2.     In the Connect to Server box, fill in the connection information, and then click Connect.

3.     After connecting to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, click the server name to expand the server tree.

4.     Expand Databases, right-click the database you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

5.     In the Source section, in the Database box, verify the database name.

6.     In the Backup type box, select Full.

7.     Under Backup component, click Database.

8.     In the Name text box, either accept the default backup set name that is suggested or type a different name for the backup set.

9.     In the Destination section, choose the type of backup destination by clicking Disk or Tape, and then select a destination. To create a different destination, click Add.

10.    Click OK to start the backup process.

http://office.microsoft.com/download/afile.aspx?AssetID=AM101638521033

Download: http://www.mediafire.com/?pgxybwmjjnm

Download: http://www.mediafire.com/?441dqnhx2jh

-) SQL Database Tables
Lý thuyết cơ bản:

SQL Data Manipulation Language (DML)
Những ngôn ngữ thao tác dữ liệu :

* SELECT - Hiển thị dữ liệu từ bảng trong CSDL
* UPDATE - Cập nhật dữ liệu vào các bảng trong CSDL
* DELETE - Xóa dữ liệu từ các bảng trong CSDL
* INSERT INTO - Thêm dữ liệu mới vào trong một bảng CSDL
* WHERE - Chỉ rõ đối tượng cần chọn

SQL Data Definition Language (DDL)
Ngôn ngữ định nghĩa dữ liệu :

* CREATE TABLE - Tạo một bảng mới trong CSDL
* ALTER TABLE - Sửa một bảng trong CSDL
* DROP TABLE - Xóa một bảng trong CSDL
* CREATE INDEX - Tạo index (dùng để search key)
* DROP INDEX - Xóa index

Định nghĩa về PRIMARY KEY , FOREIGN KEY và UNIQUE :
(Cái này sẽ gặp trong phần sau)

PRIMARY KEY Constraint :

Một table thường có một hay nhiều cột có giá trị mang tính duy nhất để xác định một hàng bất kỳ trong table. Ta thường gọi là Primary Key và được tạo ra khi ta Create hay Alter một table với Primary Key Constraint.

Một table chỉ có thể có một Primary Key constraint. Có thể có nhiều cột tham gia vào việc tạo nên một Primary Key, các cột này không thể chứa Null và giá trị trong các cột thành viên có thể trùng nhau nhưng giá trị của tất cả các cột tạo nên Primary Key phải mang tính duy nhất.

Còn FOREIGN KEY là gì :

Foreign Key là một cột hay một sự kết hợp của nhiều cột được sử dụng để áp đặt mối liên kết data giữa hai table. Foreign key của một table sẽ giữ giá trị của Primary key của một table khác và chúng ta có thể tạo ra nhiều Foreign key trong một table.

Foreign key có thể reference (tham chiếu) vào Primary Key hay cột có Unique Constraints. Foreign key có thể chứa Null. Mặc dù mục đích chính của Foreign Key Constraint là để kiểm soát data chứa trong table có Foreign key (tức table con) nhưng thực chất nó cũng kiểm soát luôn cả data trong table chứa Primary key (tức table cha). Ví dụ nếu ta delete data trong table cha thì data trong table con trở nên "mồ côi" (orphan) vì không thể reference ngược về table cha. Do đó Foreign Key constraint sẽ đảm bảo điều đó không xảy ra. Nếu bạn muốn delete data trong table cha thì trước hết bạn phải drop hay disable Foreign key trong table con trước.

Các ràng buộc FOREIGN KEY được sử dụng kết hợp với các ràng buộc PRIMARY KEY và UNIQUE nhằm đảm bảo tính toàn vẹn tham chiếu giữa các bảng được chỉ định.

UNIQUE Constraint :

Bạn có thể tạo Unique Constraint để đảm bảo giá trị của một cột nào đó không bị trùng lập. Tuy Unique Constraint và Primary Key Constraint đều đảm bảo tính duy nhất nhưng bạn nên dùng Unique Constraint trong những trường hợp sau:
• Nếu một cột (hay một sự kết hợp giữa nhiều cột) không phải là primary key. Nên nhớ chỉ có một Primary Key Constraint trong một table trong khi ta có thể có nhiều Unique Constraint trên một table.
• Nếu một cột cho phép chứa Null. Unique constraint có thể áp đặt lên một cột chứa giá trị Null trong khi primary key constraint thì không.
Cách tạo ra Unique Constraint cũng tương tự như Primary Key Constraint chỉ việc thay chữ Primary Key thành Unique. SQL Server sẽ tự động tạo ra một non-clustered unique index khi ta tạo một Unique Constraint.

1. Câu lệnh SQL

SQL chuẩn bao gồm 40 câu lệnh. Sau đây là danh sách các câu lệnh thường được sử dụng nhất trong số các câu lệnh SQL

2. Kiểu dữ liệu

Giá trị NULL

Một cơ sở dữ liệu là sự phản ánh của một hệ thống trong thế giới thực, do đó

các giá trị dữ liệu tồn tại trong cơ sở dữ liệu có thể không xác định được. Một giá trị

không xác định được xuất hiện trong cơ sở dữ liệu có thể do một số nguyên nhân sau:

• Giá trị đó có tồn tại nhưng không biết.

• Không xác định được giá trị đó có tồn tại hay không.

• Tại một thời điểm nào đó giá trị chưa có nhưng rồi có thể sẽ có.

• Giá trị bị lỗi do tính toán (tràn số, chia cho không,...)

Những giá trị không xác định được biểu diễn trong cơ sở dữ liệu quan hệ bởi

các giá trị NULL. Đây là giá trị đặc biệt và không nên nhầm lẫn với chuỗi rỗng (đối

với dữ liệu kiểu chuỗi) hay giá trị không (đối với giá trị kiểu số). Giá trị NULL đóng

một vai trò quan trọng trong các cơ sở dữ liệu và hầu hết các hệ quản trị cơ sở dữ liệu

quan hệ hiện nay đều hỗ trợ việc sử dụng giá trị này.

II. NGÔN NGỮ THAO TÁC DỮ LIỆU

1. Truy xuất dữ liệu với câu lệnh SELECT

Cú pháp chung của câu lệnh SELECT có dạng:

Điều cần lưu ý đầu tiên đối với câu lệnh này là các thành phần trong câu lệnh

SELECT nếu được sử dụng phải tuân theo đúng thứ tự như trong cú pháp. Nếu không,

câu lệnh sẽ được xem là không hợp lệ.

Câu lệnh SELECT được sử dụng để tác động lên các bảng dữ liệu và kết quả

của câu lệnh cũng được hiển thị dưới dạng bảng, tức là một tập hợp các dòng và các

cột (ngoại trừ trường hợp sử dụng câu lệnh SELECT với mệnh đề COMPUTE).

2 Bổ sung, cập nhật và xoá dữ liệu

2.1 Bổ sung dữ liệu

• Bổ sung từng dòng dữ liệu với mỗi câu lệnh INSERT. Đây là các sử dụng

thường gặp nhất trong giao tác SQL.

INSERT INTO tên_bảng[(danh_sách_cột)] VALUES(danh_sách_trị)

• Bổ sung nhiều dòng dữ liệu bằng cách truy xuất dữ liệu từ các bảng dữ liệu

khác.

INSERT INTO tên_bảng[(danh_sách_cột)] câu_lệnh_SELECT

2.2 Cập nhật dữ liệu

Câu lệnh này có cú pháp như sau:

2.3 Xoá dữ liệu

Cú pháp :

Trong câu lệnh này, tên của bảng cần xoá dữ liệu được chỉ định sau DELETE FROM.

Mệnh đề WHERE trong câu lệnh được sử dụng để chỉ định điều kiện đối với các dòng

dữ liệu cần xoá. Nếu câu lệnh DELETE không có mệnh đề WHERE thì toàn bộ các

dòng dữ liệu trong bảng đều bị xoá.

Xoá dữ liệu khi điều kiện liên quan đến nhiều bảng

Nếu điều kiện trong câu lệnh DELETE liên quan đến các bảng không phải là

bảng cần xóa dữ liệu, ta phải sử dụng thêm mệnh đề FROM và sau đó là danh sách tên

các bảng đó. Trong trường hợp này, trong mệnh đề WHERE ta chỉ định thêm điều kiện

nối giữa các bảng

III. NGÔN NGỮ ĐỊNH NGHĨA DỮ LIỆU

3.1 Tạo bảng dữ liệu

Câu lệnh CREATE TABLE có cú pháp như sau

Trong đó:

tên_bảng : Tên của bảng cần tạo. Tên phải tuân theo qui tắc định danh và

không được vượt quá 128 ký tự.

tên_cột: là tên của cột (trường) cần định nghĩa, tên cột phải tuân theo

qui tắc định danh và không được trùng nhau trong mỗi một bảng. Mỗi một bảng phải có ít nhất một cột. Nếu bảng có nhiều cột thì định nghĩa của các cột (tên cột, thuộc tính và các ràng buộc) phải phân cách nhau bởi dấu phẩy.

thuộc_tính_cột: Mỗi một cột trong một bảng ngoài tên cột còn có các thuộc tính

bao gồm:

• Kiểu dữ liệu của cột. Đây là thuộc tính bắt buộc phải có đối với mỗi cột.

• Giá trị mặc định của cột: là giá trị được tự động gán cho cột nếu như người sử dụng không nhập dữ liệu cho cột một cách tường minh. Mỗi một cột chỉ có thể

có nhiều nhất một giá trị mặc định.

• Cột có tính chất IDENTITY hay không? tức là giá trị của cột có được tự động tăng mỗi khi có bản ghi mới được bổ sung hay không. Tính chất này chỉ có thể sử

dụng đối với các trường kiểu số.

• Cột có chấp nhận giá trị NULL hay không

các_ràng_buộc:

3.1.1 Ràng buộc CHECK

Ràng buộc CHECK được sử dụng nhằm chỉ định điều kiện hợp lệ đối với dữ

liệu. Mỗi khi có sự thay đổi dữ liệu trên bảng (INSERT, UPDATE), những ràng buộc

này sẽ được sử dụng nhằm kiểm tra xem dữ liệu mới có hợp lệ hay không.

Ràng buộc CHECK được khai báo theo cú pháp như sau:

3.1.2 Ràng buộc PRIMARY KEY

Ràng buộc PRIMARY KEY được sử dụng để định nghĩa khoá chính của bảng.

Khoá chính của một bảng là một hoặc một tập nhiều cột mà giá trị của chúng là duy

nhất trong bảng. Hay nói cách khác, giá trị của khoá chính sẽ giúp cho ta xác định được duy nhất một dòng (bản ghi) trong bảng dữ liệu. Mỗi một bảng chỉ có thể có duy nhất một khoá chính và bản thân khoá chính không chấp nhận giá trị NULL. Ràng buộc PRIMARY KEY là cơ sở cho việc đảm bảo tính toàn vẹn thực thể cũng như toàn vẹn tham chiếu.

Để khai báo một ràng buộc PRIMARY KEY, ta sử dụng cú pháp như sau:

3.1.3 Ràng buộc UNIQUE

Trên một bảng chỉ có thể có nhiều nhất một khóa chính nhưng có thể có nhiều

cột hoặc tập các cột có tính chất như khoá chính, tức là giá trị của chúng là duy nhất

trong bảng. Tập một hoặc nhiều cột có giá trị duy nhất và không được chọn làm khoá

chính được gọi là khoá phụ (khoá dự tuyển) của bảng. Như vậy, một bảng chỉ có nhiều

nhất một khoá chính nhưng có thể có nhiều khoá phụ.

Ràng buộc UNIQUE được sử dụng trong câu lệnh CREATE TABLE để định nghĩa khoá phụ cho bảng và được khai báo theo cú pháp sau đây:

3.1.4 Ràng buộc FOREIGN KEY

Ràng buộc FOREIGN KEY được sử dụng trong định nghĩa bảng dữ liệu nhằm

tạo nên mối quan hệ giữa các bảng trong một cơ sở dữ liệu. Một hay một tập các cột

trong một bảng được gọi là khoá ngoại, tức là có ràng buộc FOREIGN KEY, nếu giá

trị của nó được xác định từ khoá chính (PRIMARY KEY) hoặc khoá phụ (UNIQUE)

của một bảng dữ liệu khác.

Ràng buộc FOREIGN KEY được định nghĩa theo cú pháp dưới đây:

Việc định nghĩa một ràng buộc FOREIGN KEY bao gồm các yếu tố sau:

• Tên cột hoặc danh sách cột của bảng được định nghĩa tham gia vào khoá

ngoài.

• Tên của bảng được tham chiếu bởi khoá ngoài và danh sách các cột được

tham chiếu đến trong bảng tham chiếu.

• Cách thức xử lý đối với các bản ghi trong bảng được định nghĩa trong trường

hợp các bản ghi được tham chiếu trong bảng tham chiếu bị xoá (ON

DELETE) hay cập nhật (ON UPDATE). SQL chuẩn đưa ra 4 cách xử lý:

CASCADE: Tự động xoá (cập nhật) nếu bản ghi được tham chiếu

bị xoá (cập nhật).

NO ACTION: (Mặc định) Nếu bản ghi trong bảng tham chiếu

đang được tham chiếu bởi một bản ghi bất kỳ trong bảng được

định nghĩa thì bàn ghi đó không được phép xoá hoặc cập nhật (đối

với cột được tham chiếu).

SET NULL: Cập nhật lại khoá ngoài của bản ghi thành giá trị

NULL (nếu cột cho phép nhận giá trị NULL).

SET DEFAULT: Cập nhật lại khoá ngoài của bản ghi nhận giá trị

mặc định (nếu cột có qui định giá trị mặc định).

3.2 Sửa đổi định nghĩa bảng

Một bảng sau khi đã được định nghĩa bằng câu lệnh CREATE TABLE có thể

được sửa đổi thông qua câu lệnh ALTER TABLE. Câu lệnh này cho phép chúng ta thực hiện được các thao tác sau:

• Bổ sung một cột vào bảng.