astambara ha scritto:

il database sorgente ha tabelle, viste e SP con uno schema diverso da dbo (ereditate dal backup di questa azienda) e sono obbligato a richiamare le procedure mettendo davanti il nome dello schema (dovrei modificare ogni singolo file ASP).

Non è necessario. Tra le proprietà di ogni user c'è la "default schema". Se lo user che accede al database ha la proprietà default schema impostata ad esempio a Pippo, ogni volta che egli fa una query tipo

SELECT campi FROM tabella

SQL Server trasformerà implicitamente la query di cui sopra in

SELECT campi FROM Pippo.tabella

se non esistesse l'oggetto Pippo.tabella allora SQL Server fa un tentativo con

SELECT campi FROM dbo.tabella

e solo se non esiste neanche questo oggetto viene restituito un errore di "oggetto inesistente". Quindi la prima strada che hai è quella di modificare il default schema dello user e avresti già risolto...

vorrei capire come riuscire a cambiare lo schema di tabelle viste e SP.

Puoi trasferire un oggetto da uno schema all'altro con il comando

ALTER SCHEMA schema_di_destinazione TRANSFER schema_di_origine.oggetto

ho provato a creare un nuovo database creando gli script dal vecchio DB, togliendo lo schema e rigenerare tutta la struttura.

Lavoro certosino, ma è la terza strada...

il problema è quando cerco di ripopolare il nuovo DB: da attività -> importa dati di SQLMS non collega i nomi delle tabelle avendo lo schema diverso, dovrei incrociarle una a una (sono migliaia) e creando invece una insert per ogni tabella mi fregano i campi identity.

Non l'avrei fatto così... SSMS, nella versione 2008, permette di generare gli script non solo DDL ma anche quelli di insert into (click con il destro sul DB -> Tasks -> Generate SQL Script). Non so se lo script sospende temporaneamente la proprietà identity (SET IDENTITY INSERT ON) ma al massimo si tratta di aggiungere questa correzione su quelle tabelle che hanno la proprietà identity (solo una tabella alla volta può avere la proprietà impostata). Questa strada comunque pur nella sua fattibilità è la più onerosa rispetto alle altre 2.

dovrei fare lo switching in un week end

Con la prima soluzione (modifica del default schema) ci metti 20 secondi; con la seconda (ALTER SCHEMA) al max 2-3 minuti. Il tuo week end è salvo... :-)

Bye

se non metto il nome dello schema davanti alla SP mi dice
"Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
Impossibile trovare la stored procedure 'lista_responsabili'"

ho creato un nuovo utente per poter modificare il default schema (non mi permetteva di farlo in SA) nella sezione Protezione -> Account di accesso

in mapping utenti ho inserito il default schema del nuovo DB (sezione Mapping Utenti del utente appena creato nella sezione Protezionedell'istanza.

ho dato sysadmin come ruolo al nuovo utente altrimenti non mi dava i permessi per effettuare la connessione al DB.

Nonostante questo vuole ancora il nome dello schema prima della SP....


questo nella pagina ASP

var objRst = Server.CreateObject("ADODB.RecordSet")
var command = Server.CreateObject("ADODB.Command")
command.CommandText = "lista_responsabili"
command.CommandType = adCmdStoredProc
command.Parameters.Append (command.CreateParameter("@id_azienda", adInteger, adParamInput, 3, id_azienda))
command.ActiveConnection = Session("conn_NUOVO_DB")
objRst = command.Execute

nel global.asa

Session("conn_NUOVO_DB") = Server.CreateObject("ADODB.Connection")
Session("conn_NUOVO_DB").ConnectionTimeout = 60
Session("conn_NUOVO_DB").CommandTimeout = 60
Session("conn_NUOVO_DB").Open("DSN=NUOVO_DB;UID=NUOVOUTENTE;PWD=XXXXX;")

a NUOVO_UTENTE ho associato il nuovo schema di default

se invece metto
command.CommandText = "NUOVO_SCHEMA.lista_responsabili"
funziona bene

---

Modificato da astambara il 21 gennaio 2010 14.58 -

l.bianchi ha scritto:

Se si potessero connettere solo i sysadmin sarebbe folle, non trovi? Verifica quello che hai fatto perchè non c'è nessuna logica in quello che scrivi.

per quanto riguarda il sysadmin ho replicato il ruolo che avevano i miei DB nel DB importato, facendo un operazione empirica, senza però considerarla come LA Soluzione.....

ma tornando al problema:
il tuo esempio funziona bene su MSS Management Studio e pure se replicato all'interno del mio DB con i miei schemi, utenti etc.
ma a parte questo non funziona ancora nel mio sito, mentre con la seconda soluzione spostando l'oggetto da uno schema all'altro, ovvero da SCHEMA_DB_IMPORTATO a DBO va alla grande.

propendendo per la seconda soluzione...
domanda: per spostare tutto su dbo esiste un sitema veloce o devo crearmi uno scriptone gigante per tabelle, viste e SP?

---

Modificato da astambara il 21 gennaio 2010 17.00 -

Il cursore puoi popolarlo con questa query

SELECT ROUTINE_NAME
FROM INFORMATION_SCHEMA.ROUTINES
UNION ALL
SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES

(in routines ci sono sia le sp che le udf; in tables ci sono sia le tabelle che le viste).
Per quanto dicevi nel post precedente non è che stai lavorando con questi signori qui

http://community.ugiss.org/blogs/lbianchi/archive/2008/06/26/owner-schema-e-
permessi-su-aruba.aspx

Hai verificato che i permessi siano stati assegnati correttamente?
Altrimenti, visto che hai detto che in SSMS tutto funziona regolarmente non
resta che un errore nel codice.

Bye