Discussion :

[belzeluc]

Salut à tous.

Voila j'ai un DataTable que j'arrive déjà à remplir avec un DataAdapter depuis une base de données. J'arrive également à ajouter un record (DataRow) dans le DataTable mais lorsque j'essaie de mettre à jour la base de données, le record ne passe pas...
J'ai vérifié que les champs n'acceptant pas de valeur nulle sont remplis avec une valeur par défaut du bon type.
Auriez-vous une idée? Pour info, je procède comme ceci

Code :

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

1
2
3
4
5
6
7
8
9
10
 
:
//déclaration de la nouvelle ligne
DataRow rowAjout = tabItem.NewRow();
:
rowAjout[1] = 45489;
rowAjout[56] = 1;
:
//MAJ de la DB (DaItem est le DataAdapter; tabItem est le DataTable)
DaItem.Update(tabItem);

Merci beaucoup

[Thomas Lebrun]

Essaye ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
//déclaration de la nouvelle ligne
DataRow rowAjout = tabItem.NewRow();
 
rowAjout[1] = 45489;
rowAjout[56] = 1;
 
DaItem.tabItem.Rows.Add(rowAjout);
 
//MAJ de la DB (DaItem est le DataAdapter; tabItem est le DataTable)
DaItem.Update(tabItem);

[belzeluc]

Hello. Merci pour ta réponse.

EN ayant ajouté la ligne d'ajout dans le DataTable, j'ai maintenant une erreur générée lors du Update sur la DB

Une exception non gérée du type 'System.Data.OleDb.OleDbException' s'est produite dans system.data.dll

Bizarre...Des pistes?

[belzeluc]

Je resort mon topic du fond des âges car après l'avoir laissé de coté, je reprends mon projet et je n'ai toujours pas trouvé de solution...

[Astartee]

EN ayant ajouté la ligne d'ajout dans le DataTable, j'ai maintenant une erreur générée lors du Update sur la DB

Une exception non gérée du type 'System.Data.OleDb.OleDbException' s'est produite dans system.data.dll

ça ressemble à une exception lors de l'insertion dans la base de données
Quelle est la commande d'insertion du DataAdapter ?

[belzeluc]

Oui pour moi aussi c'est une erreur d'insertion

INSERT INTO item(item_number, description, default_location_id, cost, avgcost, manufacturer_id, category_id, unit_of_measure, reorder_qty, alt_item_number, linked_file, list_price, sale_price, supplier_id, min_stock_level, max_stock_level, qty_available, qty_checked_out, qty_in_house, track_serial_numbers, track_lots, track_date_codes, track_pallets, track_pos, track_suppliers, track_customers, allow_fraction_qty, manager, checkout_duration, width, height, length, dimension_unit, weight, weight_unit, usrdefdate1, usrdefdate2, usrdefdate3, usrdefdate4, usrdefdate5, usrdefnumber1, usrdefnumber2, usrdefnumber3, usrdefnumber4, usrdefnumber5, usrdeftext1, usrdeftext2, usrdeftext3, usrdeftext4, usrdeftext5, usrdeftext6, usrdeftext7, usrdeftext8, usrdeftext9, usrdeftext10, record_status, company_id, list_id, date_updated, auto_sn, auto_sn_value) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?); SELECT item_id, item_number, description, default_location_id, cost, avgcost, manufacturer_id, category_id, unit_of_measure, reorder_qty, alt_item_number, linked_file, list_price, sale_price, supplier_id, min_stock_level, max_stock_level, qty_available, qty_checked_out, qty_in_house, track_serial_numbers, track_lots, track_date_codes, track_pallets, track_pos, track_suppliers, track_customers, allow_fraction_qty, manager, checkout_duration, width, height, length, dimension_unit, weight, weight_unit, usrdefdate1, usrdefdate2, usrdefdate3, usrdefdate4, usrdefdate5, usrdefnumber1, usrdefnumber2, usrdefnumber3, usrdefnumber4, usrdefnumber5, usrdeftext1, usrdeftext2, usrdeftext3, usrdeftext4, usrdeftext5, usrdeftext6, usrdeftext7, usrdeftext8, usrdeftext9, usrdeftext10, record_status, company_id, list_id, date_updated, auto_sn, auto_sn_value FROM item WHERE (item_id = @@IDENTITY)

Ce qui me parait bizarre, c'est la deuxième partie de la commande, après le "SELECT"...

[Astartee]

Ce qui me parait bizarre, c'est la deuxième partie de la commande, après le "SELECT"...

et pourtant c'est ton code... il a donc été récupéré quelque part ? ^^


La deuxième partie de la requête sert à récupérer le dernier enregistrement créé dans la base, par exemple pour vérifier que c'est bien le bon, ou pour récupérer les valeurs produites automatiquement (compteurs...) par la base et les réinsérer dans ta DataTable.

Problèmes que je peux envisager :
- ta base accepte-t-elle les requêtes multiples ? par exemple, Access ne les accepte pas => erreur
- en supposant que les requêtes multiples sont acceptées, le fait d'en utiliser dans l'InsertCommand du DataAdapter pose peut-être problème ; *j'imagine* qu'à l'intérieur du DataAdapter la requête d'insertion est envoyée en ExecuteNonQuery puisqu'on n'attend pas de résultat...

Dans tous les cas, cette deuxième partie dans la requête est inutile, puisque le résultat retourné ne sera jamais traité !
C'est une solution à utiliser quand tu fais tes insertions "à la main", sans passer par un DataAdapter.

[belzeluc]

Ma DB (SQL) est actuellement sur une MSDE en local.

A un autre endroit de mon programme, je réalise une insertion de la même manière mais dans une autre table avec un autre DataAdapter et un autre DataTable et la ca fonctionne nickel. J'ai comparé la syntaxe des deux commandes d'insertion ainsi que mes deux codes et cela concorde.
Comme je l'ai dit, j'ai fait attention à ce que les champs n'acceptant pas de valeur NULL soient remplis par défaut (ici le champs 56). J'ai fait le test en utilisant l'explorateur de DB inclus dans Visual Studio : j'affiche la table et je crée un nouveau record en mettant une valeur uniquement à ce champs-là, ca passe alors que si ce champs reste vide, j'ai un message d'erreur comme quoi il faut lui donner une valeur.

[Astartee]

hummm
euh
je sèche
allez, encore quelques idées au cas-z-où :

Je ne connais pas l'explorateur de base, mais d'après ta formulation je n'ai pas l'impression que tu testes ta requête elle-même (?) Est-il possible qu'il y ait une erreur dans les noms des champs ?? (c'est con mais ça arrive parfois même après avoir lu et relu...)

Y a-t-il, par hasard un trigger sur ta table qui générerait une ligne dans une autre table (ex : un journal...), ce qui ferait que le "@@IDENTITY" ne correspondrait en fait plus à la clé de ta table ? (c'est tordu, mais c'est possible)

Et sinon, as-tu essayé en supprimant la partie "SELECT" de ta requête ?

[belzeluc]

En supprimant la partie SELECT de la commande, oui

Pour le nom des champs, comme tu as pu voir dans mon premier message, je travaille avec les numéro de champs et pas avec les nom des champs (ceci-dit, j'avais essayé avec le nm du champs.

Sinon c'est vrai, en passant par l'explorateur de base, je ne teste pas vraiment la requete mais les champs qu'il faut remplir obligatoirement (n'acceptant pas la valeur NULL)

Dans tous les cas, merci de ton aide

[Astartee]

je travaille avec les numéro de champs et pas avec les nom des champs (ceci-dit, j'avais essayé avec le nm du champs.

Je parle bien sûr d'une éventuelle erreur dans la chaîne de la requête... Enfin je suppose que tu l'as déjà "lue et relue"


Autre tests à faire : essayer d'envoyer directement la requête en donnant les données "en dur" dans la chaîne, puis ajouter les paramètres en leur donnant directement leur valeur (param.Value=...), puis réessayer sur un DataRow en contrôlant les valeurs données en paramètres (exécution en mode débug)...
Evidemment avec un tel nombre de champs ça risque de ne pas être folichon ! Mais si tu dis que ça marche pour une autre table, c'est que le problème doit se situer dans la requête envoyée à la base àmha...