Especificaciones para la importación de scripts suministrados por terceras partes

La utilización de scripts suministrados por terceros para la utilización de software gratuito se haría siempre más difusa.

Para este propósito a continuación vienen descritos una serie de agudezas que pueden hacer ahorrar tiempo en caso de problemas encontrados en la ejecución de estos últimos con la utilización del panel mssql.aruba.it.

 

En particular estas sugerencias evitan problemas por la grandeza del script y por la gestión de los permisos que Aruba utiliza para los usuarios que adquieren el servicio MS Sql Server.

Descripción de las partes que componen un script (normalmente suministrados como archivos con extensión .sql)

Las partes que componen un script son normalmente 3:

1
La parte inicial está compuesta normalmente por una serie de instrucciones que sirven para la cancelación de las tablas que se deben crear en el caso de que estas existan ya.

Es la parte que, si la base de datos está vacía, se podría tranquilamente omitir. En cada caso necesita prestar atención antes de ejecutar tales partes porque si los nombres de las tablas a crear coinciden con tablas ya creadas, que quizás tengan una función diferente, se arriesga a perder los datos inútilmente.

El código está descrito como sigue (en el ejemplo la tabla a crear se llama  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

Se debe tomar nota del hecho de que el titular como está descrito en el artículo relacionado debe ser explícitamente sustituido con el nombre de usuario sql que le ha sido comunicado por Aruba luego el usuario [dbo] será [MSSql10059].

Note también el hecho de que el comando select * from dbo.sysobjects where id = object_id debe permanecer invariado en cuanto a los objetos de sistema según el funcionamiento  de  Ms Sql Server tiene obligatoriamente un acceso en select a nivel public (guest).
Luego no cambie nunca el titular de los objetos de sistema [dbo] reconocibles por el sufijo sys.... (sysobjects) en cuanto a que la consecuencia es el error

Invalid object name ‘MSSql10059.sysobjects'

Es necesario luego cambiar dbo solamente para los objetos que deben hacer parte de la propia base de datos

2
La parte sucesiva es relativa a la creación de las tablas, índices, foreign key, stored procedure, etc…

Esta parte está luego compuesta por la mayor parte de los scripts de CREATE y 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

Aquí es obligatoria la utilización del titular usuario sql que le es comunicado por Aruba en el momento de la activación, de otra manera la ejecución de los varios comandos fallan. Si dejamos, en efecto, invariado el código con [dbo] obtendremos el error:

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

3
La última parte normalmente está compuesta por query de insert, update etc... que sirven para inicializar las varias tablas con datos como:
INSERT INTO [MSSql10059].[CodeCountry] ([Code], [Description]) VALUES ('SH', 'St. Helena')
GO
INSERT INTO [MSSql10059].[CodeCountry] ([Code], [Description]) VALUES ('SI', 'Slovenia')
GO
También aquí, como del resto se hará en el código de todas las aplicaciones por cualquier comando sql o transact sql ejecutado sobre objetos de la propia base de datos, es necesario la utilización del usuario sql en el sitio de [dbo] de otra manera se cae en el error:
Invalid object name 'dbo.CodeCountry'

Importancia del límite de líneas en el interior de un script:

Según la interfaz web y el lenguaje utilizado desde la aplicación mssql.aruba.it, es necesario para una correcta ejecución de los scripts sql limitar el número máximo de líneas en el interior de un script, máximo 7000 7500.

Para tal propósito se aconseja de subdividir el único archivo sql en más de casi 7000 7500 líneas.