Oversikt over databasetilkoblinger¶

Innholdsfortegnelse¶

1. Slik fungerer tilkoblinger
2. Veiledninger per teknologi
3. Forutsetning: Installer ODBC-driveren på digna-verten
4. Opprett en databasetilkobling
5. ODBC-egenskaper
6. Kryptering av egenskapsverdier
7. Teste en tilkobling
8. Hvilken database tilkoblingen ser
9. Profiling Mode og Work Schema
10. Bruke en DSN i stedet
11. Feilsøking

Slik fungerer tilkoblinger¶

digna når alle kildeteknologier over ODBC. En tilkobling er en liste med ODBC-egenskaper som du legger inn som nøkkel/verdi-par. Når digna åpner tilkoblingen, setter den sammen parene til en tilkoblingsstreng — Key=Value, skilt med ;, i den rekkefølgen du oppga dem — og sender den til ODBC-driverbehandleren (driver manager) på digna-verten.

Det at du selv legger inn egenskapene, er det som gjør oppsettet DSN-løst: tilkoblingen inneholder alt driveren trenger, så ingen ODBC-datakilde (DSN) må registreres på verten. Dette er den anbefalte måten å konfigurere digna på, fordi tilkoblingsdefinisjonen ligger helt i digna og følger med den.

Hvorfor ODBC¶

Tidligere versjoner lot deg velge mellom en teknologispesifikk driver og ODBC via en Use ODBC-bryter. Fra og med Release 2026.06 bygger digna utelukkende på ODBC. Ett enkelt, standardisert grensesnitt gir deg mer enn en samling spesiallagde drivere kan:

• Autentisering — autentisering er en del av ODBC, så en tilkobling kan bruke alt driveren støtter: passord, tokens og PAT-er, Kerberos og Active Directory, MFA og nettleserbasert single sign-on, skyidentitet, klientsertifikater og TLS. Nye metoder kommer med en driveroppdatering, i stedet for å vente på en ny digna-versjon.
• Drivere vedlikeholdt av databaseleverandørene — leverandørens egen driver følger nye serverversjoner og sikkerhetsrettelser, og du kan oppdatere den etter din egen tidsplan, uavhengig av digna.
• Én måte å konfigurere alt på — alle teknologier er en liste med nøkkel/verdi-egenskaper, med samme grensesnitt, samme kryptering av sensitive verdier og samme feilsøking, i stedet for et eget sett med felter for hver kilde.
• Finjustering og rekkevidde — innstillinger på drivernivå som tidsavbrudd, TLS-innstillinger, proxyer og fetch-størrelser er tilgjengelige for alle kilder, og enhver teknologi med en kompatibel ODBC-driver kan kobles til, også de som digna ikke publiserer en egen veiledning for.

Veiledninger per teknologi¶

Egenskapsnavnene varierer fra driver til driver, og hver teknologi har en eller to detaljer som de andre ikke har. Veiledningene nedenfor dekker den delen; denne siden dekker digna-siden, som er den samme for alle.

Forutsetning: Installer ODBC-driveren på digna-verten¶

digna åpner kildetilkoblinger fra serveren som kjører digna-backend, ikke fra nettleseren. ODBC-driveren må derfor være installert på den maskinen, og navnet dens må være registrert hos den lokale driverbehandleren.

odbcinst -q -d

odbcinst -q -d

I stedet for et registrert navn godtar alle vanlige driverbehandlere også den fullstendige banen til driverbiblioteket, for eksempel Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Det er nyttig når driveren er installert, men ikke registrert.

Opprett en databasetilkobling¶

Åpne Admin Panel, gå til fanen Database Connections og klikk Add DB Connection. Skjermbildet ber om fem ting:

En tilkobling administreres sentralt og tildeles deretter ett eller flere prosjekter, så den samme tilkoblingen kan betjene flere prosjekter.

ODBC-egenskaper¶

Klikk Add Property for hver egenskap, og fyll ut Key, Value og, for hemmeligheter, avkrysningsboksen Encrypted. Hver teknologiveiledning viser et eksempelsett for den aktuelle teknologien, som du tilpasser til driverversjonen og serveren din — se merknaden ovenfor.

Uansett driver dekker et egenskapssett de samme fire tingene:

• Driver — det registrerte drivernavnet, som beskrevet ovenfor.
• Serverens adresse — nøkkelen varierer fra driver til driver: SERVER, HOST, DBCNAME, Server, eller, for Oracle, connect descriptoren i DBQ.
• Legitimasjon — vanligvis UID og PWD; Snowflake bruker UID pluss en token, og Databricks bruker den bokstavelige brukeren token pluss personal access token i PWD.
• Databasen eller katalogen det skal arbeides i, der teknologien har en slik — se Hvilken database tilkoblingen ser.

Alt annet som driveren dokumenterer, kan legges til på samme måte — connection pooling, socket-tidsavbrudd, Kerberos-innstillinger, proxyinnstillinger. digna tolker ikke egenskapene; den sender dem bare videre.

Kryptering av egenskapsverdier¶

Kryss av for Encrypted for hver egenskap som inneholder en hemmelighet — PWD, token, en client secret. Verdien krypteres da før den lagres i digna-repositoriet, maskeres i skjermbildet og dekrypteres først når tilkoblingsstrengen settes sammen.

Egenskaper som ikke er hemmelige — drivernavn, vert, port, database — bør helst være ukrypterte, slik at de forblir lesbare for den som vedlikeholder tilkoblingen senere.

Teste en tilkobling¶

Klikk Test i dialogboksen Add DB Connection før du lagrer. Testen bruker verdiene som står i skjemaet, og utfører en ekte tilkobling, så den rapporterer nøyaktig det en inspeksjon ville støtt på — et feil drivernavn, et avvist passord, en vert som ikke kan nås. Ingenting lagres: testtilkoblingen rulles tilbake enten den lykkes eller mislykkes.

For en tilkobling som allerede finnes, holder du markøren over raden i fanen Database Connections og klikker på plugg-ikonet for å teste den på nytt. Det er den raskeste måten å sjekke om en kilde kan nås etter et passordbytte eller en brannmurendring.

Hvilken database tilkoblingen ser¶

Når du legger til en datakilde, tilbyr digna katalogene, skjemaene og tabellene som tilkoblingen kan nå. Hvor langt det rekker, avhenger av teknologien:

Profiling Mode og Work Schema¶

Profileringsmodusen bestemmer hvordan digna behandler data og beregner metrikker:

• Standard: Metrikker beregnes direkte på kildetabellene uten at dataene kopieres.
• Permanent: Data for den inspiserte dagen kopieres til en permanent tabell, og metrikker beregnes på de kopierte dataene.
• Session: Data kopieres til en sesjonstabell eller midlertidig tabell, og metrikker beregnes på disse midlertidige dataene.

Modusen avgjør hva tilkoblingsbrukeren må ha lov til å gjøre:

Standard leser bare, noe som gjør den til modusen du bør velge når digna får skrivebeskyttet tilgang. Work Schema leses bare ved Permanent, men det lønner seg å fylle det ut likevel, slik at tilkoblingen fortsetter å fungere hvis modusen endres senere.

Bruke en DSN i stedet¶

En DSN fungerer fortsatt — DSN er bare enda en egenskap:

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

DSN-en må være registrert på digna-verten, for den samme brukerkontoen som kjører digna-backend, og som en System DSN når digna kjører som en tjeneste. Alt som er konfigurert i DSN-en, kan overstyres ved også å legge det til som en egenskap.

DSN-løst er den dokumenterte standarden fordi det unngår slik tilstand på verten: tilkoblingen er fullstendig beskrevet i digna, og en ny digna-vert trenger bare at driveren er installert, uten noen konfigurasjon.

Feilsøking¶

Data source name not found / no default driver specified¶

Symptomer: - Test-knappen rapporterer en feil som nevner data source name not found, selv om oppsettet er DSN-løst

Årsaker og løsninger: 1. Driver-verdien samsvarer ikke med et registrert drivernavn — sammenlign den med fanen Drivers i ODBC Data Source Administrator (64-bit), eller med odbcinst -q -d 2. Driveren er installert på arbeidsstasjonen din, men ikke på digna-verten 3. Driveren er 32-biters mens digna er 64-biters — installer 64-biters driveren 4. Egenskapen Driver mangler helt, og ingen DSN er oppgitt heller 5. På Linux og macOS er driveren installert, men ikke registrert — oppgi den fullstendige banen til driverbiblioteket i stedet, eller registrer den i odbcinst.ini

Tilkoblingstesten får tidsavbrudd¶

Symptomer: - Test henger og feiler deretter etter omtrent et halvt minutt

Årsaker og løsninger: 1. Verten eller porten kan ikke nås fra digna-verten — sjekk brannmuren og, for skykilder, IP-tillatelseslisten 2. Vertsnavnet er riktig, men porten tilhører en annen tjeneste 3. Kilden trenger lenger enn standard 30 sekunder for å godta en tilkobling — øk DIGNA_SOURCE_LOGIN_TIMEOUT_SEC i [base]-seksjonen i config.toml (0 venter på ubestemt tid) og start backend på nytt 4. Et serverless-endepunkt våkner fra inaktiv tilstand — prøv igjen, og hvis det skjer jevnlig, øk innloggingstidsavbruddet som beskrevet ovenfor

Autentiseringen feiler selv om legitimasjonen er riktig¶

Symptomer: - Driveren rapporterer ugyldig legitimasjon, men den samme brukeren fungerer i en annen SQL-klient

Årsaker og løsninger: 1. Passordet inneholder ; — sett verdien i krøllparenteser: {p@ss;word} 2. Et avsluttende mellomrom ble kopiert inn i verdien 3. Driveren forventer en bestemt autentiseringsmekanisme — for eksempel AuthMech for Hive- og Databricks-driverne, eller authenticator for Snowflake 4. Verdien ble lagret kryptert og deretter redigert — krypterte verdier kan ikke leses tilbake, så legg inn hemmeligheten på nytt i sin helhet 5. Et token har utløpt — personal access tokens og programmatic access tokens utstedes med en utløpsdato

Datakildeskjermbildet tilbyr ikke forventet database eller skjema¶

Symptomer: - Kataloger, skjemaer eller tabeller mangler når en datakilde legges til

Årsaker og løsninger: 1. Tilkoblingen peker på en annen database — se Hvilken database tilkoblingen ser 2. Tilkoblingsbrukeren mangler lesetilgang til skjemaet eller til datakatalogen (data dictionary) 3. Technology samsvarer ikke med kilden, så digna spør mot feil datakatalog 4. For Snowflake er ingen standard warehouse tildelt brukeren, og ingen Warehouse-egenskap er oppgitt, så metadataspørringer kan ikke kjøres

Profileringen feiler mens tilkoblingstesten lykkes¶

Symptomer: - Test går gjennom, men en inspeksjon feiler når arbeidstabeller opprettes

Årsaker og løsninger: 1. Permanent-profilering er valgt, og tilkoblingsbrukeren kan ikke opprette tabeller i Work Schema — gi rettighetene, eller bytt til Session eller Standard 2. Work Schema er tomt eller angir et skjema som ikke finnes, mens Permanent-profilering er valgt 3. Session-profilering er valgt, og tilkoblingsbrukeren har ikke lov til å opprette midlertidige tabeller 4. En langvarig profileringsspørring når tidsavbruddet for spørringer — øk DIGNA_SOURCE_QUERY_TIMEOUT_SEC i [base]-seksjonen i config.toml (standard 3600 sekunder, 0 slår av tidsavbruddet)

Beste praksis¶

GJØR:

• Installer og registrer driveren på digna-verten før du konfigurerer tilkoblingen
• Kryss av for Encrypted for hvert passord og token
• Klikk Test før du lagrer, og test på nytt etter et passordbytte
• Gi tilkoblinger navn etter kilde og miljø, for eksempel sales_dwh_prod
• Gi digna en egen databasebruker, med skrivebeskyttet tilgang der Standard-profilering er nok
• Ha én tilkobling per kildedatabase, og legg heller til en ny enn å bytte om den første

IKKE:

• Lagre hemmeligheter ukryptert, eller del én databasebruker mellom digna og andre verktøy
• Bruk en 32-biters driver med en 64-biters digna-installasjon
• Stol på en User DSN når digna kjører som en tjeneste — den vil ikke være synlig
• Legg inn en verdi som inneholder ; i en egenskap uten krøllparenteser
• La Work Schema peke på et skjema som inneholder kildedata

Støtte¶

Trenger du hjelp med en databasetilkobling?

• E-post: support@digna.ai
• Dokumentasjon: https://docs.digna.ai
• Nettsted: https://www.digna.ai

Release: 2026.06
© 2026 digna GmbH — www.digna.ai