Overgang fra ODBC til ADBC-drivere i Power BI og Fabric

Power BI og Microsoft Fabric overfører støttede datakildetilkoblinger fra eldre innebygde ODBC-drivere til Apache Arrow Database Connectivity (ADBC) drivere. ADBC inneholder et sett med standardgrensesnitt for samhandling med pildata, noe som er spesielt effektivt for å hente store datasett med minimal overhead og ingen serialisering eller kopiering. ADBC-driverne inkluderer også sikkerhetsforbedringer, som minnesikkerhet og søppelsamling.

Du kan ta i bruk ADBC i dag per tilkobling, og administratorer kan kontrollere standardoppførselen i stor skala ved å bruke en leietakerinnstilling som arbeidsområdeadministratorer kan overstyre for testing og validering.

Kontakter og driverendringer

Tabellen nedenfor viser kontaktene som går fra innebygde ODBC-drivere til erstatningsdrivere. I de fleste tilfeller er erstatningsdriveren en ADBC-driver.

Hvem som er berørt

Du blir berørt hvis du bruker noen av koblingene som går over til ADBC (som Databricks, Snowflake eller Google BigQuery) og:

• Du har ikke eksplisitt valgt en implementering i tilkoblingen (parameteren Implementation er ikke spesifisert), eller
• Organisasjonen din ønsker sentralisert kontroll over om ADBC eller ODBC er standard for støttede koblinger.

Denne standarden gjelder uansett hvor du oppretter en kobling, inkludert semantiske modeller, Dataflows Gen2 og paginerte rapporter.

Hvordan migrere

Du kan migrere på tre måter, ordnet etter hvor mye kontroll du ønsker:

• Opt-in per tilkobling: Legg til Implementation="2.0" individuelle forbindelser for å validere ADBC i ditt eget tempo.
• Leietakerinnstilling: Sett standard for hele organisasjonen via administrasjonsportalen.
• Arbeidsområde-overstyring: Overstyr leietakerstandarden på arbeidsområde-nivå for side-ved-side-validering.

Per-tilkobling opt-in

Du kan melde deg på ADBC ved å legge til Implementation="2.0" støttede tilkoblinger. Denne tilnærmingen lar deg validere ADBC i ditt eget tempo for individuelle forbindelser.

For detaljerte instruksjoner om hvordan man velger per tilkobling for en spesifikk kontakt, se den stikkerspesifikke dokumentasjonen lenket i tabellen Koblinger og driverendringer .

Leierinnstilling

Leietakeradministratorer kan sette organisasjonens standard ved å bruke Admin-portalinnstillingen:

Brukere kan koble seg til datakilder ved å bruke Apache Arrow databasetilkobling (ADBC)

• Deaktivert (standard): Velger de eldre ODBC-driverne som standardvalg.
• Aktivert: Velger de nye ADBC-driverne som standardvalg.

Denne innstillingen styrer også testtilkoblingsoppførselen for hver tilkoblingstype inne i leietakeren.

Arbeidsområde-overstyring

Leietakerinnstillingen delegerer til arbeidsområder, slik at arbeidsområdeadministratorer kan overstyre standarden og sammenligne atferd uten å endre hver enkelt tilkobling. Denne tilnærmingen tillater side-ved-side-validering. For eksempel kan du bruke ett arbeidsområde for å teste ADBC-standardinnstillinger mens du beholder et annet arbeidsområde på ODBC-standardinnstillinger.

Hvordan implementeringen velges

Hvis du eksplisitt spesifiserer parameteren Implementation i tilkoblingen, har den verdien alltid forrang over standardinnstillingene for leietaker eller arbeidsområde.

Tabellen nedenfor viser hvordan driveren velges:

Lokal virkemåte for datagateway

ADBC-innstillingene for tenant og arbeidsområde gjelder for oppdateringsbaner som kjører i skytjenesten. Spørringer som ruter gjennom en lokal datagateway , fortsetter å bruke driveren som er buntet med gatewayinstallasjonen, som i dag er ODBC for koblingene som er oppført i denne artikkelen. Gateway-rutede oppdateringer bytter ikke til ADBC når leier- eller arbeidsområdeinnstillingen er aktivert, og dette er forventet virkemåte.

To konsekvenser å være oppmerksom på når du planlegger overføringen:

• Hvis du bruker en gateway til å teste overgangen til ADBC, gjenspeiler ikke oppdateringer gjennom gatewayen ADBC-banen. Test ADBC ved hjelp av en skytilkobling for å validere ADBC-virkemåte ende-til-ende på en nøyaktig måte.
• Kunder som trenger å forbli på ODBC (for eksempel for å bevare en privat koblingsbane gjennom gatewayen), kan utsette endringen ved å fortsette å rute oppdateringer gjennom den lokale gatewayen med ODBC-driverne installert. Dette er en utsettelse, ikke en permanent utmelding: Når ODBC-drivere fjernes fra fremtidige gateway-installasjoner (se nøkkeldatoer), blir gatewayer festet til tidligere versjoner til slutt ikke støttet. Planlegg gatewayoppgraderinger og ADBC-validering tilsvarende.

Anbefalt migrasjonssjekkliste

1. Overvåk arbeidsområdet med pq-adbc-advisor til lager hver tilkobling som fester den eldre driveren og ser en risikoklassifisering per element. Se Overvåke arbeidsområdet med pq-adbc-advisor.
2. Velg et pilotarbeidsområde og aktiver ADBC der først ved å bruke arbeidsområdets overstyring for å validere viktige datasett og oppdatere scenarioer. Hvis du vil validere ADBC-banen fra ende til ende, tester du ved hjelp av en skytilkobling – se virkemåten for lokal datagateway for hvorfor gateway-rutede oppdateringer forblir på ODBC.
3. Valider i Power BI Desktop. Installer gjeldende Power BI Desktop-utgivelse, som sender ADBC-driveren for hver in-scope-kobling som har passert standard flip. Det finnes ingen veksleknapp per fil for å tvinge ADBC på en eksisterende spørring – for å rute en eksisterende spørring til ADBC, slette spørringen, legge til kilden på nytt og velge feltene på nytt. Oppdater og sammenlign radantall, kolonnetyper og oppdateringsvarighet mot ODBC-grunnlinjen.
4. For eventuelle kritiske forbindelser du ønsker å validere umiddelbart, velg per forbindelse med Implementation="2.0".
5. Når valideringen er fullført, avgjør om ADBC skal aktiveres som standard på leietakernivå.

Overvåke arbeidsområdet med pq-adbc-advisor

Før du overfører, må du vite hva du skal endre. pq-adbc-advisorer en skrivebeskyttet Fabric notatblokk som skanner et arbeidsområde og returnerer en konsekvensrapport per element som viser hvilke semantiske modeller, dataflyter og datasamlebånd som fremdeles fester den eldre ODBC-driveren og hva de skal gjøre med hver enkelt.

Hva konsekvensrapporten gir deg

Konsekvensrapporten gir deg:

• En oversikt over alle koblingskaller som overføres i arbeidsområdet på tvers av koblingene som går over til ADBC.

• En fullstendig risikoklassifisering for hvert element:

  Risiko	Hva risikoen betyr	Hva du må gjøre
  Vil mislykkes	M-spørringspinnene Implementation="1.0" og elementet har ingen gatewaybinding. Ved fullstendig, slutter denne oppdateringen å fungere.	Fjern [Implementation="1.0"] fra kildetrinnet, eller bind elementet til en gateway før fullstendig.
  Trenger gjennomgang	Enten fester M-spørringen ODBC, men en gateway er bundet (overlever fullstendig, men bør fortsatt vendes), eller M bygger en rå DSN-streng som ADBC ikke bruker ordrett.	Test ADBC-banen i en kopi av elementet, og rull deretter ut. For DSN-strengtilfeller som standardkoblingen ikke dekker, kan du eskalere til eskaleringspostboksen som er oppført i akseleratoren.
  Klar	M-spørringen fester allerede ADBC (Implementation="2.0"), eller den løsnes, og leierbryteren håndterer den rent.	Ingen handling. Skann på nytt etter cutover for å bekrefte.

• Dekning for datasamlebånd og dataflyt gen2, ikke bare semantiske modeller.

• Løsningssporing på tvers av skanninger – hver skanning har både en førstekjørings grunnlinje og en gjeldende kjøreteller, så en ny skanning forteller deg hva som har blitt ryddet opp siden første gang.

Hva konsekvensrapporten ikke gjør

Konsekvensrapporten gjør ikke følgende:

• Skriv om eventuelle M-uttrykk.
• Utløser oppdateringer på egen hånd (et eget inngangspunkt er angitt for validering).
• Send M-kode, elementnavn, URL-adresser for endepunkt, legitimasjon eller oppdatering av meldingstekster utenfor arbeidsområdet.

Hver skanning sender anonyme tellinger til Power Query teamet, slik at de kan måle innføring og prioritere koblingsdekning. Skanningen sender bare SHA-256-hashed tenant og brukeridentifikatorer, uten råverdier som standard. Hvis du vil melde deg ut når som helst, deaktiverer du telemetri som dokumentert i akseleratoren. Utmeldingen vedvarer på tvers av kjernestarter.

Slik kjører du konsekvensrapporten

Den enkleste måten å bruke verktøyet på, er gjennom startnotatblokken i Microsoft Fabric Toolbox.

1. Last ned startnotatblokken og importer den til et Fabric arbeidsområde.
2. Legg ved notatblokken i arbeidsområdet du vil lagre.
3. Kjør notatblokken fra topp til bunn. Det installeres pq-adbc-advisor i økten, skanner arbeidsområdet, gjengir innvirkningsrapporten innebygd og lagrer en HTML-kopi av rapporten til standard lakehouse hvis du legger ved en.
4. Gjør løsningene dine.
5. Kjør notatblokken på nytt. Rapporten viser oppløsningsdeltaene – hvor mange pinner du har ryddet opp etter den første skanningen.

Hvis du har administratortillatelser og ønsker å feie alle arbeidsområder i leieren, dokumenterer hurtigvalgene et alternativ for hele leieren som bruker API-en for Fabric administratorskanner. Tenantskanninger tar vanligvis 15–30 minutter for en mellomstor leier.

Hvis du vil ha informasjon om feil, funksjonsforespørsler og koblingsdekningshull, kan du se akseleratorrepositoriet.

Viktige datoer

• Juli 2026 (planlagt): Bred utrulling av leietakerordningen starter. Workspace-atferd arver denne innstillingen og kan overstyres av workspace-administratorer der det støttes.
• Oktober 2026 (planlagt): Microsoft planlegger å starte aktivering av leierinnstillingen som standard i faser, avhengig av utrullingsberedskap.
• Tidlig kvartal 2027 (planlagt): Microsoft planlegger å begynne å fjerne ODBC-drivere fra tjenesten, avhengig av utrullingsberedskap. Hvis du må bli værende på ODBC (Implementation="1.0" eller workspace som aktiverer Off), må du bruke en gateway for å fortsette å kjøre spørringer med ODBC.
• Våren 2027 (planlagt): ODBC-driverne som refereres til i denne artikkelen, er planlagt ikke lenger å leveres med Power BI Desktop eller gatewayen.

Før håndhevelsesmilepæler planlegger Microsoft å gi forhåndsvarsel slik at kundene kan fullføre migrerings- og valideringsaktiviteter.

Vanlige spørsmål

Kan jeg teste ADBC nå?

Ja. Installer gjeldende Power BI Desktop, og legg til en hvilken som helst kilde i omfanget på nytt – nye spørringer rutes til ADBC umiddelbart. For testing på tjenestesiden bruker du overstyringen av arbeidsområdet til å aktivere ADBC på et pilotarbeidsområde og validere via en skytilkobling.

Hvordan finner jeg alle steder jeg fortsatt bruker den eldre ODBC-driveren?

Kjør pq-adbc-advisor mot arbeidsområdet. Det er en skrivebeskyttet Fabric notatblokk som lager hver semantisk modell, dataflyt og datasamlebånd som fortsatt bruker den eldre driveren. Det klassifiserer hver enkelt etter cutover risiko og viser hva du skal endre. Behandle det som startpunktdiagnose, ikke en endelig revisjon. Se Overvåke arbeidsområdet med pq-adbc-advisor. Administratorer kan kjøre en leierens omfattende opprydding via API-en for Fabric administratorskanner. Se hurtigvalgdokumentasjonen for mer informasjon.

Påvirkes jeg hvis jeg allerede bruker den lokale datagatewayen?

ADBC-innstillingene for tenant og arbeidsområde gjelder bare for kjøringer i tjenesten – de påvirker ikke oppdateringer som rutes gjennom en lokal datagateway. Gateway-rutede oppdateringer fortsetter å bruke ODBC gjennom fullstendig for koblingene i denne artikkelen. Se virkemåten for lokal datagateway. ODBC-drivere er planlagt fjernet fra fremtidige gatewayinstallasjoner – spor nøkkeldatoer for tidsberegning.

Hvordan kan jeg velge bort ADBC-overgangen?

Du kan ikke velge bort permanent. Med leierinnstillingen kan du utsette standard flip under valideringsvinduet, men når ODBC er deaktivert i tjenesten, er endringen universell. Hvis du vil fortsette å bruke ODBC etter fullstendig tjenesteside, må du rute oppdateringer gjennom en lokal datagateway med ODBC-drivere installert. Denne endringen er bare en utsettelse – ODBC-drivere er planlagt fjernet fra fremtidige gatewayinstallasjoner.

Hvorfor endrer ikke ADBC-innstillingen for arbeidsområdet min Power BI Desktop-filen?

Det finnes ingen veksleknapp per fil for ADBC i Power BI Desktop. Eksisterende spørringer i en skrivebordsfil forblir på hvilken driver de ble skrevet opp mot til spørringen ble opprettet på nytt. Hvis du vil validere ADBC for en eksisterende spørring, sletter du spørringen, legger til kilden på nytt og velger feltene på nytt. Nye spørringer i gjeldende skrivebordsversjonsrute til ADBC automatisk for koblinger som har sendt standardflipsen.

Omskriver ADBC-innstillingen for arbeidsområdet mine eksisterende M-spørringer?

Nei. Innstillingene for leier og arbeidsområde endrer hvilken driver som er valgt ved kjøring av spørring, men de endrer ikke selve M-uttrykket – vertsnavn, porter, tilkoblingsparametere og koblingsargumenter i M forblir nøyaktig som forfattet. Denne virkemåten gjelder både nyopprettede og eksisterende tilkoblinger: enhver tilkobling som ikke eksplisitt fester Implementation i M, følger arbeidsområdet/leieren som standard når den snur seg.

Tilkoblinger som fester driveren i M, har prioritet over standardinnstillingen for arbeidsområdet/leieren. En tilkobling med Implementation="1.0" forblir på ODBC, og Implementation="2.0" forblir på ADBC, uavhengig av arbeidsområdet eller leierinnstillingen. Hvis du vil endre en av disse, redigerer du M.

Hvis du vil ha koblingsspesifikk virkemåte (inkludert eventuelle port- eller alternativforskjeller mellom ODBC- og ADBC-driverne), kan du se den koblingsspesifikke dokumentasjonen som er koblet i tabellen Koblinger og driverendringer .

Relatert innhold

• Databricks-kobling
• Azure Databricks kontakt
• Google BigQuery-kobling
• Google BigQuery (Microsoft Entra ID) kobling
• Impala-kontakt
• Snowflake-kobling
• pq-adbc-advisor accelerator (Microsoft Fabric Toolbox)