Μετάβαση στο περιεχόμενο

Επισκόπηση Συνδέσεων Βάσεων Δεδομένων


Πίνακας Περιεχομένων

  1. Πώς Λειτουργούν οι Συνδέσεις
  2. Οδηγοί ανά Τεχνολογία
  3. Προαπαιτούμενο: Εγκατάσταση του ODBC Driver στον Host του digna
  4. Δημιουργία Σύνδεσης Βάσης Δεδομένων
  5. Ιδιότητες ODBC
  6. Κρυπτογράφηση Τιμών Ιδιοτήτων
  7. Δοκιμή Σύνδεσης
  8. Ποια Βάση Δεδομένων Βλέπει η Σύνδεση
  9. Profiling Mode και Work Schema
  10. Χρήση DSN Εναλλακτικά
  11. Αντιμετώπιση Προβλημάτων

Πώς Λειτουργούν οι Συνδέσεις

Το digna προσεγγίζει κάθε τεχνολογία πηγής μέσω ODBC. Μια σύνδεση είναι μια λίστα ιδιοτήτων ODBC που εισάγετε ως ζεύγη κλειδιού/τιμής. Όταν το digna ανοίγει τη σύνδεση, ενώνει αυτά τα ζεύγη σε ένα connection string — Key=Value, χωρισμένα με ;, με τη σειρά που τα καταχωρίσατε — και το παραδίδει στον ODBC driver manager του host του digna.

Το ότι εισάγετε μόνοι σας τις ιδιότητες είναι αυτό που κάνει τη ρύθμιση χωρίς DSN (DSN-less): η σύνδεση περιέχει όλα όσα χρειάζεται ο driver, οπότε δεν χρειάζεται να καταχωριστεί καμία πηγή δεδομένων ODBC (DSN) στον host. Αυτός είναι ο συνιστώμενος τρόπος διαμόρφωσης του digna, επειδή ο ορισμός της σύνδεσης βρίσκεται εξ ολοκλήρου στο digna και μεταφέρεται μαζί του.

Γιατί ODBC

Παλαιότερες εκδόσεις πρόσφεραν επιλογή ανάμεσα σε έναν driver ανά τεχνολογία και στο ODBC, μέσω του διακόπτη Use ODBC. Από το Release 2026.06, το digna βασίζεται αποκλειστικά στο ODBC. Μια ενιαία, τυποποιημένη διεπαφή σας προσφέρει περισσότερα από ένα σύνολο εξειδικευμένων drivers:

  • Αυθεντικοποίηση — η αυθεντικοποίηση είναι μέρος του ODBC, οπότε μια σύνδεση μπορεί να χρησιμοποιήσει ό,τι υποστηρίζει ο driver της: κωδικούς πρόσβασης, tokens και PATs, Kerberos και Active Directory, MFA και single sign-on μέσω browser, cloud identity, πιστοποιητικά πελάτη και TLS. Νέες μέθοδοι έρχονται με μια ενημέρωση του driver, χωρίς αναμονή για νέα έκδοση του digna.
  • Drivers που συντηρούνται από τους κατασκευαστές των βάσεων δεδομένων — ο driver του ίδιου του κατασκευαστή ακολουθεί τις νέες εκδόσεις του server και τις διορθώσεις ασφαλείας, και μπορείτε να τον ενημερώνετε με το δικό σας χρονοδιάγραμμα, ανεξάρτητα από το digna.
  • Ένας τρόπος διαμόρφωσης για όλα — κάθε τεχνολογία είναι μια λίστα ιδιοτήτων κλειδιού/τιμής, με την ίδια διεπαφή, την ίδια κρυπτογράφηση ευαίσθητων τιμών και την ίδια αντιμετώπιση προβλημάτων, αντί για διαφορετικό σύνολο πεδίων ανά πηγή.
  • Ρύθμιση και εμβέλεια — επιλογές σε επίπεδο driver, όπως timeouts, ρυθμίσεις TLS, proxies και fetch sizes, είναι διαθέσιμες για κάθε πηγή, και οποιαδήποτε τεχνολογία με συμβατό ODBC driver μπορεί να συνδεθεί, ακόμη και αυτές για τις οποίες το digna δεν δημοσιεύει ξεχωριστό οδηγό.

Τι άλλαξε στη διεπαφή

Ο διακόπτης Use ODBC και τα ξεχωριστά πεδία host, port, database, user και password δεν υπάρχουν πλέον. Μια σύνδεση που δεν χρησιμοποιεί ήδη ODBC χρειάζεται να εισαχθούν οι ιδιότητες ODBC της για να λειτουργήσει ξανά — δείτε Δημιουργία Σύνδεσης Βάσης Δεδομένων.


Οδηγοί ανά Τεχνολογία

Τα ονόματα των ιδιοτήτων διαφέρουν ανά driver, και κάθε τεχνολογία έχει μία ή δύο λεπτομέρειες που δεν έχουν οι υπόλοιπες. Οι παρακάτω οδηγοί καλύπτουν αυτό το μέρος· αυτή η σελίδα καλύπτει την πλευρά του digna, που είναι ίδια για όλες.

Τα σύνολα ιδιοτήτων στους οδηγούς είναι παραδείγματα

Κάθε οδηγός δείχνει έναν συνδυασμό που είναι γνωστό ότι λειτουργεί — αυτόν με τον οποίο δοκιμάζεται το digna. Είναι σημείο εκκίνησης, όχι προδιαγραφή: οι ιδιότητες ανήκουν στον ODBC driver, και το ποιες υπάρχουν, πώς ονομάζονται και ποιες τιμές δέχονται διαφέρει ανάμεσα σε εκδόσεις driver και κατασκευαστές, ανάμεσα σε Windows, Linux και macOS, και ανάλογα με το πώς είναι διαμορφωμένος ο server πηγής — μέθοδος αυθεντικοποίησης, TLS, gateway, port. Αναμένετε να προσαρμόσετε μία ή δύο τιμές, και θεωρήστε την τεκμηρίωση της έκδοσης driver που εγκαταστήσατε ως την έγκυρη πηγή.

Τεχνολογία Οδηγός Αξίζει να γνωρίζετε
Azure Synapse Analytics Azure Synapse Τα serverless pools χρειάζονται -ondemand στο όνομα του host και υποστηρίζουν μόνο Standard profiling
Databricks Databricks Αυθεντικοποίηση με token: UID=token, PAT στο PWD
Apache Hive Hive Οι catalogs προέρχονται από τον driver, όχι από ένα query
Netezza Netezza Το όνομα του driver γράφεται σε άγκιστρα: {NetezzaSQL}
Oracle Oracle Το DBQ δέχεται είτε πλήρη connect descriptor είτε alias του tnsnames.ora
PostgreSQL PostgreSQL Το SSLMode πρέπει να ταιριάζει με αυτό που απαιτεί ο server
Snowflake Snowflake Το programmatic access token είναι η δοκιμασμένη μέθοδος αυθεντικοποίησης
MS SQL Server MS SQL Server Το DATABASE καθορίζει ποια schemas μπορεί να δει το digna
Teradata Teradata Ο host μπαίνει στο DBCNAME· οι βάσεις δεδομένων λειτουργούν ως schemas

Προαπαιτούμενο: Εγκατάσταση του ODBC Driver στον Host του digna

Το digna ανοίγει τις συνδέσεις πηγών από τον server που εκτελεί το backend του digna, όχι από τον browser. Επομένως ο ODBC driver πρέπει να είναι εγκατεστημένος σε εκείνο το μηχάνημα, και το όνομά του πρέπει να είναι καταχωρισμένο στον τοπικό driver manager.

Εγκαταστήστε τον 64-bit driver του κατασκευαστή, έπειτα ανοίξτε το ODBC Data Source Administrator (64-bit) και μεταβείτε στην καρτέλα Drivers. Τα ονόματα που εμφανίζονται εκεί είναι ακριβώς οι τιμές που μπορείτε να χρησιμοποιήσετε για την ιδιότητα Driver.

Εγκαταστήστε το unixODBC και τον driver του κατασκευαστή, έπειτα εμφανίστε τα καταχωρισμένα ονόματα drivers:

odbcinst -q -d

Τα ονόματα που εμφανίζονται σε αγκύλες είναι οι τιμές που μπορείτε να χρησιμοποιήσετε για την ιδιότητα Driver. Προέρχονται από το /etc/odbcinst.ini (ή από το αρχείο που αναφέρει το odbcinst -j).

Εγκαταστήστε το unixODBC (για παράδειγμα με brew install unixodbc) και τον driver του κατασκευαστή, έπειτα εμφανίστε τα καταχωρισμένα ονόματα drivers:

odbcinst -q -d

Το όνομα του driver πρέπει να ταιριάζει χαρακτήρα προς χαρακτήρα

Το Driver περνά στον driver manager αμετάβλητο. Τα Simba Spark ODBC Driver και Simba Spark ODBC Driver 64 είναι διαφορετικοί drivers για τον driver manager, και ένα όνομα που δεν είναι καταχωρισμένο προκαλεί σφάλμα data source name not found, παρόλο που δεν εμπλέκεται κανένα DSN.

Αντί για καταχωρισμένο όνομα, όλοι οι συνήθεις driver managers δέχονται επίσης την πλήρη διαδρομή προς τη βιβλιοθήκη του driver, για παράδειγμα Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Αυτό είναι χρήσιμο όταν ο driver είναι εγκατεστημένος αλλά όχι καταχωρισμένος.


Δημιουργία Σύνδεσης Βάσης Δεδομένων

Ανοίξτε το Admin Panel, μεταβείτε στην καρτέλα Database Connections και κάντε κλικ στο Add DB Connection. Η οθόνη ζητά πέντε στοιχεία:

Πεδίο Περιγραφή
Name Όνομα της σύνδεσης. Χρησιμοποιείται για την αναφορά στη σύνδεση σε άλλες οθόνες.
Technology Postgres, Oracle, SQL Server, Databricks, Teradata, Netezza, Snowflake ή Hive. Επιλέγει τη διάλεκτο SQL που παράγει το digna, οπότε πρέπει να ταιριάζει με την πηγή — όχι με τον driver. Το Azure Synapse Analytics είναι σύνδεση SQL Server.
ODBC Properties Τα ζεύγη κλειδιού/τιμής που περιγράφονται στις Ιδιότητες ODBC.
Profiling Mode Standard, Permanent ή Session — δείτε Profiling Mode και Work Schema.
Work Schema Schema που περιέχει τους πίνακες εργασίας για το Permanent profiling.

Μια σύνδεση διαχειρίζεται κεντρικά και έπειτα εκχωρείται σε ένα ή περισσότερα έργα, οπότε η ίδια σύνδεση μπορεί να εξυπηρετεί πολλά έργα.


Ιδιότητες ODBC

Κάντε κλικ στο Add Property για κάθε ιδιότητα και συμπληρώστε Key, Value και, για μυστικά, το πλαίσιο ελέγχου Encrypted. Κάθε οδηγός τεχνολογίας παραθέτει ένα παράδειγμα συνόλου για εκείνη την τεχνολογία, το οποίο προσαρμόζετε στην έκδοση του driver και στον server σας — δείτε τη σημείωση παραπάνω.

Όποιος κι αν είναι ο driver, ένα σύνολο ιδιοτήτων καλύπτει τα ίδια τέσσερα στοιχεία:

  • Driver — το καταχωρισμένο όνομα του driver, όπως περιγράφεται παραπάνω.
  • Η διεύθυνση του server — το κλειδί διαφέρει ανά driver: SERVER, HOST, DBCNAME, Server ή, για το Oracle, ο connect descriptor DBQ.
  • Διαπιστευτήρια — συνήθως UID και PWD· το Snowflake χρησιμοποιεί UID μαζί με ένα token, και το Databricks χρησιμοποιεί τον κυριολεκτικό χρήστη token μαζί με το personal access token στο PWD.
  • Η βάση δεδομένων ή ο catalog στον οποίο εργάζεται, όπου η τεχνολογία έχει κάτι τέτοιο — δείτε Ποια Βάση Δεδομένων Βλέπει η Σύνδεση.

Οτιδήποτε άλλο τεκμηριώνει ο driver μπορεί να προστεθεί με τον ίδιο τρόπο — connection pooling, socket timeouts, ρυθμίσεις Kerberos, ρυθμίσεις proxy. Το digna δεν ερμηνεύει τις ιδιότητες· απλώς τις μεταβιβάζει.

Οι τιμές δεν γίνονται escape — βάλτε σε άγκιστρα ό,τι περιέχει ερωτηματικό

Επειδή οι ιδιότητες ενώνονται με ;, μια τιμή που περιέχει η ίδια ; θα χώριζε το connection string σε λάθος σημείο. Περικλείστε τέτοιες τιμές σε άγκιστρα: PWD={p@ss;word}. Το ίδιο ισχύει για τιμές με = ή με αρχικά κενά. Γι' αυτό επίσης ορισμένοι drivers γράφονται κατά σύμβαση σε άγκιστρα, όπως {NetezzaSQL} ή {SnowflakeDSIIDriver}.


Κρυπτογράφηση Τιμών Ιδιοτήτων

Επιλέξτε Encrypted για κάθε ιδιότητα που περιέχει μυστικό — PWD, token, ένα client secret. Η τιμή τότε κρυπτογραφείται πριν αποθηκευτεί στο repository του digna, αποκρύπτεται στην οθόνη και αποκρυπτογραφείται μόνο όταν συντίθεται το connection string.

Συμβουλή

Μια κρυπτογραφημένη τιμή δεν μπορεί να διαβαστεί ξανά, ούτε στο UI ούτε μέσω του API — μπορεί μόνο να αντικατασταθεί. Φυλάσσετε τα μυστικά και στον δικό σας password manager.

Ιδιότητες που δεν είναι μυστικές — το όνομα του driver, ο host, το port, η βάση δεδομένων — είναι προτιμότερο να μένουν μη κρυπτογραφημένες, ώστε να παραμένουν αναγνώσιμες για όποιον συντηρήσει τη σύνδεση αργότερα.


Δοκιμή Σύνδεσης

Κάντε κλικ στο Test στο παράθυρο διαλόγου Add DB Connection πριν την αποθήκευση. Η δοκιμή χρησιμοποιεί τις τιμές που βρίσκονται τη στιγμή εκείνη στη φόρμα και εκτελεί πραγματική σύνδεση, οπότε αναφέρει ακριβώς ό,τι θα συναντούσε ένα inspection — λάθος όνομα driver, κωδικό που απορρίφθηκε, host που δεν είναι προσβάσιμος. Τίποτα δεν αποθηκεύεται: η δοκιμαστική σύνδεση αναιρείται (rollback) είτε πετύχει είτε αποτύχει.

Για μια σύνδεση που υπάρχει ήδη, περάστε τον δείκτη πάνω από τη γραμμή της στην καρτέλα Database Connections και κάντε κλικ στο εικονίδιο plug για να την ξαναδοκιμάσετε. Αυτός είναι ο γρηγορότερος τρόπος να ελέγξετε αν μια πηγή είναι προσβάσιμη μετά από αλλαγή κωδικού ή αλλαγή στο firewall.


Ποια Βάση Δεδομένων Βλέπει η Σύνδεση

Όταν προσθέτετε μια πηγή δεδομένων, το digna προσφέρει τους catalogs, τα schemas και τους πίνακες που μπορεί να προσεγγίσει η σύνδεση. Το εύρος αυτό εξαρτάται από την τεχνολογία:

Τεχνολογία Catalogs που προσφέρονται
PostgreSQL, MS SQL Server, Oracle, Snowflake Μόνο η τρέχουσα βάση δεδομένων της σύνδεσης
Teradata, Netezza, Databricks Όλες οι βάσεις δεδομένων ή οι catalogs που επιτρέπεται να δει ο χρήστης
Hive, Impala Αναφέρονται από τον driver

Μία σύνδεση, μία βάση δεδομένων

Για PostgreSQL, SQL Server, Oracle και Snowflake, οι ιδιότητες πρέπει να δείχνουν στη βάση δεδομένων που περιέχει τα schemas πηγής — DATABASE=…, Database=… ή το service name μέσα στο DBQ του Oracle. Πίνακες σε άλλη βάση δεδομένων δεν είναι προσβάσιμοι μέσω αυτής της σύνδεσης· προσθέστε μια δεύτερη σύνδεση γι' αυτήν.


Profiling Mode και Work Schema

Το profiling mode καθορίζει πώς το digna επεξεργάζεται τα δεδομένα και υπολογίζει τις μετρικές:

  • Standard: Οι μετρικές υπολογίζονται απευθείας στους πίνακες πηγής χωρίς αντιγραφή των δεδομένων.
  • Permanent: Τα δεδομένα της ημέρας που εξετάζεται αντιγράφονται σε έναν μόνιμο πίνακα, και οι μετρικές υπολογίζονται στα αντιγραμμένα δεδομένα.
  • Session: Τα δεδομένα αντιγράφονται σε έναν πίνακα session ή προσωρινό πίνακα, και οι μετρικές υπολογίζονται σε αυτά τα προσωρινά δεδομένα.

Το mode καθορίζει τι πρέπει να επιτρέπεται να κάνει ο χρήστης της σύνδεσης:

Mode Τι γράφει Δικαιώματα που χρειάζεται ο χρήστης της σύνδεσης
Standard τίποτα Ανάγνωση στους πίνακες πηγής
Permanent έναν πίνακα ανά πηγή δεδομένων στο Work Schema Δημιουργία και διαγραφή πινάκων στο Work Schema
Session έναν προσωρινό πίνακα που η βάση δεδομένων διαγράφει μαζί με το session Δημιουργία προσωρινών πινάκων — το Work Schema δεν χρησιμοποιείται

Το Standard μόνο διαβάζει, γι' αυτό είναι το mode που επιλέγετε όταν στο digna παραχωρείται πρόσβαση μόνο ανάγνωσης. Το Work Schema διαβάζεται μόνο για το Permanent, αλλά αξίζει να το συμπληρώσετε ούτως ή άλλως, ώστε η σύνδεση να συνεχίσει να λειτουργεί αν αλλάξει αργότερα το mode.


Χρήση DSN Εναλλακτικά

Ένα DSN εξακολουθεί να λειτουργεί — το DSN είναι απλώς μια ακόμη ιδιότητα:

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

Το DSN πρέπει να είναι καταχωρισμένο στον host του digna, για τον ίδιο λογαριασμό χρήστη που εκτελεί το backend του digna, και ως System DSN όταν το digna εκτελείται ως service. Οτιδήποτε έχει διαμορφωθεί στο DSN μπορεί επίσης να παρακαμφθεί, προσθέτοντάς το ως ιδιότητα.

Η ρύθμιση χωρίς DSN είναι η τεκμηριωμένη προεπιλογή επειδή αποφεύγει αυτή την κατάσταση στην πλευρά του host: η σύνδεση περιγράφεται πλήρως στο digna, και ένας νέος host του digna χρειάζεται μόνο εγκατεστημένο τον driver, χωρίς καμία διαμόρφωση.


Αντιμετώπιση Προβλημάτων

Data source name not found / no default driver specified

Συμπτώματα: - Το κουμπί Test αναφέρει σφάλμα που αναφέρει data source name not found, παρόλο που η ρύθμιση είναι χωρίς DSN

Αιτίες & Λύσεις: 1. Η τιμή του Driver δεν ταιριάζει με καταχωρισμένο όνομα driver — συγκρίνετέ την με την καρτέλα Drivers του ODBC Data Source Administrator (64-bit) ή με το odbcinst -q -d 2. Ο driver είναι εγκατεστημένος στον σταθμό εργασίας σας αλλά όχι στον host του digna 3. Ο driver είναι 32-bit ενώ το digna είναι 64-bit — εγκαταστήστε τον 64-bit driver 4. Η ιδιότητα Driver λείπει εντελώς, και δεν δόθηκε ούτε DSN 5. Σε Linux και macOS, ο driver είναι εγκατεστημένος αλλά όχι καταχωρισμένος — δώστε αντί γι' αυτό την πλήρη διαδρομή προς τη βιβλιοθήκη του driver, ή καταχωρίστε τον στο odbcinst.ini


Η δοκιμή σύνδεσης λήγει λόγω χρονικού ορίου

Συμπτώματα: - Το Test κολλάει και έπειτα αποτυγχάνει μετά από περίπου μισό λεπτό

Αιτίες & Λύσεις: 1. Ο host ή το port δεν είναι προσβάσιμα από τον host του digna — ελέγξτε το firewall και, για πηγές στο cloud, τη λίστα επιτρεπόμενων IP 2. Το όνομα του host είναι σωστό αλλά το port ανήκει σε άλλη υπηρεσία 3. Η πηγή χρειάζεται περισσότερο από τα προεπιλεγμένα 30 δευτερόλεπτα για να δεχτεί σύνδεση — αυξήστε το DIGNA_SOURCE_LOGIN_TIMEOUT_SEC στην ενότητα [base] του config.toml (το 0 σημαίνει αναμονή χωρίς όριο) και επανεκκινήστε το backend 4. Ένα serverless endpoint επανέρχεται από αδράνεια — δοκιμάστε ξανά, και αν συμβαίνει τακτικά, αυξήστε το login timeout όπως παραπάνω


Η αυθεντικοποίηση αποτυγχάνει παρόλο που τα διαπιστευτήρια είναι σωστά

Συμπτώματα: - Ο driver αναφέρει μη έγκυρα διαπιστευτήρια, αλλά ο ίδιος χρήστης λειτουργεί σε άλλον SQL client

Αιτίες & Λύσεις: 1. Ο κωδικός περιέχει ; — περικλείστε την τιμή σε άγκιστρα: {p@ss;word} 2. Αντιγράφηκε ένα κενό στο τέλος της τιμής 3. Ο driver αναμένει συγκεκριμένο μηχανισμό αυθεντικοποίησης — για παράδειγμα AuthMech για τους drivers Hive και Databricks, ή authenticator για το Snowflake 4. Η τιμή αποθηκεύτηκε κρυπτογραφημένη και έπειτα επεξεργάστηκε — οι κρυπτογραφημένες τιμές δεν μπορούν να διαβαστούν ξανά, οπότε εισαγάγετε ξανά ολόκληρο το μυστικό 5. Ένα token έχει λήξει — τα personal access tokens και τα programmatic access tokens εκδίδονται με ημερομηνία λήξης


Η οθόνη πηγής δεδομένων δεν προσφέρει την αναμενόμενη βάση δεδομένων ή το αναμενόμενο schema

Συμπτώματα: - Λείπουν catalogs, schemas ή πίνακες όταν προστίθεται μια πηγή δεδομένων

Αιτίες & Λύσεις: 1. Η σύνδεση δείχνει σε διαφορετική βάση δεδομένων — δείτε Ποια Βάση Δεδομένων Βλέπει η Σύνδεση 2. Ο χρήστης της σύνδεσης δεν έχει δικαιώματα ανάγνωσης στο schema ή στο data dictionary 3. Το Technology δεν ταιριάζει με την πηγή, οπότε το digna κάνει query στο λάθος data dictionary 4. Για το Snowflake, δεν έχει εκχωρηθεί προεπιλεγμένο warehouse στον χρήστη και δεν δόθηκε ιδιότητα Warehouse, οπότε τα queries μεταδεδομένων δεν μπορούν να εκτελεστούν


Το profiling αποτυγχάνει ενώ η δοκιμή σύνδεσης πετυχαίνει

Συμπτώματα: - Το Test περνά, αλλά ένα inspection αποτυγχάνει κατά τη δημιουργία πινάκων εργασίας

Αιτίες & Λύσεις: 1. Έχει επιλεγεί Permanent profiling και ο χρήστης της σύνδεσης δεν μπορεί να δημιουργήσει πίνακες στο Work Schema — παραχωρήστε τα δικαιώματα ή αλλάξτε σε Session ή Standard 2. Το Work Schema είναι κενό ή ονομάζει schema που δεν υπάρχει, ενώ έχει επιλεγεί Permanent profiling 3. Έχει επιλεγεί Session profiling και ο χρήστης της σύνδεσης δεν επιτρέπεται να δημιουργεί προσωρινούς πίνακες 4. Ένα μακροχρόνιο query profiling φτάνει το query timeout — αυξήστε το DIGNA_SOURCE_QUERY_TIMEOUT_SEC στην ενότητα [base] του config.toml (προεπιλογή 3600 δευτερόλεπτα, το 0 απενεργοποιεί το timeout)


Βέλτιστες Πρακτικές

ΚΑΝΤΕ:

  • Εγκαταστήστε και καταχωρίστε τον driver στον host του digna πριν διαμορφώσετε τη σύνδεση
  • Επιλέξτε Encrypted για κάθε κωδικό πρόσβασης και token
  • Κάντε κλικ στο Test πριν την αποθήκευση, και ξαναδοκιμάστε μετά από αλλαγή κωδικού
  • Ονομάστε τις συνδέσεις με βάση την πηγή και το περιβάλλον, για παράδειγμα sales_dwh_prod
  • Δώστε στο digna έναν αποκλειστικό χρήστη βάσης δεδομένων, μόνο ανάγνωσης όπου αρκεί το Standard profiling
  • Κρατήστε μία σύνδεση ανά βάση δεδομένων πηγής, και προσθέστε μια δεύτερη αντί να αλλάζετε την πρώτη

ΜΗΝ ΚΑΝΕΤΕ:

  • Μην αποθηκεύετε μυστικά χωρίς κρυπτογράφηση, και μη μοιράζεστε έναν χρήστη βάσης δεδομένων ανάμεσα στο digna και σε άλλα εργαλεία
  • Μη χρησιμοποιείτε 32-bit driver με εγκατάσταση 64-bit του digna
  • Μη βασίζεστε σε User DSN όταν το digna εκτελείται ως service — δεν θα είναι ορατό
  • Μη βάζετε τιμή που περιέχει ; σε ιδιότητα χωρίς άγκιστρα
  • Μην κατευθύνετε το Work Schema σε schema που περιέχει δεδομένα πηγής

Υποστήριξη

Χρειάζεστε βοήθεια με μια σύνδεση βάσης δεδομένων;

  • Email: support@digna.ai
  • Τεκμηρίωση: https://docs.digna.ai
  • Ιστότοπος: https://www.digna.ai

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