Discussion :

[DEV-10]

Bonjour

J'ai un dataset et j'utilise TableAdapter.Update lorsque je veux le sauvegarder sur la table de la bases de données.

Je travaille avec SQL server 2005.

Est-ce qu'il y a une autre façon plus sécuritaires de faire les choses au lieu d'utiliser la méthode Update de l'objet TableAdapter ?

Merci de votre aide

[Nathanael Marchand]

Sécuritaire?

[DEV-10]

Sécuritaire?

Oui je dis sécuritaire, parce que d'habitude on fait la mise à jour en appelant une procédure stocké qui contient à l'intérieur des droits d'accès.

Maintenant je ne sais comment la méthode Update de l'objet TableAdapter fait son travail.

Y a t-il moyen de le savoir ?

Qu'est ce que tu en penses ?

Merci.

[Nathanael Marchand]

Tu peux passer par des commandes SQL traditionnelles:
http://msdn.microsoft.com/en-us/libr...qlcommand.aspx
Ou surement définir le SQL qui fait la requête de mise à jour (ne travaillant jamais avec des TableAdapter, je ne pourrais confirmer).

[DEV-10]

Tu peux passer par des commandes SQL traditionnelles:
http://msdn.microsoft.com/en-us/libr...qlcommand.aspx
Ou surement définir le SQL qui fait la requête de mise à jour (ne travaillant jamais avec des TableAdapter, je ne pourrais confirmer).

La raison est que des fois on peut faire 36 modifications dans le datagrid et si j'appelle la procedure stockée qui contient l'enonçé Update ...SET ...

il va faloir rajouter plusieurs conditions where pour enveloppé les 36 changements qu'on vient de faire sur le DataGrid.

C'est pour cela que j'aimerais savoir s'il y a d'autres façons pour le faire.

Puisque tu ne travaille pas avec les dataadapter, est-ce que tu fais tes sauvegardes avec du code sql (statement Update ... set...) ?

si oui, comment tu fais lorsque il y a plusieurs changements dans le datagrid ?

Merci.

[Nathanael Marchand]

Je travaille généralement avec des ORM (comme NHibernate et Entity Framework) le problème est donc assez différent.
Mais typiquement ce qu'il faut faire c'est ligne par ligne updater tous les champs sauf ceux d'identité qui servent de discriminant (clause WHERE de l'update).

[Graffito]

Code :

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

comment tu fais lorsque il y a plusieurs changements dans le datagrid ?

D'une façon générale, je fais les update+acceptChanges à chaque insert, update ou delete.

Dans les cas où on a plusieurs modifications, j'englobe l' Adapter.Update (ou les Adapter.Update si on gère des modifs sur plusieurs tables) dans une transaction et suivant le résultat AcceptChanges ou RejectChanges.

[DEV-10]

Code :

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

comment tu fais lorsque il y a plusieurs changements dans le datagrid ?

D'une façon générale, je fais les update+acceptChanges à chaque insert, update ou delete.

Dans les cas où on a plusieurs modifications, j'englobe l' Adapter.Update (ou les Adapter.Update si on gère des modifs sur plusieurs tables) dans une transaction et suivant le résultat AcceptChanges ou RejectChanges.

Merci pour ces détails.

Je m'explique

Les clients qui vont utiliser l'application, leur compte n'a pas accès à modifier les donnes dans les Tables, ilspeuvent juste executé les procédures stockées.

Alors dans le code VB on rajoute l'appel à une procedure stockée, et dans le code de cette procédure stockée on rajoute un autre appel à une autre procédure stockée qui cette dernière va donner la permission pour pouvoir changer les donnes des tables.

Question : Est-ce possible de rentrer dans les propriétes de l'objet TableAdapter et lui donner la permission de changer les données des tables même si le client utilisateur n'a pas droit de faire des update sur les tables.

En quelque sorte, on va rajouter une clé de sécurité dans le lancement du DataAdapter.

Comme par exemple ajouter un appel d'une procedure stockée (qui assure notre sécurité) dans le code du mondataset.designer.vb

Je sais que ce n'est pas facile à expliquer mais je suis ici pour tout autre détail que vous vous voulez savoir.

Merci.

[iberserk]

D'une façon générale, je fais les update+acceptChanges à chaque insert, update ou delete.

Sauf erreur de ma part vous ne pouvez faire autrement...
Dommage que vous n'ayez pas SQL SERVER 2008... vous auriez pu tenter l'approche par Table Valued Parameters

Alors dans le code VB on rajoute l'appel à une procedure stockée, et dans le code de cette procédure stockée on rajoute un autre appel à une autre procédure stockée qui cette dernière va donner la permission pour pouvoir changer les donnes des tables.

C'est bien compliqué tout ça... vos droits sont gérés au niveau des objets/authorization de la base de données?

[DEV-10]

C'est bien compliqué tout ça... vos droits sont gérés au niveau des objets/authorization de la base de données?

Oui . Les clients ont droit "exec" sur les procédures stockées.

[Bluedeep]

Les clients qui vont utiliser l'application, leur compte n'a pas accès à modifier les donnes dans les Tables, ilspeuvent juste executé les procédures stockées.

Alors dans le code VB on rajoute l'appel à une procedure stockée, et dans le code de cette procédure stockée on rajoute un autre appel à une autre procédure stockée qui cette dernière va donner la permission pour pouvoir changer les donnes des tables.

Question : Est-ce possible de rentrer dans les propriétes de l'objet TableAdapter et lui donner la permission de changer les données des tables même si le client utilisateur n'a pas droit de faire des update sur les tables.

A la base, il y a quelque chose que je ne comprends pas dans cette démarche; en effet,une approche de sécurité a été choisie (pas forcément la meilleure mais admettons) qui consiste à limiter l'interaction des clients avec la base en n'autorisant que l'exécution des proc stoc; ok, pourquoi pas.

Mais dans ce cas, pourquoi ne pas coder l'application en utilisant exclusibvment des accès aux procédures stockées ?

La problèmatique soulevée parait relever d'une sorte de logique Shadok dont je ne comprends pas la finalité.

[DEV-10]

A la base, il y a quelque chose que je ne comprends pas dans cette démarche; en effet,une approche de sécurité a été choisie (pas forcément la meilleure mais admettons) qui consiste à limiter l'interaction des clients avec la base en n'autorisant que l'exécution des proc stoc; ok, pourquoi pas..

Est-ce que vous connaissez une autre façon qui est plus sécuritaire ?

Mais dans ce cas, pourquoi ne pas coder l'application en utilisant exclusibvment des accès aux procédures stockées ?

C'est parce que avec l'objet TableAdapter, on peut modifier le dataGrid comme on veut et après avec la méthode Update du TableAdapter elle sauvegarde tout le dataset au complet et le met dans la bases de données.

Si on n'utilise pas le TableAdapter.Update, il faut écrire beaucoup de lignes de codes en ADO pur pour faire le même travail.

[iberserk]

Si on n'utilise pas le TableAdapter.Update, il faut écrire beaucoup de lignes de codes en ADO pur pour faire le même travail.

Et bien faites l'effort...
J'ai personnelement codé une procédure stockée qui me génère automatique les CRUD pour une table donnée...

[Bluedeep]

Est-ce que vous connaissez une autre façon qui est plus sécuritaire ?

Il faudrait avoir beaucoup plus éléments pour répondre (authentifiez vous le client de bout-en-bout, où authentifiez vous uniquement le serveur d'application ? authentification Kerberos ou authentification Sql Server ? etc .... la sécurité c'est une approche globale - et je précise que je n'en suis pas un spécialiste).

[DEV-10]

Et bien faites l'effort...
J'ai personnelement codé une procédure stockée qui me génère automatique les CRUD pour une table donnée...

J'essaye d'utiliser la puissance des objets que nous offre Visual Studio, ADO.NET, et le FrameWork en les adaptant à notre situation.


C'est quoi les CRUD ?

[Bluedeep]

J'essaye d'utiliser la puissance des objets que nous offre Visual Studio, ADO.NET, et le FrameWork en les adaptant à notre situation.


C'est quoi les CRUD ?

"Create Read Update Delete" : les actions de base sur les tables.

[Graffito]

iberserk : sauf erreur de ma part, vous ne pouvez faire autrement "que faire les update+acceptChanges à chaque insert, update ou delete"

On peut faire une série d'insert dans la DataTable ADO, puis faire Adapter.Update() pour toute la série,
au lieu d'exécuter l'Update+acceptChanges après chaque insert.

[iberserk]

On peut faire une série d'insert dans la DataTable ADO, puis faire Adapter.Update() pour toute la série,
au lieu d'exécuter l'Update+acceptChanges après chaque insert.

Vous avez raison, je voulais dire par là que cela générera autant d'ordre sql que de ligne...

[Invité]

On peut faire une série d'insert dans la DataTable ADO, puis faire Adapter.Update() pour toute la série,
au lieu d'exécuter l'Update+acceptChanges après chaque insert.

Bref j'ajoute juste que ce principe est toujours le même dans EF. Tu crées, modifies et supprimes tes données en mémoire. Mais au final pour que ça soit validé vers la base de données il faut appeler la méthode SaveChanges (qui fait office de AcceptChanges en codant mais en dé-compilant la méthode SaveChanges (sans paramètres), vous pouvez voir que les développeurs de l'API EF appellent bien une méthode AcceptChnages qui a le même but que pour un TableAdapter. )