none
Modifier les propriete d'un champs db Access avec ado.net RRS feed

  • Question

  • Bonjour,

    Comment dois faire pour modifier les proprietees d'un champs d'une base de donnee Access en utilisant ado.net:

    Auparavant j'utilisais DAO comme ceci :

    Dim MyTable As dao.TableDef
    Dim MyField As dao.Field
    DAOEngine = New dao.DBEngine
    DAODatabase = DAOEngine.OpenDatabase(DB, False, False, ";UID=" & Utilisateur & ";PWD=" & Password)
    '
    MyTable = DAODatabase.TableDefs("Corps")
    MyField = MyTable.Fields("Notes")
    If MyField.AllowZeroLength = False Then
       MyField.AllowZeroLength = True
       MyTable.Fields.Refresh()
       DAODatabase.TableDefs.Refresh()
    End If
    MyTable.close
    DAODatabase.close


     mais comment faire avec ado.net

    Merci par avance

     

    vendredi 23 septembre 2011 15:15

Réponses

  • Un script vbs comme :

    Set obj=CreateObject("DAO.DBEngine.36")
    MsgBox obj.Version

    permettrait de voir si DAO 3.6 est bien installé ou si le problème se situe plutôt sur le "wrapper" .NET.

    Le fichier Interop.DAO.dll a bien été copié ?

    Sinon un outil comme http://technet.microsoft.com/en-us/sysinternals/bb896645 permet de tracer les accès aux fichiers et probablement, en filtrant les résultats "fichier pas trouvé" de voir quel est le fichier à l'origine de cette erreur.

    Egalement ce n'est pas un problème de version ? Je crois que DAO 3.6 correspond à Office 2000 et que c'est DAO 3.5 qui correspond à Access 97.

    Bon courage.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    lundi 26 septembre 2011 08:45
    Modérateur

Toutes les réponses

  • Bonjour,

    Je crains que cela ne soit impossible sans référençer la bibliothèque DAO depuis votre projet car cette propriété est spécifique à Access.

    Les autres bases utilisent généralement des contraintes CHECK. Si éventuellement Access générait derrière une contrainte CHECK accessible à l'utilisateur, il serait peut-être alors possible de faire la modification via un ALTER TABLE MaTable DROP CONSTRAINT MaContrainteCheck ??? Mais je ne sais pas du tout comment c'est implanté dans Access.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    vendredi 23 septembre 2011 15:45
    Modérateur
  • C'est ce que je pensais les nouveaux outils ne sont pas aussi evoluer qu'ont le dit puisqu'il perdent de leurs possibilitées en ''evoluant'' au profit d'autres peut etre inutile ?

     

    vendredi 23 septembre 2011 15:58
  • Le probleme c'est que ont affirme que DAO est obsolete, la je m'interroge ?

    Et l'orsque que je veux deployer une appli avec DAo 3.6 probleme  d'exploitation erreur interop etc ...

    Je voudrais bien qu'on m'explique.

    vendredi 23 septembre 2011 16:03
  • Le message exact est ? Je dirais que DAO 3.6 n'est pas installé. Si une appli Office est installée sur le poste, lancer l'environnement VBA et vérifier si DAO 3.6 est bien listé dans l'ajout de références. Ou s'agirait il d'une machine 64 bits ?

    Le problème est surtout que DAO est étroitement lié à un format de base de données (et même plutôt à un produit) en particulier. Je pense que c'est en ce sens que MS l'a signalé comme obsolète (en tant que format général) tout en continuant à le maintenir de fait pour une utilisation depuis Access.

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    vendredi 23 septembre 2011 18:13
    Modérateur
  • Merci de votre reponse.

    Mais.

    Tout ca, c'est bien joli, mais l'orsque l'on veut deployer une application avec la DAO 3.6 Library, on se heurte au probleme d'absence de dll au lancement de l'appliocation et cela meme si vous prevoyer les dll en fichiers dans le package.

    Je conais ce probleme j'ai perdu 1 mois en recherche d'une solution sur le sujet. (en 32 bits avec MsAccess 97 installé sur le poste), j'ai du changer et reprendre tout mon code avec ADO.NET et maintenant on s'apercoi que il faut conserver DAO 3.6 pour certaines opérations, mais pas de solution quant on deploie DAO 3.6.

    La ca va plus. 

     

    samedi 24 septembre 2011 08:22
  • Un script vbs comme :

    Set obj=CreateObject("DAO.DBEngine.36")
    MsgBox obj.Version

    permettrait de voir si DAO 3.6 est bien installé ou si le problème se situe plutôt sur le "wrapper" .NET.

    Le fichier Interop.DAO.dll a bien été copié ?

    Sinon un outil comme http://technet.microsoft.com/en-us/sysinternals/bb896645 permet de tracer les accès aux fichiers et probablement, en filtrant les résultats "fichier pas trouvé" de voir quel est le fichier à l'origine de cette erreur.

    Egalement ce n'est pas un problème de version ? Je crois que DAO 3.6 correspond à Office 2000 et que c'est DAO 3.5 qui correspond à Access 97.

    Bon courage.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    lundi 26 septembre 2011 08:45
    Modérateur
  • Bonjour, Dave,

    Est-ce que vous avez pu avancer en utilisant les informations fournies par Patrice ? Merci de tenir la communauté informée sur la suite de vos démarches.

     

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    mercredi 28 septembre 2011 06:28
  • Bonjour,

    Tous les fichier necessaire ont ete copie meme Interop.DAO.dll pas non plus un probleme de version j'ai testé avec DAO 3.5 aussi.

    Pour etre sur j'avais installé MS Access 97 + Le pack Jet3.5 . prevu dans le pack d'install toutes les dlls.

    Et toujours probleme .

    Par contre j'ai d'autres appli qui sont developpé en vb6 avec base de données MSAccess 97 celle ci s'install et tourne sans problemes, c'est une vraie rolls de ce coté la, donc je crois qu'il va falloir revoir la copie VB.net chez MS.

    Y a donc bien un truc, je me demande donc si vb.net est vraiment polyvalent y a des developpements qu'il vaut mieux executer sous vb6 ca c'est sur ! car vb.net soit y a des gadgets mais sinon pour la tranquilite y a pas photo (pour moi apres pour les autres ...)



    dimanche 2 octobre 2011 07:58
  • Bonjour,

    Et le message d'errreur exact est donc ? Quid des suggestions précédentes notamment de l'outil permettant de voir quel est le fichier manquant ?

    Personnellement je n'utilise pas DAO depuis .NET. Comme indiqué dans ma première réponse une contrainte CHECK permet d'obtenir le même résultat, fonctionne sur toutes les bases de données et supprimerait la dépendance sur DAO si c'est la seule fonctionnalité de DAO qui est encore utilisée.

    Je vais faire un essai sur un Windows 7 et je vais mettre l'exe sur un XP (vous êtes bien dans ce cas de figure ?)

    Je comprends votre frustation mais il va être difficile d'avancer si aucune des précisions demandées ou suggestions faites n'est suivie d'effet. Déjà quel est le message d'erreur exact que vous avez lorsque vous déployez votre application et sur quelle ligne survient il ?

     Je confirme : un déploiement d'une appli compilé sur Windows 7 avec DAO 3.6 vers un XP avec Access 97 fonctionne sans souci chez moi. La première étape serait vraiment de comprendre quel est le fichier manquant (peut-être le fichier "groupe de travail" plutôt qu'une DLL ?) si c'est bien ce qui provoque le message d'erreur.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    dimanche 2 octobre 2011 10:00
    Modérateur
  • Mon cas est sous Xp pro sp3, mais je ne vais pas m'etendre cela dure depuis 1 mois et cela commence a me les briser (sans vouloir etre mechant).

    J'ai revu tout mon projet, tous le code utilisant DAO n'existe plus, tout a ete passe en ADO net, cela a augmenter de 30% la taille de mon exe (evidement).

    Donc mon seul soucis est de trouver une solution qui me permette de  pouvoir modifier les proprietes d'un objet fields de table access dans des base de donnees MSAccess 97.

    De pouvoir modifier la propriete fields.AllowZeroLength  d'un champ mais aussi d'un field de type Date (passe de longDate a ShortDate) etc ..

    Et cela sans avoir 4 kilometre de code a balancé.

    Mais d'apres ce que j'ai lu cela n'est pas possible, corrigez moi si je me trompe ?

     

    dimanche 2 octobre 2011 16:32
  • Cela marche donc chez moi sans souci même avec des OS différents.

    Le problème serait donc qu'il manque un fichier et il faudrait identifier quel est le fichier manquant. Ne connaissant ni le message d'erreur exact, ni la ligne concernée, il est difficile de savoir de quel fichier il s'agit exactement.

    D'où ma demande du message d'erreur exact ou ma suggestion d'utiliser l'outil indiqué plus haut pour trouver le message manquant. Quel est donc le message d'erreur exact ?


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    mardi 4 octobre 2011 13:58
    Modérateur