Discussion :

[Dschub]

Bonjour,

But:
Je souhaite savoir comment récupérer les informations contenues (nom de colonnes et valeurs) dans la pseudo table 'Inserted' afin de construire une autre requête.

Architecture :
Il y a N bases esclaves et une base Maitre. Les bases esclaves ont toutes le même schéma. La base maître contient des vues qui sont la concaténation des tables des bases esclaves.

Les utilisateurs ne savent pas qu'il y a des bases esclaves et utilisent la base maître pour toutes leurs actions (select, insert, delete, update). Sur chacun de ces trois derniers événements je créé un déclencheur 'instead of' et construit une requête pour la base esclave correspondante.

Problème
Dans le cadre des inserts les utilisateurs ne font pas toujours un insert sur toutes les colonnes de la tables. (ex: insert into ma_table(col_1,col_2) values(val_1,val_2)) Dans ce cas là, je ne peux pas construire ma requête car je n'ai pas les noms des colonnes et donc je ne peux pas récupérer les valeurs (avec select nom_col from inserted)

Avez vous un moyen de récupérer ces informations ou une autre solution pour régler mon problème?

PS : Je sais que le moyen serrai d'utiliser les tables partitionnées mais cette option n'est pas disponible sur SQL Express.

[elsuket]

Bonjour,

la table virtuelle INSERTED a la même structure que l'objet (table ou vue) cible de la modification de données.

Dans le cadre des inserts les utilisateurs ne font pas toujours un insert sur toutes les colonnes de la tables

Je ne comprends plus : suivant ce que vous avez dit, les utilisateurs ne savent pas que les bases escales existent, donc je pars de l'hypothèse que ceux-ci réalisent les modifications toujours sur la vue.

Avez vous un moyen de récupérer ces informations ou une autre solution pour régler mon problème?

Si toutes vos bases ont strictement la même structure de données et que instances qui les hébergent ne sont pas distantes, pourquoi ne pas mettre tous les oeufs dans le même panier ?

La seule façon pour vous, si j'ai bien compris, de connaître la structure des tables cibles est de requêter sys.tables ou INFORMATION_SCHEMA.TABLES.

@++

[Dschub]

Merci beaucoup de votre réponse,

Je ne comprends plus : suivant ce que vous avez dit, les utilisateurs ne savent pas que les bases escales existent, donc je pars de l'hypothèse que ceux-ci réalisent les modifications toujours sur la vue.

Oui, les utilisateurs font toutes les modifications sur les vues.

En fait j'ai pas été très clair dans mes explications. quand mes utilisateurs font des insert sur une tables ils n'insèrent pas forcement des données dans toutes mes colonnes de la table et utilisent la syntaxe insert into table(col1,col2) values(val1,val2).

A ce moment je ne peux pas récupérer mes valeurs dans le pseudo table 'Inserted' car je n'ai pas mes nom de colonne. La seule facon que je connais pour récupérer des information dans cette pseudo table est de faire un select nom_colonne from inserted.

Si toutes vos bases ont strictement la même structure de données et que instances qui les hébergent ne sont pas distantes, pourquoi ne pas mettre tous les oeufs dans le même panier ?

En fait c'est a cause des limitations même de SQL Serveur Express Edition qui ne gère que les bdd inférieures à 4 GO. Je suis en train de mettre en place ce système de base Maitre/esclave pour contourner cette limitation.

La seule façon pour vous, si j'ai bien compris, de connaître la structure des tables cibles est de requêter sys.tables ou INFORMATION_SCHEMA.TABLES.

Justement c'est ce que j'ai essayé de faire mais la pseudo table 'Inserted' n'est pas dans le schéma. Je pense que c'est parqu'elle doit crée a chaque insertion avec un schéma différent dépendant de la requête...

je cherche justement à récupérer ce schéma 'dynamique' à chaque requete

[elsuket]

la pseudo table 'Inserted' n'est pas dans le schéma

Non mais comme je vous l'ai dit elle a strictement la même structure que la table cible de la modification.
Donc il vous suffit de requêter sys.tables ou INFORMATION_SCHEMA.TABLES avec le nom de table cible de la modification.

A mon avis vous perdrez beaucoup moins de d'énergie de temps et d'argent en achetant l'édition Developer de SQL Server qui coûte je crois un peu plus de 40€ ...

@++

[Dschub]

Non mais comme je vous l'ai dit elle a strictement la même structure que la table cible de la modification.
Donc il vous suffit de requêter sys.tables ou INFORMATION_SCHEMA.TABLES avec le nom de table cible de la modification.

Effectivement si je teste méthodiquement tous mes champs de ma table avec le 'is null', j'arrive à identifier mes colonnes ou mon utilisateur fait ses insertions.

A mon avis vous perdrez beaucoup moins de d'énergie de temps et d'argent en achetant l'édition Developer de SQL Server qui coûte je crois un peu plus de 40€ ...

Cette solution à été envisagée par ma société et n'a malheureusement pas été retenue pour des raisons commerciales...

En tout cas merci pour ton aide, qui m'a permis de trouver une solution au problème.

Bonne continuation