Specifiche per l’importazione di script forniti da terze parti

L’utilizzo di script forniti da terzi per l’utilizzo di software gratuito e’ diventato sempre piu’ diffuso.

A questo proposito di seguito vengono descritti una serie di accorgimenti che possono far risparmiare tempo in caso di problemi riscontrati nell’esecuzione di questi ultimi con l’utilizzo del pannello mssql.aruba.it.

In particolare questi suggerimenti evitano problemi per la grandezza dello script e per la gestione dei permessi che aruba utilizza per gli utenti che acquistano il servizio MS Sql Server.

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

Le parti che compongono uno script sono di solito 3:

1
La parte iniziale e’ composta di solito da una serie di istruzioni che servono alla cancellazione delle tabelle che si devono creare nel caso queste esistano gia’.

E’ la parte che se il database e’ vuoto si potrebbe tranquillamente omettere. In ogni caso  occorre far attenzione prima di eseguire tale parte perche’ se i nomi delle tabelle da creare coincidono con tabelle gia' create, che magari hanno una funzione diversa, si rischia di perdere i dati inutilmente.

Il codice e’ 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

E’ da notare il fatto che il proprietario come descritto nell’articolo collegato deve essere esplicitamente sostituito con il nome utente sql che vi e’ stato comunicato da aruba quindi l’utente [dbo] diventa es [MSSql10059].

Notare anche il fatto che 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).
Quindi non cambiate mai l’owner degli oggetti di sistema [dbo] riconoscibili dal suffisso sys.... (sysobjects) in quanto la conseguenza e’ l’errore

Invalid object name ‘MSSql10059.sysobjects'

E’ necessario quindi cambiare dbo soltanto per gli oggetti che devono far parte del prorio database

2
La parte successiva e’ relativa alla creazione delle tabelle, indici, foreign key, stored procedure etc...

Questa parte e’ quindi composta per la maggior parte da script di CREATE e ALTER es:

CREATE TABLE [MSSql10059].[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 [MSSql10059].[ClickLog] WITH NOCHECK ADD
 CONSTRAINT [PK_ClickLog] PRIMARY KEY  CLUSTERED
 (
  [ClickLogId]
 )  ON [PRIMARY]
GO

Qui e’ obbligatorio l’utilizzo del proprietario utente sql che viene comunicato da aruba al momento dell’attivazione altrimenti l’esecuzione dei vari comandi fallisce. Se lasciamo infatti invariatoil codice con [dbo] otteniamo l’errore:

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

3
L’ultima parte di solito e’ composta da query di insert ,update etc... che servono per inizializzare le varie tabelle con dati es:
INSERT INTO [MSSql10059].[CodeCountry] ([Code], [Description]) VALUES ('SH', 'St. Helena')
GO
INSERT INTO [MSSql10059].[CodeCountry] ([Code], [Description]) VALUES ('SI', 'Slovenia')
GO
Anche qui, come del resto sara’ fatto nel codice di tutti gli applicativi per qualsiasi comando sql o transact sql eseguito su oggetti del proprio db, e’ 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 e’ 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 piu’ file di circa 7000 7500 righe.