Discussion :

[Abyssin]

Bonjour !
J'essaie de faire communiquer 2 BDD SQL Server entre elles mais j'ai quelques soucis.
Les 2 bases sont sur 2 serveurs distincts (serveur 1, avec base 1 et l'application, serveur 2 avec base 2). En créant un serveur lié, je peux requeter dans le SQL Server Management en admin, tout se passe bien.
Par contre, je voudrais que les bases communiquent en temps réel pour certaines données/tables.
J'ai donc créé une procédure stockée qui met à jour la base 2 en fonction des infos dans la base 1, et j'appelle celle-ci dans un trigger d'une table de la base 1.
A ce moment j'ai 2 problèmes :
- la session utilisée par l'application et dans la base 1 et serveur 1 doit exister dans le serveur 2 et la base 2 avec le même mot de passe, mais je ne pense pas que ça soit une bonne idée de recréer tous les utilisateurs sur le serveur 2 et je ne sais pas si c'est possible de récupérer les mots de passes
- on ne peut pas utiliser de transaction avec le serveur lié et dans le code de l'application, toutes les procédures sont dans des transactions

Je commence donc à douter que ça soit la bonne méthode.
Sauriez-vous m'aiguiller? Quelle serait la meilleure manière de faire pour avoir 2 BDD qui communiquent en temps réel?
Il est aussi possible que j'ai à faire communiquer la base 2 avec d'autres applications pas sous SQL Server et pas forcément en temps réel. Là je pensais travailler avec des exports de fichier csv ou excel, sauf si vous avez une autre idée plus optimisée?

Merci d'avance pour votre aide !

[SQLpro]

Pour faire ceci vous avez besoin de transaction distribuées.
Ceci implique :
1) définir des transactions explicite avec précision de la distribution des données (BEGIN DISTRIBUTED TRANSACTION)
2) activer le service MSDTC qui est le coordinateur des transactions distribuées
3) faire un commit à deux phases. À me lire : http://blog.developpez.com/sqlpro/p1..._a_deux_phases

Cela dit, c'est catastrophique pour les performances en plus d'être risqué. Mieux vaut un processus asynchrone. Par exemple Service Broker !

A +

[Abyssin]

Merci pour ces infos, je vais me renseigner sur Service Broker alors
Si ma première idée est catastrophique pour les perf, je vais éviter de faire ça.

[SQLpro]

Service broker est le meilleur moyen de faire cela. Lisez le petit article avec la démo minimaliste que j'ai fait :

Offrez-vous le livre de Klaus Aschenbrenner sur le sujet : https://www.apress.com/index.php/aut...r/view/id/3165
Ce sont les meilleurs sources !

A +

[Abyssin]

J'ai commencé à faire quelque-chose en m'inspirant de : http://blog.developpez.com/sqlpro/p7...service_broker
Puis de http://www.atoutfox.org/modules/arti...0000000824.pdf
J'utilise le login AdminBase (qui est db_owner dans mes 2 bases, TEST_SB_1 et bjetest) au lieu de dbo dans le second tutoriel

La procédure que je veux appeler est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
use TEST_SB_1
go
 
create procedure prcTEST
AS
 
if not exists(select * from bjetest..Parametre where NomParametre = 'TEST')
	insert bjetest..Parametre values ('TEST','test')

Mais lorsque j’exécute

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
DECLARE 
	@ScheduledSql nvarchar(max), 
	@RunOn datetime, 
	@IsRepeatable BIT 
 
SELECT 
	@ScheduledSql = N'EXEC [TEST_SB_1].dbo.prcTEST',
	@RunOn = dateadd(s, 3, getdate()), 
	@IsRepeatable = 0
 
EXEC usp_AddScheduledJob @ScheduledSql, @RunOn, @IsRepeatable

J'obtiens l'erreur :

usp_RunScheduledJob: The server principal "AdminBase" is not able to access the database "bjetest" under the current security context.

Je ne comprend pas comment sont gérés les droits, le login utilisé est pourtant bien db_owner.
Si je créé la même procédure stockée sur bjetest et que je l'appelle dans EXEC usp_AddScheduledJob j'ai le même problème.
Et pour l'instant mes 2 bases sont sur le même serveur, j'ai peur de la suite...

edit : La procédure fonctionne si je fais EXEC [bjetest].dbo.prcTEST en étant sur [TEST_SB_1]

Auriez-vous une piste pour me débloquer?
Peut être devrais-je faire un service avec Visual Studio au final?

[SQLpro]

Vous devez éviter tout appel interbase et passer des messages de données (XML) entre serveur via service broker.
De chaque côté vous devez avoir une boucle d'écoute (procédure) qui consomme les messages via la commande RECEIVE.

http://gavindraper.com/2012/06/03/sq...ker-explained/
https://www.simple-talk.com/sql/lear...ons-workbench/

a +