Discussion :

[Pol63]

bonjour

d'habitude je suis sur sql server, qui est tellement gentil qu'il vous explique l'erreur plutot que de vous narguer avec un message qui équivaut à "essaye encore"

bref j'ai une requete qui ne passe pas sur access, depuis un programme en .net

Code :

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

1
2
3
4
5
6
7
8
 
UPDATE [reception] 
SET [ident]=@ident,[dateent]=@dateent,[heurent]=@heurent,[datesor]=@datesor,[heursor]=@heursor,[coop]=@coop,[livreur]=@livreur,[centre]=@centre,[produit]=@produit,[transport]=@transport,[modetrans]=@modetrans,[contrat]=@contrat,
         [libcamp]=@libcamp,[echantillon]=@echantillon,[pdsent]=@pdsent,[pdssor]=@pdssor,[pdsbrut]=@pdsbrut,[pdscor]=@pdscor,[cara1]=@cara1,[taux1]=@taux1,[cara2]=@cara2,[taux2]=@taux2,[cara3]=@cara3,[taux3]=@taux3,[cara4]=@cara4,[taux4]=@taux4,[commentaire]=@commentaire,
[code_cellule]= DLookup("[Code_Cellule]", "cellules", "[Designation_Cellule] = 'C79'")
 
          WHERE [nopesee] = @nopesee
;

je remplie tous les paramètres par code

1er problème "le champ est trop petit pour accueillir les données, mais je te laisse deviner lequel !" sympa ce access !
pour moi tout doit rentrer, surtout qu'un coier coller dans access qui me demande la valeur des paramètres passe ...

bref pour chercher lequel j'ai mis "" dans tous les string, et là autre problème cité en titre

j'en déduis que ca vient du WHERE ou éventuellement du dlookup
pour le where ca me semble peu probable, c'est un double dans access et dans mon programme
et pour le dllookup à priori il passe sous access aussi ...


comment avoir des vrais informations sur les erreurs sur ce @#$µ% d'access ?
voyez vous quelques chose qui cloche ?

merci

[Maxence HUBICHE]

Salut !!!

Bon alors, plusieurs choses...

• D'abord, est-ce que ta requête est écrite en SQL dans ton code DotNet ? Si oui... euh ... bon courage
• Si la requête est écrite dans l'application Access, tu n'es pas en présence de paramètres, puisque je ne vois pas la clause PARAMETERS dans ton SQL. D'autre part, il semble que pour accéder à une requête paramétrée depuis le DotNet, tu doives passer par un DataAdapter, et non par une Command (je te passe les détails...), mais c'est un autre problème
• Concernant le pessage d'erreur, il indique que tu essaies de mettre quelque chose dans aute chose, mais ces deux choses n'ont pas le même type. Est-ce que tu Cast toutes tes valeurs au moment où tu passes les paramètres, afin qu'ils correspondent aux types des champs ?

à toi la balle !

[Pol63]

j'utilise un DbCommand en effet, sur lequel j'ajoute des OleDbParameters en précisant le type (OleDb.OleDbType.VarWChar par exemple) et je fourni la valeur

je n'ai jamais utilisé de DataAdapter, pensant que c'était juste fait pour utilisation d'un non connaisseur du langage sql désireux de remplir un datatable et d'en répercuter les modifications
et si j'ai bien suivi le DataAdapter ne fait que créer des requetes insert/update/delete donc c'est qu'on a bien le droit d'exécuter des requetes sur access ... (ton "bon courage" me fait peur)
d'ailleurs le DataAdapter fournit un DbCommand ...

je vais revérifier que les types concordent une fois de plus ...

[Pol63]

j'ai retiré le dlookup ca passe pas mieux
donc c'est bien le where qui pose problème, meme en mettant

Code :

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

cdbl([reception].[nopesee]) = cdbl(@nopesee)

toujours "type incompatible"

en retirant le where l'erreur redevient "champ trop petit"
pourtant j'ai vérifier les tailles et les types ...

[Jean-Philippe André]

salut,

as-tu des valeurs NULL ou non numeriques dans tes enregistrements ?

[Pol63]

tous les champs sont nullables, et il y a certains champs que je ne spécifie pas dans mon insert si c'est ca la question

j'ai des double, des varWchar et un longVarWchar

[Pol63]

un collègue a fini par trouver

attention aux âmes sensibles ca peut faire peur !

access utilise les DbParameters indépendamment de leur nom, le 1er trouvé dans la requête aura comme valeur celle du 1er parameter de la collection Parameters et ainsi de suite ...

[LedZeppII]

Bonsoir,

En fait ça ne vient pas d'Access, mais du framework, et plus précisément du type de fournisseur de données .NET.

Cf Utilisation des procédures stockées avec une commande

Les fournisseurs de données .NET Framework pour OLE DB et .NET Framework pour ODBC ne prennent pas en charge les paramètres nommés pour le passage des paramètres à une instruction SQL ou une procédure stockée. Dans ce cas, vous devez utiliser l'espace réservé de point d'interrogation (?), comme dans l'exemple suivant.

Code :

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

SELECT * FROM Customers WHERE CustomerID = ?

En conséquence, l'ordre dans lequel les objets Parameter sont ajoutés à la collection Parameters doit directement correspondre à la position de l'espace réservé ? pour le paramètre.

Ton problème aurait été le même avec toute source de données autre que SQL Server et Oracle

A+

[Pol63]

oui je me doute bien que c'est la surcouche du framework ...
enfin si c'est tout oledb qui fait ca, je préfère de loin le namespace d'sql server