Modification de XSD ConnectionString au moment de l'exécution pour une application multi-locataires

Question

Je modifie notre application à partir d'un & amp; jeu de code & amp; une base de données " vers "un ensemble de code vers plusieurs bases de données (une base de données par client)".

Le code d'origine est VS2005 ASP.NET (VB) & amp; beaucoup de XSD dans une DLL séparée. ConnectionString de web.config remplacerait celui stocké dans la DLL lors de l'exécution.

Maintenant, je dois changer le ConnectionString chaque fois que je déclare un adaptateur / un ensemble de données / une table de données, car l'appel pourrait être dirigé vers une base de données différente du dernier appel.

Quelqu'un a-t-il des indices à ce sujet?

Answer 1

Après quelques recherches, il semble qu'un XSD ait une propriété appelée ConnectionModifier.

Pour le trouver, sur votre diagramme XSD, cliquez sur la partie TableAdapter du diagramme (où les requêtes sont définies).

Dans la fenêtre des propriétés, définissez ConnectionModifier sur Public et cliquez sur Enregistrer. (Cela semble également modifier la propriété de tous les jeux de données de cette page.)

De retour dans le code principal de votre site, vous pouvez maintenant faire quelque chose comme ceci:

'declare the adapter as normal
Dim AdapterTest As New DataSetTestTableAdapters.TestTableAdapter

'pass the new connection object into the now visible property
AdapterTest.Connection = New Data.SqlClient.SqlConnection("Data Source=Myserver;Initial Catalog=TEST;Integrated Security=True;")

Cela ne prend qu'un objet de connexion.

Je n'ai pas encore testé cela correctement! Malheureusement, un nouvel objet de connexion devra être passé chaque fois que vous déclarez quelque chose d'un XSD.

Answer 2

Nous avons également constaté que, bien que la propriété mentionnée (ConnectionModifier) ??soit publique, elle ne peut toujours pas être vue via le code s’il s’agit d’un QueriesTableAdapter. Je devais donc passer un bon moment à les supprimer et à les remplacer par un message "Using Query" normal. bloquer.

De plus, je suis sûr que le projet semble plus rapide maintenant. Il peut s’agir de la réduction de taille ou de l’utilisation de & Using; Using " avec tous les appels maintenant (le code original était au début de nos jours .NET donc aurait pu être mieux écrit en premier lieu).