Man soll ja nie nie sagen und immer bereit sein, was
Kategorie Allgemein T-SQL
hinzu zu lernen.
Letzte Woche hatte ich so ein Erlebnis
Unsere Enterprise DBA's waren hier und bemerkten, dass wir linked Server in unserer Anwendung "hardcodiert" haben.
So etwa select * from RemoteServer.Database.dbo.Table
der Hinweis, "Es existieren Tools, womit wir das Schema bei einem Umzug automatisiert adaptieren", wurde nicht akzeptiert.
hinzu zu lernen.
Letzte Woche hatte ich so ein Erlebnis
Unsere Enterprise DBA's waren hier und bemerkten, dass wir linked Server in unserer Anwendung "hardcodiert" haben.
So etwa select * from RemoteServer.Database.dbo.Table
der Hinweis, "Es existieren Tools, womit wir das Schema bei einem Umzug automatisiert adaptieren", wurde nicht akzeptiert.
Also ein Beispiel gesucht:
declare @Count int
select @count = count(*) from RemoteServer.Database.dbo.Table
müßte dann ja in etwa wie folgt umgeschrieben werden ->
declare @Count int
declare @RemoteServer varchar(255)
declare @Sql varchar(1024)
set @RemoteServer = 'RemoteServer'
set @Sql = 'select @count = count(*) from ' + @RemoteServer + '.Database.dbo.Table'
Exec(@Sql)
Nur dass dies leider nicht funktioniert, weil man ja in dynamischen SQL keine Chance hat Variablen zu setzen, so dachte ich
Aber es exisitert die Stored Procedure sp_execsql
mit dieser ist es möglich Parameter an ein Dynamic-SQL zu übergeben und auszulesen.
Das Enterprise-Statement sieht dann wie folgt aus:
declare @Count int
declare @RemoteServer varchar(255)
declare @Sql nvarchar(1024)
declare @Param nvarchar(1024)
set @RemoteServer = 'RemoteServer'
set @Sql = 'select @pcount = count(*) from ' + @RemoteServer + '.Database.dbo.Table'
set @Param = 'pcount int OUTPUT'
Execute @Sql,@Param,@pcount = @count OUTPUT
Auch wenn die Ausführungszeit ein wenig langsamer sein sollte, wir reden evtl. von Millisekunden, hat es den Vorteil, dass in den verschiedenen Systemen (Testing, Staging, Produktion) das selbe Datenbank-Schema genutzt werden kann.
Gruß JJR
P.S.: Schade, dass ich hierzu noch keine Quelle gefunden habe, welche "Best Practices" für die Implementierung einer Enterprise-Datenbank enthält.
declare @Count int
select @count = count(*) from RemoteServer.Database.dbo.Table
müßte dann ja in etwa wie folgt umgeschrieben werden ->
declare @Count int
declare @RemoteServer varchar(255)
declare @Sql varchar(1024)
set @RemoteServer = 'RemoteServer'
set @Sql = 'select @count = count(*) from ' + @RemoteServer + '.Database.dbo.Table'
Exec(@Sql)
Nur dass dies leider nicht funktioniert, weil man ja in dynamischen SQL keine Chance hat Variablen zu setzen, so dachte ich
Aber es exisitert die Stored Procedure sp_execsql
mit dieser ist es möglich Parameter an ein Dynamic-SQL zu übergeben und auszulesen.
Das Enterprise-Statement sieht dann wie folgt aus:
declare @Count int
declare @RemoteServer varchar(255)
declare @Sql nvarchar(1024)
declare @Param nvarchar(1024)
set @RemoteServer = 'RemoteServer'
set @Sql = 'select @pcount = count(*) from ' + @RemoteServer + '.Database.dbo.Table'
set @Param = 'pcount int OUTPUT'
Execute @Sql,@Param,@pcount = @count OUTPUT
Auch wenn die Ausführungszeit ein wenig langsamer sein sollte, wir reden evtl. von Millisekunden, hat es den Vorteil, dass in den verschiedenen Systemen (Testing, Staging, Produktion) das selbe Datenbank-Schema genutzt werden kann.
Gruß JJR
P.S.: Schade, dass ich hierzu noch keine Quelle gefunden habe, welche "Best Practices" für die Implementierung einer Enterprise-Datenbank enthält.
| Permalink | 
