tu veux dire que quand tu te connecte à ton cluster SQL via un fichier DSN la bascule ne fonctionne pas si le node vers lequel le fichier DSN pointait n’est plus disponible ?
mais là je pense que l’on ne parle meme pas du service IMA en tant que tel qui n’arrive pas à basculer car il mentionne qu’avec un user ou system dsn ça passe… et IMA n’aime pas ce genre de DSN
donc les tests ont dû être faits depuis l’outil ODBC de Windoz
Il me semble que dans ce type de config sql en miroir (log shapping), la table de connexion des n’est pas partagé entre les serveurs, il semblerait logique que ima ai le besoin de relancer sa connexion à la DS.
Pour le vérifier, faudrait faire le test avec un client sql qui conserve la connexion et pas avec un simple test de dsn…
tu veux dire que quand tu te connecte à ton cluster SQL via un fichier DSN la bascule ne fonctionne pas si le node vers lequel le fichier DSN pointait n'est plus disponible ?
Tout à fait... Le support MS a reproduit le problème et travaille dessus...
Il me semble que dans ce type de config sql en miroir (log shapping), la table de connexion des n'est pas partagé entre les serveurs, il semblerait logique que ima ai le besoin de relancer sa connexion à la DS.
Pour l'instant ce n'est même pas au niveau d'ima que le problème se passe on en est encore à valider le bon fonctionnement de la bascule automatique avec un fichier DSN...
tu veux dire que quand tu te connecte à ton cluster SQL via un fichier DSN la bascule ne fonctionne pas si le node vers lequel le fichier DSN pointait n'est plus disponible ?
Tout à fait... Le support MS a reproduit le problème et travaille dessus...
Il me semble que dans ce type de config sql en miroir (log shapping), la table de connexion des n'est pas partagé entre les serveurs, il semblerait logique que ima ai le besoin de relancer sa connexion à la DS.
Pour l'instant ce n'est même pas au niveau d'ima que le problème se passe on en est encore à valider le bon fonctionnement de la bascule automatique avec un fichier DSN...
Pour m'être amusé avec de la réplication sql via du double take, est-ce que la partie service spn dans l'ad est good ?
Pour m'être amusé avec de la réplication sql via du double take, est-ce que la partie service spn dans l'ad est good ?
Ca semble bon de ce côté la, merci...
Le support MS nous a fait faire quelques traces SQL et réseau et pour l'instant pas de news... Si on a rien lundi, on contactera le TAM pour débloquer la situation...
Juste pour info, le retour du support MS : Bug dans le odbcad32 qui ne gère pas bien le failover. Si on test avec un “vrai” environnement Citrix : cela fonctionne…