Dans une application Winform, j'acc=E8de =E0 une base Access avec un=20
DataGridView.
A c=F4t=E9 de ce DataGridView, sur l'enregistrement s=E9lectionn=E9, je c=
r=E9e une=20
requ=EAte update (pour rectifier un champ de clef, voir fil pr=E9c=E9dent=
), et=20
je l'ex=E9cute avec une oledbConnection.
Tant que mon application est ouverte, m=EAme apr=E8s avoir ferm=E9 le=20
formulaire, la valeur est bien corrig=E9e, =E7a baigne.
Patatras, d=E8s que j'ai ferm=E9 l'application, =E0 l'utilisation suivant=
e, le=20
champ a repris la valeur qu'il avait avant.
Il manque une validation quelque part, j'h=E9site =E0 dire o=F9 ...
Si quelqu'un pouvait me rafraichir les esprits ...
command.UpdatedRowSource =3D UpdateRowSource.Both;
// avant d'ouvrir la connection
J'ai aussi essay=E9 avec une transaction, mais curieusement, ce que je=20
comprends du texte de l'erreur est qu'on ne peut ouvrir une transaction=20
que si il y en a d=E9j=E0 une en cours, alors que je me serais na=EFvemen=
t=20
repr=E9sent=E9 l'inverse.
code :
OleDbTransaction trans =3D null;
command.Connection =3D connection;
command.UpdatedRowSource =3D UpdateRowSource.Both;
connection.Open();
trans =3D connection.BeginTransaction();
command.ExecuteNonQuery();
trans.Commit();
erreur sur ExecuteNonQuery :
"System.InvalidOperationException: ExecuteNonQuery implique que la=20
commande comporte une transaction lorsque la connexion attribu=E9e =E0 la=
=20
commande se trouve dans une transaction locale en attente. La propri=E9t=E9=
=20
Transaction de la commande n'a pas =E9t=E9 initialis=E9e.\r\n
=E0=20
System.Data.OleDb.OleDbConnectionInternal.ValidateTransaction(OleDbTransa=
ction=20
transaction, String method)\r\n
=E0=20
System.Data.OleDb.OleDbConnection.ValidateTransaction(OleDbTransaction=20
transaction, String method)\r\n
=E0=20
System.Data.OleDb.OleDbCommand.ValidateConnectionAndTransaction(String=20
method)\r\n
=E0=20
System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior=20
behavior, String method)\r\n
=E0 System.Data.OleDb.OleDbCommand.ExecuteNonQuery()\r\n
=E0 CandEtat.frmActions.button1_Click(Object sender, EventArgs e) dan=
s=20
C:\\Documents and Settings\\admin\\Mes documents\\Visual Studio=20
2005\\Projects\\CandEtat\\CandEtat\\frmActions.cs:ligne 109"
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
Gloops
ça y est, ça marche.
Le formulaire où sont faites les modifications n'est pas le formulaire principal, et le formulaire principal avait un DataSet ouvert sur la même table. ça fait que les anciennes données restaient chargées dans le DataSet du formulaire principal, et donc était restaurées lors de la fermeture de celui-ci.
J'ai créé un formulaire de menu pour appeler l'un ou l'autre, comme ç a le formulaire principal ne contient plus de données, et le problème n e se pose plus.
J'ai bien essayé d'appliquer le principe dont parlait cc18 l'autre jour , à savoir déclarer public la source de données du formulaire princip al, et l'appeler depuis l'autre formulaire. Il s'avère que cette affaire-là est un fichu casse-tête. En effet, le owner n'est renseigné qu'aprè s le InitializeComponent, donc si on veut aller fouiller dedans ça suppose d e décaler les instructions du InitializeComponent concernant la source commune vers le Form_Load. J'ai essayé de jouer à ça, et puis il s'avérait que le DataGridView était vide, alors que la DataTable contenait bien les données. ça peut être intéressant de chercher un peu plus loin, mais pour le moment j'ai préféré en rester à des faç ons de travailler plus habituelles.
Bon alors pour les tests il faut prendre en compte autre chose encore : depuis l'environnement de développement on se retrouve systématiqueme nt avec les mêmes données, car la base comporte l'attribut Copy Always, donc lors de la compilation la base est copiée du répertoire source v ers bindebug. Après déploiement ce problème ne se pose plus -ou alors on change la propriété Copy to Output Directory.
Pour tout dire, je n'ai déployé qu'après avoir créé un formulai re principal sans données. _____________________________________ Gloops a écrit, le 10/08/2009 17:35 :
Bonjour tout le monde,
Dans une application Winform, j'accède à une base Access avec un DataGridView.
A côté de ce DataGridView, sur l'enregistrement sélectionné, je crée une requête update (pour rectifier un champ de clef, voir fil précéde nt), et je l'exécute avec une oledbConnection.
Tant que mon application est ouverte, même après avoir fermé le formulaire, la valeur est bien corrigée, ça baigne.
Patatras, dès que j'ai fermé l'application, à l'utilisation suiva nte, le champ a repris la valeur qu'il avait avant.
Il manque une validation quelque part, j'hésite à dire où ...
Si quelqu'un pouvait me rafraichir les esprits ...
command.UpdatedRowSource = UpdateRowSource.Both; // avant d'ouvrir la connection
J'ai aussi essayé avec une transaction, mais curieusement, ce que je comprends du texte de l'erreur est qu'on ne peut ouvrir une transaction que si il y en a déjà une en cours, alors que je me serais naïvem ent représenté l'inverse.
code : OleDbTransaction trans = null; command.Connection = connection; command.UpdatedRowSource = UpdateRowSource.Both; connection.Open(); trans = connection.BeginTransaction(); command.ExecuteNonQuery(); trans.Commit();
erreur sur ExecuteNonQuery : "System.InvalidOperationException: ExecuteNonQuery implique que la commande comporte une transaction lorsque la connexion attribuée à la commande se trouve dans une transaction locale en attente. La proprié té Transaction de la commande n'a pas été initialisée.rn à System.Data.OleDb.OleDbConnectionInternal.ValidateTransaction(OleDbTran saction transaction, String method)rn à System.Data.OleDb.OleDbConnection.ValidateTransaction(OleDbTransaction transaction, String method)rn à System.Data.OleDb.OleDbCommand.ValidateConnectionAndTransaction(String method)rn à System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)rn à System.Data.OleDb.OleDbCommand.ExecuteNonQuery()rn à CandEtat.frmActions.button1_Click(Object sender, EventArgs e) da ns C:Documents and SettingsadminMes documentsVisual Studio 2005ProjectsCandEtatCandEtatfrmActions.cs:ligne 109"
ça y est, ça marche.
Le formulaire où sont faites les modifications n'est pas le formulaire
principal, et le formulaire principal avait un DataSet ouvert sur la
même table. ça fait que les anciennes données restaient chargées dans le
DataSet du formulaire principal, et donc était restaurées lors de la
fermeture de celui-ci.
J'ai créé un formulaire de menu pour appeler l'un ou l'autre, comme ç a
le formulaire principal ne contient plus de données, et le problème n e
se pose plus.
J'ai bien essayé d'appliquer le principe dont parlait cc18 l'autre jour ,
à savoir déclarer public la source de données du formulaire princip al,
et l'appeler depuis l'autre formulaire. Il s'avère que cette affaire-là
est un fichu casse-tête. En effet, le owner n'est renseigné qu'aprè s le
InitializeComponent, donc si on veut aller fouiller dedans ça suppose d e
décaler les instructions du InitializeComponent concernant la source
commune vers le Form_Load. J'ai essayé de jouer à ça, et puis il
s'avérait que le DataGridView était vide, alors que la DataTable
contenait bien les données. ça peut être intéressant de chercher un peu
plus loin, mais pour le moment j'ai préféré en rester à des faç ons de
travailler plus habituelles.
Bon alors pour les tests il faut prendre en compte autre chose encore :
depuis l'environnement de développement on se retrouve systématiqueme nt
avec les mêmes données, car la base comporte l'attribut Copy Always,
donc lors de la compilation la base est copiée du répertoire source v ers
bindebug. Après déploiement ce problème ne se pose plus -ou alors on
change la propriété Copy to Output Directory.
Pour tout dire, je n'ai déployé qu'après avoir créé un formulai re
principal sans données.
_____________________________________
Gloops a écrit, le 10/08/2009 17:35 :
Bonjour tout le monde,
Dans une application Winform, j'accède à une base Access avec un
DataGridView.
A côté de ce DataGridView, sur l'enregistrement sélectionné, je crée une
requête update (pour rectifier un champ de clef, voir fil précéde nt), et
je l'exécute avec une oledbConnection.
Tant que mon application est ouverte, même après avoir fermé le
formulaire, la valeur est bien corrigée, ça baigne.
Patatras, dès que j'ai fermé l'application, à l'utilisation suiva nte, le
champ a repris la valeur qu'il avait avant.
Il manque une validation quelque part, j'hésite à dire où ...
Si quelqu'un pouvait me rafraichir les esprits ...
command.UpdatedRowSource = UpdateRowSource.Both;
// avant d'ouvrir la connection
J'ai aussi essayé avec une transaction, mais curieusement, ce que je
comprends du texte de l'erreur est qu'on ne peut ouvrir une transaction
que si il y en a déjà une en cours, alors que je me serais naïvem ent
représenté l'inverse.
code :
OleDbTransaction trans = null;
command.Connection = connection;
command.UpdatedRowSource = UpdateRowSource.Both;
connection.Open();
trans = connection.BeginTransaction();
command.ExecuteNonQuery();
trans.Commit();
erreur sur ExecuteNonQuery :
"System.InvalidOperationException: ExecuteNonQuery implique que la
commande comporte une transaction lorsque la connexion attribuée à la
commande se trouve dans une transaction locale en attente. La proprié té
Transaction de la commande n'a pas été initialisée.rn
à
System.Data.OleDb.OleDbConnectionInternal.ValidateTransaction(OleDbTran saction
transaction, String method)rn
à
System.Data.OleDb.OleDbConnection.ValidateTransaction(OleDbTransaction
transaction, String method)rn
à
System.Data.OleDb.OleDbCommand.ValidateConnectionAndTransaction(String
method)rn
à
System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)rn
à System.Data.OleDb.OleDbCommand.ExecuteNonQuery()rn
à CandEtat.frmActions.button1_Click(Object sender, EventArgs e) da ns
C:\Documents and Settings\admin\Mes documents\Visual Studio
2005\Projects\CandEtat\CandEtat\frmActions.cs:ligne 109"
Le formulaire où sont faites les modifications n'est pas le formulaire principal, et le formulaire principal avait un DataSet ouvert sur la même table. ça fait que les anciennes données restaient chargées dans le DataSet du formulaire principal, et donc était restaurées lors de la fermeture de celui-ci.
J'ai créé un formulaire de menu pour appeler l'un ou l'autre, comme ç a le formulaire principal ne contient plus de données, et le problème n e se pose plus.
J'ai bien essayé d'appliquer le principe dont parlait cc18 l'autre jour , à savoir déclarer public la source de données du formulaire princip al, et l'appeler depuis l'autre formulaire. Il s'avère que cette affaire-là est un fichu casse-tête. En effet, le owner n'est renseigné qu'aprè s le InitializeComponent, donc si on veut aller fouiller dedans ça suppose d e décaler les instructions du InitializeComponent concernant la source commune vers le Form_Load. J'ai essayé de jouer à ça, et puis il s'avérait que le DataGridView était vide, alors que la DataTable contenait bien les données. ça peut être intéressant de chercher un peu plus loin, mais pour le moment j'ai préféré en rester à des faç ons de travailler plus habituelles.
Bon alors pour les tests il faut prendre en compte autre chose encore : depuis l'environnement de développement on se retrouve systématiqueme nt avec les mêmes données, car la base comporte l'attribut Copy Always, donc lors de la compilation la base est copiée du répertoire source v ers bindebug. Après déploiement ce problème ne se pose plus -ou alors on change la propriété Copy to Output Directory.
Pour tout dire, je n'ai déployé qu'après avoir créé un formulai re principal sans données. _____________________________________ Gloops a écrit, le 10/08/2009 17:35 :
Bonjour tout le monde,
Dans une application Winform, j'accède à une base Access avec un DataGridView.
A côté de ce DataGridView, sur l'enregistrement sélectionné, je crée une requête update (pour rectifier un champ de clef, voir fil précéde nt), et je l'exécute avec une oledbConnection.
Tant que mon application est ouverte, même après avoir fermé le formulaire, la valeur est bien corrigée, ça baigne.
Patatras, dès que j'ai fermé l'application, à l'utilisation suiva nte, le champ a repris la valeur qu'il avait avant.
Il manque une validation quelque part, j'hésite à dire où ...
Si quelqu'un pouvait me rafraichir les esprits ...
command.UpdatedRowSource = UpdateRowSource.Both; // avant d'ouvrir la connection
J'ai aussi essayé avec une transaction, mais curieusement, ce que je comprends du texte de l'erreur est qu'on ne peut ouvrir une transaction que si il y en a déjà une en cours, alors que je me serais naïvem ent représenté l'inverse.
code : OleDbTransaction trans = null; command.Connection = connection; command.UpdatedRowSource = UpdateRowSource.Both; connection.Open(); trans = connection.BeginTransaction(); command.ExecuteNonQuery(); trans.Commit();
erreur sur ExecuteNonQuery : "System.InvalidOperationException: ExecuteNonQuery implique que la commande comporte une transaction lorsque la connexion attribuée à la commande se trouve dans une transaction locale en attente. La proprié té Transaction de la commande n'a pas été initialisée.rn à System.Data.OleDb.OleDbConnectionInternal.ValidateTransaction(OleDbTran saction transaction, String method)rn à System.Data.OleDb.OleDbConnection.ValidateTransaction(OleDbTransaction transaction, String method)rn à System.Data.OleDb.OleDbCommand.ValidateConnectionAndTransaction(String method)rn à System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)rn à System.Data.OleDb.OleDbCommand.ExecuteNonQuery()rn à CandEtat.frmActions.button1_Click(Object sender, EventArgs e) da ns C:Documents and SettingsadminMes documentsVisual Studio 2005ProjectsCandEtatCandEtatfrmActions.cs:ligne 109"
