[ASE][11.9.2]ADO avec connexion (problème lors d'un update et movenext)

[louffi]

Bonjour à tous,

Mon objectif est de migrer une apllication vb6 connecté à une basse access vers une base de donnée sybase 11.9.2. L'idée générale est de ne pas refaire toute l'aplli mais de changer que ce qui est necessaire.

Pour la connexion proprement dit à la sgbd, je n'ai pas eu de problème.
Par contre, ça se complique sur la methode update et movenext de l'objet recordset. En effet je recupère comme erreur : "Un état E_Fail a eté renvoyé par le fournisseur de données ou par un autre service".

Au depart, le select de mon recordset etait composé de jointures, j'ai donc fait une requete simple pour voir si le pbe persiste, hélas il persiste.
J'ai donc pensé que les composants odbc de sybase n'etait pas à jour...le pbe pesiste toujours. J'ai également mis à jour le composant Mcrosoft ActiveX Data Objects 2.7 library, le pbe persiste.

Pour la méthode update de mon recordset, je peux m'en sortir en faisant un update directement en base, parcontre si je ne peux pas boucler sur le recorset avec movenext, comment faire ??

Après m'être tiré les cheveux et en lisant les différents tutos de votre site, j'utilise un curseur serveur, sur une "requête simple" (une table et sans jointure), et oh miracle les deux methodes update et movenext fonctionnent.

Je fais donc le test avec une "requête plus complexe" (3 tables avec jointures), et là, pas de chance car ça plante, j'obtiens le message suivant : "la requete ne peut être mise à jour car la clause FROM ne contient pas un nom unique et simple de table"

Je me dis, ok, je vais donc faire moi même mon update directement en sql via un objet command. L'update se fait correctement, mais ça plante de nouveau sur le movenext, avec le même message...snif

Au moins je n'ai plus le message un peu flippant E_Fail

Pour info, les tables que j'utilise n'ont pas de clef unique...

Merci d'avance de me dire comment je peux m'en sortir...

[fadace]

La modification de vues est très (et justement) limitée. Commençez par mettre des clefs primaires et des intégrités référentielles à vos tables... ça aidera pas mal en cas d'update sur vue/requête.

[louffi]

là n'est pas le problème :

Envoyé par fadace

Commençez par mettre des clefs primaires à vos tables...

si je ne t'avais pas précisé cette information, que m'aurais-tu répondu ?

Imaginons, que je rajoute une clef incrémentale à ma table, tu m'assures que je n'aurais plu de pbme sur l'update et le movenext ?

de plus à chaque insert en base, il faudra via vb que je sois capable, par l'intermédiare de mon recodset, lorsque je fais addnew, d'incrementer automatiquement ma table ?

[fadace]

Ce n'est pas anodin. Un curseur est obligé de passer par une unicité de champ afin de ne pas se perdre si un bloc venait à bouger pendant la ballade du curseur.

C'est comme dans une table liée en MS-Access. Si l'outil ne trouve pas de PK, il en demande une ou refuste toute modif sur la table liée.

D'où l'existance en T-SQL du cursor for update ou for select !

Maintenand, il est clair que nous parlons d'un cluster côté client et pas serveur via ADO. Je ne dis pas que c'est la cause unique de votre problème,
mais que vous pouvez vous éviter pas mal de cas de bord en modélisant proprement...

Et l'existance d'une clé primaire dans une table, c'est le b-a-ba d'une modélsiation basique...