Mim

Sql Serveur 2005 SP2 : MIN_ACTIVE_ROWVERSION

Depuis l'arrivée du service Pack 2 de Sql Serveur 2005, est apparue une nouvelle fonction appellée MIN_ACTIVE_ROWVERSION()

Cette fonction permet de renvoyer la prochaine valeur de type Timestamp à insérer dans la base de donnée.
En comparaison avec ce qui se faisait avant le SP2, MIN_ACTIVE_ROWVERSION() correspond à la valeur renvoyée par @@DBTS + 1.

Note : Nous allons travailler avec un type timestamp. Sachez que ce type peut être aussi appellée rowversion. D'ailleurs les deux écritures sql sont correctes

Prenons un exemple : Voici une table contenant une colonne de type timestamp

Create table Person.ClientWithRowVersion (version ROWVERSION)

Insert Into Person.ClientWithRowVersion Values (DEFAULT)
Select * from Person.ClientWithRowVersion

Le résultat est :

(1 row(s) affected) version
---------------------------
0x00000000000007D3

Maintenant effectuons un test sur la valeur renvoyée par MIN_ACTIVE_ROWVERSION() et par @@DBTS

print 'MIN_ACTIVE_ROWVERSION : ' 
print  MIN_ACTIVE_ROWVERSION()
print '@@DBTS'
print @@DBTS
------------------------------------------------------------------
MIN_ACTIVE_ROWVERSION : 
0x00000000000007D4
@@DBTS
0x00000000000007D3

Le résultat attendu est bien correct, MIN_ACTIVE_ROWVERSION() est bien la prochaine valeur insérée et @@DBTS la valeur en cours.

La où cela devient intéressant (et où l'on comprend l'intéret de cette nouvelle fonction) c'est lors de l'ajout d'une transaction dans notre exemple.

Nous allons récupérer les valeurs PENDANT la transaction :

BEGIN TRAN

INSERT INTO Person.ClientWithRowVersion VALUES (DEFAULT)
SELECT * FROM Person.ClientWithRowVersion
GO

PRINT 'MIN_ACTIVE_ROWVERSION'
PRINT MIN_ACTIVE_ROWVERSION() 
PRINT 'DBTS'
PRINT @@DBTS
GO

COMMIT

---------------------------------------
0x00000000000007D5

(1 row(s) affected)

MIN_ACTIVE_ROWVERSION
0x00000000000007D5
DBTS
0x00000000000007D5

Que constatons nous ? Que la valeur de MIN_ACTIVE_ROWVERSION n'a pas été encore mise à jour, alors que celle de DBTS, si .

Là où cette implémentation est judicieuse, c'est lors de l'utilisation de cette fonction lors d'une synchronisation.

L'un des principes lors d'une synchronisation, c'est la récupération des enregistrements de la base de données Source.

Grâce à l'utilisation de MIN_ACTIVE_ROWVERSION() vous êtes sûr de ne récupérer que les enregistrements VALIDES par la base de données, et non des enregistrements en cours de validation et donc potentiellement incorrects...

La prochaine question est donc : Mais comment faire de la synchro ? :)

Stay tuned ;)

VS 2008 : Astuce : WCF Configuration

Pour les chanceux (comme moi) qui ont accés à la RTM de Visual Studio 2008, voici une première astuce, si vous travaillez sur WCF.

Supposons que vous souhaitiez créer un projet classique Windows Forms (dans mon cas, projet supposé jouer le rôle de Host dans une archi WCF) et que vous souhaitiez éditer le fichier de configuration via l'outil WCF Configurator ;, et bien vous risquez d'être supris de ... ne pas voir le menu associé, lors du clic droit sur votre fichier de configuration.

Pour résoudre ce soucis, il vous suffit juste d'appeller le WCF configurator depuis le menu Tools.
Le WCF Configurator va apparaitre (vide). Il ne reste plus qu'à le fermer (si si !).

Une fois cette petite manipulation réalisée, retenter le clic droit sur votre fichier de configuration, et là, Ohhh miracle !

DB PRO : Output et Error List

On me demande souvent pourquoi, avec Visual Studio Team For Database Professionnals (DB PRO pour les intimes) quelques fois les erreurs remontent dans la fenêtre Error List avec de bonne grosses icônes d'erreurs, et des fois dans la fenêtre d'Output, plutôt discrète quant à elle.

Tout simplement, car vous confondez deux choses:

1. La validité de votre syntaxe SQL
2. La validité de votre schéma de base de donnée

Dans le premier cas, le code que vous écrivez, SLQ'ment parlant, est faux, auquel cas DB Pro va générer une "erreur", comme dans l'exemple suivant :

Dans le deuxième cas, votre code, SQL'ment parlant (décidemment !) est valide, mais ce code ne marchera pas car le schéma de base de données est incohérent.

Dans l'exemple suivant, j'essais de faire un Select sur une table qui n'existe pas. Tout ceci est correct au niveau Syntaxe, mais il n'y a aucune chance que cela fonctionne !

Dans ce cas DBPRO, lors de la phase de Build vous avertira de cette "erreur de schéma", car il aura vérifier votre script via sa "Design time validation Database". Effectivement, cette alerte est affichée au niveau de la fenêtre Output, qui est moins "flashy" que nos bonnes vieilles erreures de compilation :)

Note : A vérifier, mais chez moi, j'ai quand même un avertissement dans la fenêtre Error List dans le deuxième cas, je ne sais pas si c'était le cas avant la SR1 de DB PRO. Si quelqu'un a l'info je suis preneur ;)