Una Stored Procedure è la procedura di un database in grado di eseguire operazioni complesse all'interno del database stesso. È un programma scritto SQL o in altri linguaggi derivanti da SQL, come ad esempio ASP, ASP.NET, Visual Basic o altro.

Secondo le caratteristiche può essere distinta in:

• Funzioni (accettano parametri in entrata/uscita e restituiscono un singolo valore);
• Procedure (accettano parametri in entrata/uscita ma non restituiscono alcun valore);
• Trigger (che sono scatenati da eventi).

L'utilizzo delle Stored Procedure permette di:

• evitare al client di riscrivere query complesse. La procedura viene compilata e archiviata all'interno del database stesso, garantendo un miglioramento delle prestazioni e evitando di scambiare un numero eccessivo di informazioni fra client e server.
• eseguire operazioni complesse che non sarebbero realizzabili utilizzando unicamente query SQL, essendo scritte in versioni proprietarie di SQL e trattandosi quindi di veri e propri linguaggi strutturati.
• mantenere delle librerie di funzioni, utilizzate comunemente all'interno del database stesso.
• eseguire le operazioni richiamando una diversa procedura senza conoscere la struttura di un database o avendone una conoscenza limitata (questo permette all'amministratore di un database il vantaggio di concedere solo il permesso di esecuzione delle Stored Procedure, evitando di assegnare permessi di modifica e/o di lettura).

Comporta un notevole risparmio delle risorse di rete, risparmio direttamente proporzionale alla quantità di codice contenuto nelle Stored Procedure e alla frequenza di invocazione dello stesso.

Se si ottiene il seguente errore eseguendo una query su MSSQL

Errore -2147217900 Specified owner name 'dbo' either does not exist or you do not have permission to use it

l'owner per tutti gli oggetti che creano gli utenti deve essere il nome stesso dell'utente MSSQL: non può essere dbo in quanto gli utenti non hanno i permessi di database owner, che è possibile solo sul proprio server dedicato.

Quindi nell'eseguire una istruzione di questo tipo:

CREATE TABLE [dbo].[tbl_nometabella] ( [col_id] [int] IDENTITY (1, 1) NOT NULL , [col_user] [nvarchar] (20) NOT NULL , [col_cat] [int] NULL , [col_sub] [int] NULL , [col_state] [int] NULL , [col_city] [nvarchar] (50) NULL , [col_key] [nvarchar] (100) NULL , [col_type] [nvarchar] (1) NULL , [col_both] [nvarchar] (1) NULL , [col_min] [money] NULL , [col_max] [money] NULL ,) ON [PRIMARY]GO

è necessario sostituire in CREATE TABLE [dbo].[tbl_nometabella]

l'utente dbo con il proprio utente MSSQL, per esempio MSSql00000 e quindi
CREATE TABLE [MSSql00000].[tbl_nometabella]

In caso di problemi riscontrati nell'esecuzione di script forniti da terzi per l'utilizzo di software gratuiti con l'utilizzo del pannello mssql.aruba.it, è necessario verificare di aver utilizzato gli accorgimenti di seguito descritti, che consentono di evitare problemi per la grandezza dello script e per la gestione dei permessi che Aruba utilizza per gli utenti che acquistano il servizio MSSQL.

Descrizione delle parti che compongono uno script (di solito fornito come file con estensione .sql)

Le parti che compongono uno script sono di solito:

1. la parte iniziale, composta di solito da una serie di istruzioni che servono alla cancellazione delle tabelle che si devono creare nel caso queste esistano già.
   
   Occorre prestare attenzione prima di eseguire la parte perché se i nomi delle tabelle da creare coincidono con tabelle già create, magari con una funzione diversa, si rischia di perdere dati inutilmente.
   
   Il codice è descritto come segue (nell'esempio la tabella da creare si chiama MenuDefinitions):
   
   if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[MenuDefinitions]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) drop table [<UTENTESQL>].[MenuDefinitions] GO
   
   Il proprietario va esplicitamente sostituito con il nome utente sql comunicato da Aruba al momento dell'acquisto del servizio. L'utente [dbo] diventa es [MSSql00000].
   
   Il comando select * from dbo.sysobjects where id = object_id deve rimanere invariato in quanto gli oggetti di sistema secondo il funzionamento di Ms Sql Server hanno obbligatoriamente un accesso in select a livello public (guest). Non si deve mai cambiare l'owner degli oggetti di sistema [dbo] riconoscibili dal suffisso sys.... (sysobjects) poiché si produce l'errore:
   
   Invalid object name 'MSSql00000.sysobjects'
   
   È necessario quindi cambiare dbo soltanto per gli oggetti che devono far parte del proprio database
2. La parte successiva è relativa alla creazione delle tabelle, indici, foreign key, stored procedure etc...
   
   Questa parte è quindi composta per la maggior parte da script di CREATE e ALTER es:
   
   CREATE TABLE [MSSql00000].[ClickLog] (
   [ClickLogId] [int] IDENTITY (1, 1) NOT NULL ,
   [TableName] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
   [ItemId] [int] NOT NULL ,
   [DateTime] [datetime] NOT NULL ,
   [UserId] [int] NULL
   ) ON [PRIMARY]
   GO
   
   ALTER TABLE [MSSql00000].[ClickLog] WITH NOCHECK ADD
   CONSTRAINT [PK_ClickLog] PRIMARY KEY CLUSTERED
   (
   [ClickLogId]
   ) ON [PRIMARY]
   GO
   
   Qui è obbligatorio l'utilizzo del proprietario utente SQL che viene comunicato da Aruba al momento dell'attivazione altrimenti l'esecuzione dei vari comandi fallisce.
3. L'ultima parte é composta da query di insert ,update etc... che servono per inizializzare le varie tabelle con dati es:
   INSERT INTO [MSSql00000].[CodeCountry] ([Code], [Description]) VALUES ('SH', 'St. Helena')
   GO
   INSERT INTO [MSSql00000].[CodeCountry] ([Code], [Description]) VALUES ('SI', 'Slovenia')
   GO
   Anche qui, come del resto sarà fatto nel codice di tutti gli applicativi per qualsiasi comando sql o transact sql eseguito su oggetti del proprio db, è necessario l'utilizzo dell'utente sql al posto di [dbo] altrimenti si cade sull'errore:
   Invalid object name 'dbo.CodeCountry'

Importanza del limite di righe all'interno di uno script:

Data l'interfaccia web ed il linguaggio utilizzato dall'applicativo mssql.aruba.it è necessario, per una corretta esecuzione degli script sql, limitare il numero massimo di righe all'interno di uno script non oltre 7000 7500.
A tal proposito si consiglia di suddividere l'unico file sql in più file di circa 7000 7500 righe.