Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Impossible d'exécuter un StoredProc en VB.NET. GRANT ?

Impossible d'exécuter un StoredProc en VB.NET. GRANT ?

11 réponses
Avatar
\(\( Olivier \)\)
Bonjour,
J'utilise MSDE 2000

J'ai une Procédure Stockée : sp_DeleteAdresse qui est : DELETE FROM
adresse
J'ai accordé les droits à l'utilisateur : GRANT ALL ON sp_DeleteAdresse
to moimeme;

Si j'utilise OSQL -U moimeme -P monpass, alors je peux executer la procédure
stockée.

Par contre, en VB.NET, je me connecte bien avec mon compte, et là,
impossible d'executer la procédure stockée.
J'indique que tout marche impeccablement pour les autres procédures stockée.

Est-ce à cause du DELETE ? Pourquoi OSQL marche et pas en VB.NET ?

Voiçi le code que j'utilise (qui est le même que les autres ... ?)

Dim cString As String = "Initial Catalog=mabase;Data Source=localhost; User
Id=moimeme; Password=monpass;"
Dim cnx As New SqlConnection(cString)
Dim cmd As New SqlCommand("sp_DeleteAdresse", cnx)
Try

cnx.Open()
cmd.CommandType = CommandType.StoredProcedure
cmd.ExecuteNonQuery()
cnx.Close()

Catch ex As Exception
MsgBox(ex.Message)

End Try

Merci pour l'aide car là, je coince !

Olivier
Signaler un problème avec ce contenu

1 réponse

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
bruno reiter [MVP]
pour que les admins locaux n'aient pas les droits sur le serveur SQL il faut
enlever le compte builtinadministrators du role sysadmin

br

"(( Olivier ))" wrote in message
news:
Je sais, mais dans mon cas, c'est pas ca.

Je suis dev independant.
Mes clients n'ont aucun admin de quoi que se soit, il savent tous juste
démarrer le pc :-)
ils ne savent même pas que j'utilise tel ou tel SGBD. Ils ne connaissent
même pas les bases de données.
C'est moi qui install mon prog avec tout qui va bien, et c'est tout.
Je ne travaille pas pour des grands comptes ou autres assimilé, qui là, ok
je suis d'accord avec toi, on surrement des personnels qualifiés.

Seulement, par sécurité, je voudrais empecher quique se soit de faire un
OSQL -E
et donc de faire des catastrophes. Si non à quoi sert le compte 'sa' si
c'est si simple de faire un OSQL -E ?

Olivier



"Paul Bacelar" a écrit dans le message de
news:
> Tu ne ferra jamais admettre à un client et surtout à son admin qu'il ne
doit
> pas toucher à la base. S'il est compétent il sait qu'il doit faire des
back
> up et autres taches. Le client est roi, ne l'oublie pas.
> --
> Paul Bacelar
>
> "(( Olivier ))" a écrit dans le message de
> news:
> > Et pourquoi "Doux rèves" ?
> > Vous me faites peur :-<
> >
> > Est-ce impossible ? S'il n'y a qu'un seul compte et un seul ?
> > On peut avoir qu'un seul compte 'sa' ?
> > Avec le SECURITYMODE=SQL
> >
> > Par contre, il est vraiment impossible d'empecher quiconque de faire un
> > OSQL -E ?
> >
> > Cela serait très dangereux, non ?
> > Un petit .BAT avec OSQL -E DELETE et hop ! dommage !
> >
> > Merci
> > Olivier
> >
> >
> > "Paul Bacelar" a écrit dans le message de
> > news:
> > > Doux rêves ;-)
> > > --
> > > Paul Bacelar
> > >
> > > "(( Olivier ))" a écrit dans le message de
> > > news:%23419bf$
> > > > Merci pour ta réponse, mais je veux justement être indépendant des
> > comptes
> > > > Windows.
> > > >
> > > > Je voudrais n'avoir qu'un seul compte autorisé à acceder au serveur
et
> > > donc
> > > > aux bases.
> > > > C'est pour le déploiement en clientèle, je veux être SUR que
personne,
> > non
> > > > personne ne puisse acceder au server SQL a part moi.
> > > >
> > > > Donc pas de sécurité intégré ni de OSQL -E
> > > >
> > > > Merci
> > > > Olivier
> > > >
> > > >
> > > >
> > > > "Pyroa" a écrit dans le
> message
> > > de
> > > > news:
> > > > > pour acceder à une base SQL le mieux est d'utiliser la sécurité
> > intégré
> > > de
> > > > > windows.
> > > > > Pour ca il faut modifier la ConnectionString en :
> > > > >
> > > > > data source=PERTHMOC;Initial Catalog½1SQL;user ID=sa" />
> > > > >
> > > > > moi j'utilise ca ou la connection string générée par VS..NET
> > > > >
> > > > > :)
> > > > >
> > > > > "(( Olivier ))" a écrit dans le message de
> > > > > news:
> > > > > > Bonjour,
> > > > > > J'utilise MSDE 2000
> > > > > >
> > > > > > J'ai une Procédure Stockée : sp_DeleteAdresse qui est :
DELETE
> > FROM
> > > > > > adresse
> > > > > > J'ai accordé les droits à l'utilisateur : GRANT ALL ON
> > > > sp_DeleteAdresse
> > > > > > to moimeme;
> > > > > >
> > > > > > Si j'utilise OSQL -U moimeme -P monpass, alors je peux executer
la
> > > > > procédure
> > > > > > stockée.
> > > > > >
> > > > > > Par contre, en VB.NET, je me connecte bien avec mon compte, et
là,
> > > > > > impossible d'executer la procédure stockée.
> > > > > > J'indique que tout marche impeccablement pour les autres
> procédures
> > > > > stockée.
> > > > > >
> > > > > > Est-ce à cause du DELETE ? Pourquoi OSQL marche et pas en VB.NET
?
> > > > > >
> > > > > > Voiçi le code que j'utilise (qui est le même que les autres ...
?)
> > > > > >
> > > > > > Dim cString As String = "Initial Catalog=mabase;Data
> > Source=localhost;
> > > > > User
> > > > > > Id=moimeme; Password=monpass;"
> > > > > > Dim cnx As New SqlConnection(cString)
> > > > > > Dim cmd As New SqlCommand("sp_DeleteAdresse", cnx)
> > > > > > Try
> > > > > >
> > > > > > cnx.Open()
> > > > > > cmd.CommandType = CommandType.StoredProcedure
> > > > > > cmd.ExecuteNonQuery()
> > > > > > cnx.Close()
> > > > > >
> > > > > > Catch ex As Exception
> > > > > > MsgBox(ex.Message)
> > > > > >
> > > > > > End Try
> > > > > >
> > > > > > Merci pour l'aide car là, je coince !
> > > > > >
> > > > > > Olivier
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




1 2