Update from openrowset va in loop

lunedì 19 novembre 2007 - 16.42

ciccios100 Profilo | Junior Member

Ciao a tutti ragazzi,ho un piccolo problema.Ho bisogno di aggiornare una tabella sql con dei dati presenti in una tabella access,e ho pensato di poterlo fare utilizzando il comando openrowset che ho già utilizzato per popolare una tabella vuota.Ho modificato la select utilizzata precedentemente in questo modo:

Update Anag
SET contatto=U_contatto
FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'c:\Documents and Settings\db1.mdb';
'admin';'',tab)
GO

ma quando lancio la query il management studio express non finisce mai di eseguirela,come mai?ho sbagliato qualcosa nel codice,oppure non posso usare la openrowset per fare un update?e se così fosse come posso fare l'update della tabella SQL?
Grazie !
Ciccio Biagioni

lbenaglia Profilo | Guru

>Update Anag
>SET contatto=U_contatto
>FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
> 'c:\Documents and Settings\db1.mdb';
> 'admin';'',tab)
>GO
>
>ma quando lancio la query il management studio express non finisce
>mai di eseguirela,come mai?ho sbagliato qualcosa nel codice,oppure
>non posso usare la openrowset per fare un update?e se così fosse
>come posso fare l'update della tabella SQL?

Ti sei dimenticato di mettere in relazione le due tabelle:

UPDATE dbo.Anag SET contatto = Q.U_contatto FROM dbo.Anag AS A JOIN OPENROWSET( 'Microsoft.Jet.OLEDB.4.0', 'c:\Documents and Settings\db1.mdb'; 'admin';'',tab ) AS Q ON A.<primary key> = Q.<primary key>;

>Grazie !
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

La query così sostanzialmente funziona,ma ho un problema nel confronto delle chiavi tra le due tabelle:
Messaggio 468, livello 16, stato 9, riga 1
Impossibile risolvere il conflitto tra le regole di confronto "Latin1_General_CI_AS" e "SQL_Latin1_General_CP1_CI_AS" nell'operazione equal to.
Ricordo di aver impostato le regole di confronto nell'installazione di SQL server 05,posso cambiarle adesso e impostarle uguali a quelle di access?
Facendo così dovrei risolvere queso problema vero?
grazie
Ciccio Biagioni

lbenaglia Profilo | Guru

>Messaggio 468, livello 16, stato 9, riga 1
>Impossibile risolvere il conflitto tra le regole di confronto
>"Latin1_General_CI_AS" e "SQL_Latin1_General_CP1_CI_AS" nell'operazione
>equal to.
>Ricordo di aver impostato le regole di confronto nell'installazione
>di SQL server 05,posso cambiarle adesso e impostarle uguali a
>quelle di access?

Secondo me il problema ce l'hai solo a livello di SQL Server. Probabilmente il tuo db ha una collation differente rispetto al server (quindi al tempdb).

La soluzione migliore è quella di allineare le collation del db a quelle del server. Come?
Beh, è un mezzo casino

Con ALTER DATABASE puoi allineare la collation del db, ma sarà valida solo per le NUOVE colonne char e varchar; per quelle esistenti dovrai andare di ALTER TABLE, una colonna alla volta....

>Facendo così dovrei risolvere queso problema vero?
Come ho detto io, si

>grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

Provo a fare l'alter column:

ALTER TABLE [dbo].[Anag] ALTER COLUMN [Code]
[varchar](15) COLLATE Latin1_General_CI_AS NOT NULL

ma il comando non riesce a modificare la colonna in quanto contiene un indice al quale sono legate anche altre tabelle...ecco l'errore che viene generato da SQL SERVER
Messaggio 4922, livello 16, stato 9, riga 2
Impossibile eseguire ALTER TABLE ALTER COLUMN Code perché uno o più oggetti accedono alla colonna.




Ciccio Biagioni

lbenaglia Profilo | Guru

>Provo a fare l'alter column:
>
>ALTER TABLE [dbo].[Anag] ALTER COLUMN [Code]
>[varchar](15) COLLATE Latin1_General_CI_AS NOT NULL
>
>ma il comando non riesce a modificare la colonna in quanto contiene
>un indice al quale sono legate anche altre tabelle...ecco l'errore
>che viene generato da SQL SERVER
>Messaggio 4922, livello 16, stato 9, riga 2
>Impossibile eseguire ALTER TABLE ALTER COLUMN Code perché uno
>o più oggetti accedono alla colonna.

Quindi mi stai confermando che le collation a livello di colonna/db è differente rispetto a quello dell'istanza?

Se la risposta è affermativa per modificare la collation di una colonna devi rimuovere tutti gli indici/constraints eventualmente esistenti e poi ricrearli successivamente.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

>>Quindi mi stai confermando che le collation a livello di colonna/db è differente rispetto a quello dell'istanza?
Penso di si(se creo un nuovo db di default gli viene asseganata la collation "Latin1_General_CI_AS")
>>Se la risposta è affermativa per modificare la collation di una colonna devi rimuovere tutti gli indici/constraints eventualmente
>>esistenti e poi ricrearli successivamente
Non posso,il DB è protetto e non posso eliminare gli indici dalle tabelle....cmq ho risolto copiando quello che mi serviva da access in una nuova tabella di SQL server, e poi ho lanciato un update fra le due tabelle di sql,questa è andata a buon fine...ma quello che mi chiedo è come mai nell'ultima UPDATE non ho avuto nessun problema di regole di confronto anche se le 2 tabelle utilizzano regole di confronto diverse?
Ciccio Biagioni

lbenaglia Profilo | Guru

>Penso di si(se creo un nuovo db di default gli viene asseganata la collation "Latin1_General_CI_AS")

Pensi? Controlla la collation del master con quella del tuo db...

>....cmq ho risolto copiando quello che mi serviva da access
>in una nuova tabella di SQL server, e poi ho lanciato un update
>fra le due tabelle di sql,questa è andata a buon fine...ma quello
>che mi chiedo è come mai nell'ultima UPDATE non ho avuto nessun
>problema di regole di confronto anche se le 2 tabelle utilizzano
>regole di confronto diverse?

Senza ulteriori dati non ti so rispondere.

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

>>Pensi? Controlla la collation del master con quella del tuo db...
La collation del master è:
Latin1_General_CI_AS
La collation del mio db è:
SQL_Latin1_General_CP1_CI_AS
Quindi la risposta è si,ma quello che non mi va giù è che cn una tabella di SQL con collation diversa l'update funziona tranquillamente

Ciccio Biagioni

lbenaglia Profilo | Guru

>>>Pensi? Controlla la collation del master con quella del tuo db...
>La collation del master è:
>Latin1_General_CI_AS
>La collation del mio db è:
>SQL_Latin1_General_CP1_CI_AS
Bene.

>Quindi la risposta è si,ma quello che non mi va giù è che cn
>una tabella di SQL con collation diversa l'update funziona tranquillamente
Occhio, tu hai fatto una INSERT in una NUOVA tabella che non necessita alcun accesso al tempdb; l'UPDATE invece contiene una JOIN che molto probabilmente avrà bisogno di ordinare fisicamente le righe in una tabella temporanea nel tempdb che avrà una collation per le colonne stringa ereditare dall'impostazione del tempdb stesso (ereditata a sua volta dall'istanza), differente rispetto a quella del db che contiene la tabella di destinazione.

Ecco spiegato l'arcano

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

>>Occhio, tu hai fatto una INSERT in una NUOVA tabella che non necessita alcun accesso al tempdb;
Questo è vero, ho fatto un insert in una tabella di appoggio.Poi però ho dovuto aggiornare la tabella finale con un update,che va a prendere i dati dalla tabella d'appoggio.La tabella d'appoggio ha una collation diversa da quella della tabella finale,quindi in teoria mi si doveva presentare la stessa situazione che mi si è presentata quando ho tentato di fare l'update direttamente da access,giusto?Invece no,l'update è riuscito senza ulteriori intoppi(meglio così ),ma perchè?


Ciccio Biagioni

lbenaglia Profilo | Guru

>Questo è vero, ho fatto un insert in una tabella di appoggio.Poi
>però ho dovuto aggiornare la tabella finale con un update,che
>va a prendere i dati dalla tabella d'appoggio.La tabella d'appoggio
>ha una collation diversa da quella della tabella finale,quindi
>in teoria mi si doveva presentare la stessa situazione che mi
>si è presentata quando ho tentato di fare l'update direttamente
>da access,giusto?
Dipende se la JOIN necessita o meno di appoggiarsi al tempdb...

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

ciccios100 Profilo | Junior Member

Quindi mi stai dicendo che molto probabilmente quando si fa un import da elementi esterni(tipo access) ci si appoggia al tmpdb,mentre quando le tabelle sono interne all'istanza no,ed è questa la differenza che in un caso fa generare l'errore e nell'altro no....Ok,lo ricordero!

lbenaglia Profilo | Guru

>Quindi mi stai dicendo che molto probabilmente quando si fa un
>import da elementi esterni(tipo access) ci si appoggia al tmpdb,mentre
>quando le tabelle sono interne all'istanza no,ed è questa la
>differenza che in un caso fa generare l'errore e nell'altro no....Ok,lo
>ricordero!
No, non ho detto questo, semplicemente ho fatto una supposizione in base ai dati che hai postato.
La verifica puoi farla tu stesso confrontando i piani di esecuzione delle due query.

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5