Sign in with Microsoft
Sign in or create an account.

Sammendrag

Når du bruker Ny operatoren eller funksjonen CreateObject i Visual Basic til å opprette en forekomst av en Microsoft Office-program, kan du få følgende feilmelding:

Kjøretidsfeil '429': ActiveX-komponent kan ikke opprette objekt

Denne feilen oppstår når det forespurte automatiseringsobjektet ikke kunne opprettes av COM, og er derfor utilgjengelig for Visual Basic. Feilen er vanligvis vises på enkelte datamaskiner, men ikke andre.

Denne artikkelen inneholder feilsøkingstips for å hjelpe deg med å diagnostisere og løse vanlige problemer som er kjent for å forårsake denne feilen.

Hvis du vil ha mer informasjon

I motsetning til noen feil i Visual Basic er det ingen én årsak til feil 429. Problemet oppstår på grunn av en feil i program- eller systemfeil konfigurasjonen eller en komponent mangler eller er skadet. Å finne den nøyaktige årsaken er et spørsmål om å eliminere mulighetene. Hvis du støter på denne feilen på en klientdatamaskin, er det flere ting du trenger for å isolere og løse problemet.

Elementene gi senere noen praktiske forslag til feilsøking av denne feilen når du arbeider med Office-programmer. Noe av denne informasjonen kan også gjelde for ikke - Office-COM-servere, men denne artikkelen forutsetter at du prøver å automatisere Microsoft Office.

Sjekke koden

Det er det første stedet å begynne på jakt etter problemet i koden. Før du kan feilsøke problemet, må du vite der feilen oppstår. Prøv å begrense det ned til en enkelt linje med kode.

Når du finner koden som feilen har oppstått, kan du prøve å gjøre følgende:

  • Kontroller at koden bruker eksplisitt objektoppretting. Alle problemer er enklere å oppdage og finne ut om problemet er smalere for en enkelt handling. Hvis du for eksempel ikke gjør følgende:

    Application.Documents.Add 'DON'T USE THIS!!

    eller:

    Dim oWordApp As New Word.Application 'DON'T USE THIS!!
    '... some other code
    oWordApp.Documents.Add

    Begge disse metodene bruker implisitt objektoppretting. Microsoft Word startes ikke til variabelen kalles minst én gang. Siden variabelen kan kalles i ulike deler av programmet, kan dette gjøre problemet vanskelig å lokalisere. Dessuten er det ikke klart om problemet er med oppretter programobjektet eller Document-objektet.

    I stedet må du eksplisitt kall til å opprette hvert objekt separat:

    Dim oWordApp As Word.Application
    Dim oDoc As Word.Document
    Set oWordApp = CreateObject("Word.Application")
    '... some other code
    Set oDoc = oWordApp.Documents.Add

    Dette gjør det enklere å isolere problemet og gjør koden mer lesbar.

  • Når du oppretter en forekomst av et Microsoft Office-program, bruker du CreateObject-metoden i stedet for Ny. CreateObject nærmere tilordner til oppretting av prosessen som brukes av de fleste Visual C++-klienter, og gjør det mulig for mulige endringer i serverens CLSID mellom versjoner. CreateObject-metoden kan brukes med tidlig binding- og sene objekter.

  • Kontroller at program-ID strengen som ble sendt til CreateObject er riktig og at den versjonen er uavhengige (det vil si bruk "Excel.Application" i stedet for "Excel.Application.8"). Det kan være at systemet mislykkes har en eldre eller nyere versjon av Microsoft Office enn versjonen du har angitt i program-IDen.

  • For å hjelpe i feilsøking programmer ikke kan kjøres i IDE, kan du bruke kommandoen Erl til å rapportere linjenummeret til linjen som mislykkes. Hvis du for eksempel vil følgende kode fortelle deg hvilket Automation-objekt ikke kan opprettes (Word eller Excel):

    Dim oWord As Word.Application
    Dim oExcel As Excel.Application

    On Error Goto err_handler

    1: Set oWord = CreateObject("Word.Application")
    2: Set oExcel = CreateObject("Excel.Application")

    ' ... some other code

    err_handler:
    MsgBox "The code failed at line " & Erl, vbCritical

    Bruke en kombinasjon av meldingsbokser og linjenumre til å spore feilen.

  • Prøv å bruke sen binding (det vil si Dim oWordApp som objekt). Tidlig bundet objekter krever sine egendefinerte grensesnitt formidles over prosessgrenser. Hvis det er et problem formidling et egendefinert grensesnitt under CreateObject eller Ny, får du en feil 429. En sent bundet objekt bruker en systemdefinert grensesnitt (IDispatch), som ikke krever en egendefinert proxy for å formidle. Prøv å bruke en sent bundet objekt for å se om det gjør en forskjell.

    Hvis problemet bare oppstår når objektet er tidlig binding, problemet er med serverprogrammet, og kan vanligvis rettes ved å installere programmet på nytt (se senere).

  • Hvis du automatiserer fra ASP- eller en MTS-komponent, bruker du CreateObject-metoden i stedet for Server.CreateObject(). Ved hjelp av Server.CreateObject , vil du starte Office-program med identiteten til en MTS-pakke som kan forårsake problemer med Microsoft Office.

Kontrollerer Automation-serveren

De vanligste årsakene til feil CreateObject eller Ny er problemer med serverprogrammet seg selv. Disse problemene er vanligvis med konfigurasjonen eller installasjonen av programmet. Her er noen elementer til å kontrollere:

  • Kontroller for Microsoft Office program du ønsker å Automatiser er installert på den lokale datamaskinen, og pass på at du kan starte programmet fra Start og kjør deretter dialogboksen. Hvis programmet ikke kan startes manuelt, vil den ikke fungere gjennom automatisering.

  • Registrer programmet på nytt ved å skrive inn banen til serveren i Start og Kjør-dialogboksen, og deretter Tilføy/regserver til slutten av linjen. Trykk OK. Dette bør stille kjøre programmet og registrere den på nytt som en COM-server. Hvis problemet er med en manglende registernøkkelen, rettes dette vanligvis det.

  • Sjekk LocalServer32-nøkkelen under CLSID for programmet du vil Automatiser. Kontroller at den peker til den riktige plasseringen for programmet, og Kontroller banenavnet er i et kort banen (DOS 8.3)-format. Mens det ikke er et krav som en server er registrert ved hjelp av et kort banenavn, lange banenavn som inneholder innebygde mellomrom er kjent for å forårsake problemer på enkelte systemer (se senere).

    Hvis du vil kontrollere banen nøkkelen som er lagret for serveren, start Registerredigering ved å skrive regedit i Start og kjør deretter dialogboksen. Gå til nøkkelen HKEY_CLASSES_ROOT\Clsid. Under denne nøkkelen finner du CLSIDene for registrerte automatiseringsservere på systemet. Ved hjelp av verdiene senere, Finn nøkkelen som representerer det Office-programmet du vil Automatiser og kontrollere sin LocalServer32-nøkkel for banen.


    +========================+=========================================+
    | Office Server | CLSID Key |
    +========================+=========================================+
    | Access.Application | {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9} |
    +------------------------+-----------------------------------------+
    | Excel.Application | {00024500-0000-0000-C000-000000000046} |
    +------------------------+-----------------------------------------+
    | FrontPage.Application | {04DF1015-7007-11D1-83BC-006097ABE675} |
    +------------------------+-----------------------------------------+
    | Outlook.Application | {0006F03A-0000-0000-C000-000000000046} |
    +------------------------+-----------------------------------------+
    | PowerPoint.Application | {91493441-5A91-11CF-8700-00AA0060263B} |
    +------------------------+-----------------------------------------+
    | Word.Application | {000209FF-0000-0000-C000-000000000046} |
    +------------------------+-----------------------------------------+
    Banen er samsvarer med den faktiske plasseringen av filen? Vær oppmerksom på at kort banenavn som kan gi inntrykk at en bane er riktig når det ikke er. For eksempel vil både Microsoft Office og Microsoft Internet Explorer (Hvis installert deres plasseringer som standard) ha en kort bane som er lik "C:\PROGRA~1\MICROS~X\" der X er et tall. Det er ikke like tydelig at du ser på fra et kort banenavn.

    Du kan teste at banen er faktisk riktig ved kopiering av verdien fra registret og lime den inn i Start og deretter Kjør-dialogboksen (fjerne bryteren /Automation før du kjører programmet). Starter programmet når du velger OK? Hvis Ja, er deretter serveren riktig registrert. Hvis ikke, bør du erstatte verdien for LocalServer32-nøkkelen med den riktige banen (Bruk om mulig et kort banenavn).

  • Problemer er kjent for å oppstå når du automatiserer Word eller Excel hvis enten Normal.dot-malen (Word) eller filen Excel.xlb ressurs (Excel) er skadet. For å teste om det har oppstått en feil, kan du søke på lokale harddisker til å søke etter alle forekomster av Normal.dot eller *.xlb. (Vær oppmerksom på at hvis du kjører Windows 2000, Windows NT eller Windows 95/98 med aktiverte profiler, kan du finne flere kopier av disse filene, én for hver brukerprofil på systemet.) Midlertidig gi nytt navn til Normal.dot-filer eller *.xlb-filene, og Kjør Automation-testen på nytt (Word og Excel oppretter disse filene hvis de ikke finner dem). Koden nå fungerer? Hvis Ja, skal deretter filene du endret navnet slettes etter at de er skadet. Hvis ikke, bør du gi dem tilbake til de opprinnelige navnene slik at alle egendefinerte innstillinger som er lagret i disse filene ikke går tapt.

  • Hvis du er på en Windows NT, Windows 2000, Windows XP eller Windows Server 2003-systemet, Kjør applikasjonen under Administrator-kontoen. Office-servere krever lese/skrive-tilgang til registret og stasjon, og kan ikke laste inn hvis de gjeldende sikkerhetsinnstillingene nekter denne rettigheten.

Kontrollerer systemet

Systemkonfigurasjon kan også forårsake problemer med opprettelsen av-prosesseksterne COM-servere. Dette er noen ting du kan kontrollere på systemer der feilen oppstår:

  • Skjer problemet med en out-of-process-server? Hvis du har et program som bruker bare en bestemt COM-server (for eksempel Word), vil du teste en annen out-of-process-server for å kontrollere at problemet ikke er med COM-laget seg selv. Hvis ingen-prosesseksterne COM-serveren ikke kan opprettes på dette systemet, en ny installering av OLE-filer (se nedenfor), eller en ny installering av operativsystemet for å løse problemet.

  • Kontrollere versjonsnumrene for OLE-systemfiler som administrerer automatisering. Disse filene installeres vanligvis som et sett, og bør samsvare med build-numrene. Et feil konfigurert installasjonsprogrammet kan ved et uhell installere filene hver for seg, forårsaker dem til å bli ugyldig. Hvis du vil unngå problemer med automatisering, bør du kontrollere filer for å kontrollere at filene som samsvarer med versjoner.

    Du finner Automation-filer i mappen Windows\System eller Winnt\System32. Følgende er en liste over filer som skal kontrollere:


    +---------------+-------------+----------------+
    | File Name | Version | Date Modified |
    +---------------+-------------+----------------+
    | Asycfilt.dll | 2.40.4275 | March 08, 1999 |
    | Oleaut32.dll | 2.40.4275 | March 08, 1999 |
    | Olepro32.dll | 5.0.4275 | March 08, 1999 |
    | Stdole2.tlb | 2.40.4275 | March 08, 1999 |
    +---------------+-------------+----------------+
    Kontroll filversjonen ved å høyreklikke filen i Explorer og velger Egenskaper fra hurtigmenyen. De viktigste verdiene er de fire siste sifrene i versjonen (build-nummer) og dato for siste endring. Vil du at disse verdiene er de samme for alle automatisering-filer.

    Vær oppmerksom på at versjonsnumre og datoene som er angitt ovenfor, er for eksempel bare. Verdiene kan være forskjellige. Viktige er at disse verdiene samsvarer med hverandre i stedet for denne tabellen.

    Hvis filene ikke tilsvarer build-numrene eller datoer som er endret, kan du laste ned et selvutpakkende verktøy som oppdaterer filene automatisering. For mer informasjon, klikker du følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:

    290887 VBRun60sp6.exe installerer kjøretidsfiler for Visual Basic 6.0 SP6

  • Windows NT 4.0 har et kjent problem med å starte automatiseringsservere som bor i en mappe som inneholder en innebygd mellomrom i navn og/eller ligner på en annen mappe som har 8 første tegnene er identiske. For eksempel kan en server som bor i c:\Programfiler\Microsoft Files\SomeFolder kunne starte under et kall til CreateObject Hvis det er en annen mappe på systemet kalles c:\Programfiler\Microsoft Stuff\SomeFolder. Hvis du vil ha mer informasjon, se følgende Knowledge Base-artikkel:For mer informasjon om dette problemet og trinn for å unngå dette, klikker du artikkelnummeret nedenfor for å vise artikkelen i Microsoft Knowledge Base:

    185126 feil: COM/OLE-serveren ikke starter på Windows NT 4.0

Installere Microsoft Office på nytt

Hvis ingen av trinnene ovenfor hjelper deg med å løse problemet, kan du vurdere å avinstallere og installere Microsoft Office på nytt. Microsoft anbefaler at du først avinstallere den eksisterende versjonen og installere på nytt fra de originale installasjonsdiskettene.

For en fullstendig liste over elementer som skal fjernes, kan du se følgende Knowledge Base-artikler:

219423 OFF2000: hvordan du fjerner Microsoft Office 2000 fullstendig

158658 OFF97: Slik fjerner du Microsoft Office 97 fullstendig

Referanser

Hvis du vil ha mer informasjon om hvordan du feilsøker feilmeldingen '429', kan du klikke følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:

240377 slik: sikre Jet 3.5 er riktig installert (del I)
For den nyeste informasjonen og eksempelkode for Microsoft Office-automatisering, kan du se webområdet Microsoft Online support på:

http://support.microsoft.com/ofd

Trenger du mer hjelp?

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Microsoft Insiders

Var denne informasjonen nyttig?

Hvor fornøyd er du med språkkvaliteten?
Hva påvirket opplevelsen din?

Takk for tilbakemeldingen!

×