Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

[Pantelis Koukousoulas]

2013/1/19 Kostas Oikonomou :
> Η κύρια δουλειά αυτής της φόρμας είναι η καταγραφή δεδομένων, τα οποία στη 
> συνέχεια θα
> περάσουν σε στατιστικό πρόγραμμα. Δεν με ενδιαφέρει η αναζήτηση δεδομένων. Ο
> έλεγχος των δεδομένων αν καταχωρήθηκαν σωστά, πριν τη στατιστική ανάλυση θα
> γίνει σε περιβάλλον Calculus.

Αφού δε σε ενδιαφέρει η αναζήτηση η στρατηγική που ανέφερες
φαίνεται αρκετά λογική :)

> Το σημαντικότερο ήταν αυτό που έγινε. Το ξεκαθάρισμα στο γιατί δεν μπορούσα
> να καταχωρήσω δεδομένα και η επιτυχής διόρθωση του αρχείου μου, ως και το
> ότι έμαθα το πως έγινε αυτό.
>
> Πολλές ευχαριστίες

Κανένα πρόβλημα :)

Χαιρετισμούς,
Παντελής
-- 
Ubuntu-gr mailing list
Ubuntu-gr@lists.ubuntu.com

If you do not want to receive any more messages from the ubuntu-gr mailing 
list, please follow this link and choose unsubscribe:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr

Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

[Kostas Oikonomou]

Απο: Pantelis  Koukousoulas 

Προς: Kostas Oikonomou  
Κοιν.: Ubuntu Λίστα ; "us...@el.libreoffice.org" 
 
Στάλθηκε: 11:57 π.μ. Σάββατο, 19 Ιανουαρίου 2013
Θέμα: Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice 
Base
 
2013/1/19 Kostas Oikonomou :
> Το παράδοξο στο αρχείο, είναι ότι υπήρχαν πίνακες με πρωτεύοντα κλειδιά που
> ήταν «Text [VARCHAR]», χωρίς μάλιστα να απαιτείται η αυτόματη εισαγωγή
> δεδομένων! Πιθανό ο όρος για INTEGER να ισχύει για τον τρίτο ή τέταρτο
> πίνακα, ή για κάτι άλλο, που δεν μπορώ να σκεφτώ (δεν είμαι πληροφορικός).

Στο αρχείο που είδα εγώ, τα πεδία με όνομα "ID" που είχαν τύπο Text
δεν ήταν ορισμένα ως πρωτεύοντα κλειδιά (σε όρους γραφικού περιβάλλοντος
δεν υπήρχε "κλειδάκι" στα αριστερά του ID όπως υπάρχει τώρα).
Στους πίνακες που υπήρχε τέτοιο "κλειδάκι" δεν υπήρχε πρόβλημα ως προς
τη λειτουργία της αντίστοιχης φόρμας.

Η απαίτηση το πρωτεύον κλειδί να είναι ντε και καλά INTEGER (δηλαδή
αριθμός) είναι πρόβλημα με το γραφικό περιβάλλον της Base του LibreOffice
δεν είναι κάτι που ισχύει γενικά για τις βάσεις δεδομένων. Οπότε αν κάποιοι
πίνακες δε δημιουργήθηκαν από το γραφικό περιβάλλον της Base αλλά
π.χ., από τη γραμμή εντολών DDL της (ALTER TABLE μπλα μπλα ...)
τότε μια χαρά είναι δυνατόν να υπάρχουν πρωτεύοντα κλειδιά που δεν
είναι INTEGER.

Ελπίζω τώρα να έγινα πιο κατανοητός. Είναι bug του GUI της Base,
όχι γενική απαίτηση στις βάσεις δεδομένων, η γραμμή εντολών SQL
της Base επίσης δουλεύει σωστά.

> Δοκίμασα σε κάποια πρωτεύοντα κλειδιά (αυτά που είχες φτιάξει εσύ) να
> καταργήσω την αυτόματη εισαγωγή δεδομένων, χωρίς να καταργηθεί το πεδίο από
> πρωτεύων κλειδί. Πιθανό στους πίνακες, που αναφέρω πιο πάνω, να είχε οριστεί
> αρχικά το πρωτεύων πεδίο σαν INTEGER και στη συνέχεια να το άλλαξα εγώ, για
> να μπορώ να προσθέτω ότι θέλω (δεν θυμάμαι αν έγινε πράγματι κάτι τέτοιο).

Αν έγινε κάτι τέτοιο αυτό θα μπορούσε να δικαιολογήσει το πρόβλημα.
Το bug είναι τέτοιο ώστε όταν κάποιος αλλάξει τον τύπο του πρωτεύοντος κλειδιού
(έστω "ID") π.χ., σε Text, το εικονίδιο με το κλειδάκι συνεχίζει να
εμφανίζεται αλλά
μόλις σώσεις τον πίνακα και κλείσεις το αντίστοιχο παράθυρο, για κάποιο μυστήριο
λόγο η Base αφαιρεί την ιδιότητα του πρωτεύοντος κλειδιού (κάποιος πανέξυπνος
προγραμματιστής της Sun που πέρασε βάσεις δεδομένων "νύχτα" ευθύνεται γι αυτό
μάλλον :P)

Οπότε μπορεί να άλλαξες τον τύπο του πεδίου, δεν είδες να αλλάζει
τίποτα (συνέχιζε
να δείχνει κλειδάκι) και μετά το έκλεισες και αυτό πίσω από την πλάτη
σου αφαίρεσε
την ιδιότητα "πρωτεύον κλειδί" από το ID το οποίο το κατάλαβες μόνο από τη
συνέπεια που είχε (το ότι κλείδωσαν οι αντίστοιχες φόρμες).

Μη γνωρίζοντας τώρα το τι μπορεί να ευθύνεται για το κλείδωμα των φορμών πού
να πάει ο νους σου ότι μπορεί να φταίει το άλλαγμα του τύπου ενός
πεδίου το οποίο
μάλιστα δεν είδες να έχει και ορατές συνέπειες.

Φαντάζομαι θα έχεις αντιμετωπίσει αρκετά τέτοια περιστατικά στην ιατρική όπου
μια φαινομενικά εντελώς αθώα αλλαγή ή παρέμβαση, που μπορεί μάλιστα
βραχυπρόθεσμα να μην έχει καν ορατά ή μετρήσιμα αποτελέσματα, μακροπρόθεσμα
μπορεί να έχει σημαντικότατες συνέπειες.

> Τέλος, για να μην έχω πρόβλημα, μετέτρεψα όλα τα πρωτεύοντα κλειδιά σε
> INTEGER με αυτόματη εισαγωγή δεδομένων, και πρόσθεσα ένα άλλο πεδίο, με
> τίτλο patient, όπου θα βάζω ένα μοναδικό κωδικό για τον κάθε ασθενή. Στη
> συνέχεια δοκίμασα να ορίσω σχέσεις μεταξύ των πινάκων, με το πεδίο patient
> που θα είναι μοναδικό για κάθε ασθενή, χωρίς επιτυχία. Βγαίνει μήνυμα
> λάθους, στα αγγλικά, που απ' ότι κατάλαβα λέει ότι το πεδίο patient, πρέπει
> να είναι πρωτεύων κλειδί ή να μην έχει διπλές τιμές στον πίνακα (πχ δυο
> τιμές με, ας πούμε, 32). Το πεδίο patient είναι επί του παρόντος «Text
> [VARCHAR]». Πως θα ελέγχει η Base ότι δεν υπάρχουν διπλές τιμές, έτσι που να
> με αφήσει να ορίσω τις σχέσεις; Με την αυτόματη τιμή στο Id, το πρωτεύων
> κλειδί, δεν μπορώ να το χρησιμοποιήσω για τη δημιουργία σχέσης μεταξύ των
> πινάκων.
>
> Ελπίζω να μην σας μπέρδεψα πολύ.

Καθόλου δε μας μπέρδεψες :)

Καταρχήν η αυτόματη τιμή στο ID σε τι σε εμποδίζει από το να το
χρησιμοποιήσεις για τη δημιουργία σχέσης μεταξύ πινάκων; Ίσα-ίσα
που δε χρειάζεται να εφευρίσκεις μοναδικούς κωδικούς για κάθε
ασθενή π.χ., και να σκέφτεσαι αν κάποιο αριθμό τον έχεις
χρησιμοποιήσει ξανά ή όχι.

Το να μην έχει διπλοεγγραφές ένα πεδίο Text δεν είναι πρόβλημα
η base να το ελέγξει. Π.χ., αν ξέρει ότι ως τώρα δεν υπάρχουν
διπλοεγγραφές αρκεί να ελέγχει κάθε νέα καταχώρηση ότι δεν
ταυτίζεται με μια από τις υπάρχουσες.

Αυτό μπορεί να γίνει συγκρίνοντας π.χ., χαρακτήρα προς χαρακτήρα
(φυσικά αυτό είναι πολύ λιγότερο αποδοτικό από το να συγκρίνεις
ακεραίους συνήθως και γι αυτό ο κόσμος προτιμά τα πεδία τύπου
ID να είναι τύπου INTEGER).

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

Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

[Pantelis Koukousoulas]

2013/1/19 Kostas Oikonomou :
> Το παράδοξο στο αρχείο, είναι ότι υπήρχαν πίνακες με πρωτεύοντα κλειδιά που
> ήταν «Text [VARCHAR]», χωρίς μάλιστα να απαιτείται η αυτόματη εισαγωγή
> δεδομένων! Πιθανό ο όρος για INTEGER να ισχύει για τον τρίτο ή τέταρτο
> πίνακα, ή για κάτι άλλο, που δεν μπορώ να σκεφτώ (δεν είμαι πληροφορικός).

Στο αρχείο που είδα εγώ, τα πεδία με όνομα "ID" που είχαν τύπο Text
δεν ήταν ορισμένα ως πρωτεύοντα κλειδιά (σε όρους γραφικού περιβάλλοντος
δεν υπήρχε "κλειδάκι" στα αριστερά του ID όπως υπάρχει τώρα).
Στους πίνακες που υπήρχε τέτοιο "κλειδάκι" δεν υπήρχε πρόβλημα ως προς
τη λειτουργία της αντίστοιχης φόρμας.

Η απαίτηση το πρωτεύον κλειδί να είναι ντε και καλά INTEGER (δηλαδή
αριθμός) είναι πρόβλημα με το γραφικό περιβάλλον της Base του LibreOffice
δεν είναι κάτι που ισχύει γενικά για τις βάσεις δεδομένων. Οπότε αν κάποιοι
πίνακες δε δημιουργήθηκαν από το γραφικό περιβάλλον της Base αλλά
π.χ., από τη γραμμή εντολών DDL της (ALTER TABLE μπλα μπλα ...)
τότε μια χαρά είναι δυνατόν να υπάρχουν πρωτεύοντα κλειδιά που δεν
είναι INTEGER.

Ελπίζω τώρα να έγινα πιο κατανοητός. Είναι bug του GUI της Base,
όχι γενική απαίτηση στις βάσεις δεδομένων, η γραμμή εντολών SQL
της Base επίσης δουλεύει σωστά.

> Δοκίμασα σε κάποια πρωτεύοντα κλειδιά (αυτά που είχες φτιάξει εσύ) να
> καταργήσω την αυτόματη εισαγωγή δεδομένων, χωρίς να καταργηθεί το πεδίο από
> πρωτεύων κλειδί. Πιθανό στους πίνακες, που αναφέρω πιο πάνω, να είχε οριστεί
> αρχικά το πρωτεύων πεδίο σαν INTEGER και στη συνέχεια να το άλλαξα εγώ, για
> να μπορώ να προσθέτω ότι θέλω (δεν θυμάμαι αν έγινε πράγματι κάτι τέτοιο).

Αν έγινε κάτι τέτοιο αυτό θα μπορούσε να δικαιολογήσει το πρόβλημα.
Το bug είναι τέτοιο ώστε όταν κάποιος αλλάξει τον τύπο του πρωτεύοντος κλειδιού
(έστω "ID") π.χ., σε Text, το εικονίδιο με το κλειδάκι συνεχίζει να
εμφανίζεται αλλά
μόλις σώσεις τον πίνακα και κλείσεις το αντίστοιχο παράθυρο, για κάποιο μυστήριο
λόγο η Base αφαιρεί την ιδιότητα του πρωτεύοντος κλειδιού (κάποιος πανέξυπνος
προγραμματιστής της Sun που πέρασε βάσεις δεδομένων "νύχτα" ευθύνεται γι αυτό
μάλλον :P)

Οπότε μπορεί να άλλαξες τον τύπο του πεδίου, δεν είδες να αλλάζει
τίποτα (συνέχιζε
να δείχνει κλειδάκι) και μετά το έκλεισες και αυτό πίσω από την πλάτη
σου αφαίρεσε
την ιδιότητα "πρωτεύον κλειδί" από το ID το οποίο το κατάλαβες μόνο από τη
συνέπεια που είχε (το ότι κλείδωσαν οι αντίστοιχες φόρμες).

Μη γνωρίζοντας τώρα το τι μπορεί να ευθύνεται για το κλείδωμα των φορμών πού
να πάει ο νους σου ότι μπορεί να φταίει το άλλαγμα του τύπου ενός
πεδίου το οποίο
μάλιστα δεν είδες να έχει και ορατές συνέπειες.

Φαντάζομαι θα έχεις αντιμετωπίσει αρκετά τέτοια περιστατικά στην ιατρική όπου
μια φαινομενικά εντελώς αθώα αλλαγή ή παρέμβαση, που μπορεί μάλιστα
βραχυπρόθεσμα να μην έχει καν ορατά ή μετρήσιμα αποτελέσματα, μακροπρόθεσμα
μπορεί να έχει σημαντικότατες συνέπειες.

> Τέλος, για να μην έχω πρόβλημα, μετέτρεψα όλα τα πρωτεύοντα κλειδιά σε
> INTEGER με αυτόματη εισαγωγή δεδομένων, και πρόσθεσα ένα άλλο πεδίο, με
> τίτλο patient, όπου θα βάζω ένα μοναδικό κωδικό για τον κάθε ασθενή. Στη
> συνέχεια δοκίμασα να ορίσω σχέσεις μεταξύ των πινάκων, με το πεδίο patient
> που θα είναι μοναδικό για κάθε ασθενή, χωρίς επιτυχία. Βγαίνει μήνυμα
> λάθους, στα αγγλικά, που απ' ότι κατάλαβα λέει ότι το πεδίο patient, πρέπει
> να είναι πρωτεύων κλειδί ή να μην έχει διπλές τιμές στον πίνακα (πχ δυο
> τιμές με, ας πούμε, 32). Το πεδίο patient είναι επί του παρόντος «Text
> [VARCHAR]». Πως θα ελέγχει η Base ότι δεν υπάρχουν διπλές τιμές, έτσι που να
> με αφήσει να ορίσω τις σχέσεις; Με την αυτόματη τιμή στο Id, το πρωτεύων
> κλειδί, δεν μπορώ να το χρησιμοποιήσω για τη δημιουργία σχέσης μεταξύ των
> πινάκων.
>
> Ελπίζω να μην σας μπέρδεψα πολύ.

Καθόλου δε μας μπέρδεψες :)

Καταρχήν η αυτόματη τιμή στο ID σε τι σε εμποδίζει από το να το
χρησιμοποιήσεις για τη δημιουργία σχέσης μεταξύ πινάκων; Ίσα-ίσα
που δε χρειάζεται να εφευρίσκεις μοναδικούς κωδικούς για κάθε
ασθενή π.χ., και να σκέφτεσαι αν κάποιο αριθμό τον έχεις
χρησιμοποιήσει ξανά ή όχι.

Το να μην έχει διπλοεγγραφές ένα πεδίο Text δεν είναι πρόβλημα
η base να το ελέγξει. Π.χ., αν ξέρει ότι ως τώρα δεν υπάρχουν
διπλοεγγραφές αρκεί να ελέγχει κάθε νέα καταχώρηση ότι δεν
ταυτίζεται με μια από τις υπάρχουσες.

Αυτό μπορεί να γίνει συγκρίνοντας π.χ., χαρακτήρα προς χαρακτήρα
(φυσικά αυτό είναι πολύ λιγότερο αποδοτικό από το να συγκρίνεις
ακεραίους συνήθως και γι αυτό ο κόσμος προτιμά τα πεδία τύπου
ID να είναι τύπου INTEGER).

Οπότε εν κατακλείδι, το σωστό και πρακτικό είναι να κάνεις
σχέσεις μεταξύ πινάκων με βάση το πρωτεύον κλειδί μόνο.
Το ότι το κλειδί αυτό θα είναι αριθμός (και μάλιστα με αυτόματη
αύξηση) δε θα πρέπει να σε αποθαρρύνει με κάποιο τρόπο
από το να το χρησιμοποιήσεις.

Χαιρετισμούς,
Παντελής
-- 
Ubuntu-gr mailing list
Ubuntu-gr@lists.ubuntu.com

If you do not want to receive any more messages from the ubuntu-gr mailing 
list, please follow this link and choose unsubscribe:
https://lists.ubuntu.com/

Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

[Kostas Oikonomou]

Απο: Pantelis  Koukousoulas 

Προς: Kostas Oikonomou  
Κοιν.: Ubuntu Λίστα ; "us...@el.libreoffice.org" 
 
Στάλθηκε: 10:02 μ.μ. Παρασκευή, 18 Ιανουαρίου 2013
Θέμα: Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice 
Base
 
2013/1/18 Kostas Oikonomou :
> Είναι απαραίτητο, στο ID, να προσθέτει το πρόγραμμα κάτι από μόνο του;

Αν μιλήσουμε με όρους θεωρίας σχεσιακών βάσεων δεδομένων τότε σίγουρα όχι,
το μόνο που είναι απαραίτητο είναι να μην υπάρχουν 2 αράδες (rows) με την
ίδια τιμή στο πεδίο που παίζει το ρόλο του πρωτεύοντος κλειδιού (και συνήθως
ονομάζεται ID - υποθέτω ότι όταν λες "ID" εννοείς "πρωτεύον κλειδί").

Δυστυχώς στην πράξη το γραφικό περιβάλλον του Base έχει ένα πρόβλημα
που για να δεχτεί ένα πεδίο ως πρωτεύον κλειδί θέλει να είναι καταρχήν
ντε και καλά τύπου INTEGER (που επίσης δε θα έπρεπε να χρειάζεται)
και κατά δεύτερο λόγο νομίζω και autoincrement (αυτό που λες
"να προσθέτει κάτι από μόνο του").

Το κατά πόσο το "autoincrement" / αυτόματη αύξηση είναι υποχρεωτικό ή όχι
βέβαια να πω την αλήθεια δεν το δοκίμασα ιδιαίτερα οπότε αν θέλεις μπορείς
να δοκιμάσεις εσύ να αφαιρέσεις την ιδιότητα "αυτόματη αύξηση' και να δεις
αν το ID παραμένει πρωτεύον κλειδί ή όχι.

Εν ολίγοις είναι πρόβλημα της Base και γνωστό, απλά δεν έχει βρεθεί ακόμα
τρόπος για να φτιαχτεί (εθελοντικά ή με αμοιβή). Μέχρι να φτιαχτεί, σίγουρα
είσαι αναγκασμένος να συμβιβαστείς με το να είναι το πεδίο "INTEGER"
και πιθανότατα με το να είναι και autoincrement.

> Η διαδικασία που ακολουθώ έχει ως εξής. Ανοίγω την πρώτη φόρμα και καταχωρώ
> τα δεδομένα μου, καταχωρώντας και τον κωδικό του ασθενούς, σαν πρωτεύων
> κλειδί. Αφού τελειώσω από αυτή τη φόρμα, που συνήθως καταγράφει τα δεδομένα
> σε ένα πίνακα, πριν πάω σε κάποια άλλη φόρμα που καταγράφει δεδομένα σε ένα
> άλλο πίνακα, ανοίγω πρώτα τον πίνακα, από τους πίνακες, προσθέτω τον κωδικό
> του ασθενούς-πρωτεύων κλειδί, στο δεύτερο πίνακα. Στη συνέχεια βγαίνω από
> τον πίνακα και ανοίγω την καινούργια φόρμα, που παίρνει και καταγράφει
> δεδομένα σε αυτόν, και προσθέτω τα δεδομένα μου, στην εγγραφή εκείνη που θα
> έχει σαν πρωτεύων κλειδί-κωδικός του ασθενούς που όρισα. Αυτή η αυτόματη
> εισαγωγή αύξοντος αριθμού σαν πρωτεύων κλειδί, με μπερδεύει. Μπορεί στον ένα
> πίνακα ο «α» ασθενείς να έχει πρωτεύων κλειδί «5» και στον άλλο πίνακα, ο
> ίδιος ασθενής να έχει πρωτεύων κλειδί «3».

Όχι αυτό δε θα έπρεπε να συμβαίνει. Βασικά πολύ απλά στη φόρμα που
αντιστοιχεί στον πίνακα στον οποίο το πρωτεύον κλειδί είναι το ID του
ασθενούς δε χρειάζεται να υπάρχει καν πεδίο "ID".

Αν τώρα θες να καταχωρήσεις το ID ενός ασθενή σε μια άλλη φόρμα
(στον πίνακα που αντιστοιχεί η οποία το ID του ασθενή *δεν* είναι
το πρωτεύον κλειδί, π.χ., "Ακτινογραφίες" με πρωτεύον κλειδί
IDακτινογραφίας) τότε πας πρώτα στον πίνακα "Ασθενείς"
και βρίσκεις το ID του ασθενούς που ψάχνεις και μετά το καταχωρείς
στη φόρμα "Ακτινογραφίες".

Κατανοώ ότι φαίνεται λίγο μπερδεμένο οπότε αν  η παραπάνω εξήγηση
δε σε καλύπτει πες μου να το ξαναδιατυπώσω.

> Και μια δεύτερη απορία. Που έκανα λάθος όταν σχεδίασα το αρχείο; Η ερώτηση
> αποσκοπεί στο να αποφύγω το «δις εξ' αμαρτείν».

Το λάθος ήταν ότι για να δουλεύει σωστά η Base (να δουλεύουν οι φόρμες)
χρειάζεται κάθε πίνακας να έχει πρωτεύον κλειδί. Για να δεχτεί τώρα να κάνει
ένα πεδίο πρωτεύον κλειδί θα πρέπει αυτό να είναι τύπου INTEGER και ίσως
και autoincrement.

Στη δική σου περίπτωση είχες 2 πίνακες που δεν είχαν πρωτεύον κλειδί.
Σε αυτούς μάλιστα το πεδίο "ID" δεν είχε τύπο INTEGER αλλά string (VARCHAR)
αν θυμάμαι καλά. Οπότε ακόμα και αν τα είχες ορίσει ως πρωτεύοντα κλειδιά
η Base δεν το είχε δεχτεί αυτό λόγω του γνωστού bug που έχει όπως είπαμε
παραπάνω.

> Και πάλι πολλές ευχαριστίες τόσο για την επιδιόρθωση του αρχείου μου, όσο
> και για το χρόνο σου αλλά και για τη σπαζοκεφαλιά.

Κανένα πρόβλημα :)

Χαιρετισμούς,
Παντελής

Φίλε Παντελή,

Το παράδοξο στο αρχείο, είναι ότι υπήρχαν πίνακες με πρωτεύοντα κλειδιά που 
ήταν «Text [VARCHAR]», χωρίς μάλιστα να απαιτείται η αυτόματη εισαγωγή 
δεδομένων! Πιθανό ο όρος για INTEGER να ισχύει για τον τρίτο ή τέταρτο πίνακα, 
ή για κάτι άλλο, που δεν μπορώ να σκεφτώ (δεν είμαι πληροφορικός).

Δοκίμασα σε κάποια πρωτεύοντα κλειδιά (αυτά που είχες φτιάξει εσύ) να καταργήσω 
την αυτόματη εισαγωγή δεδομένων, χωρίς να καταργηθεί το πεδίο από πρωτεύων 
κλειδί. Πιθανό στους πίνακες, που αναφέρω πιο πάνω, να είχε οριστεί αρχικά το 
πρωτεύων πεδίο σαν INTEGER και στη συνέχεια να το άλλαξα εγώ, για να μπορώ να 
προσθέτω ότι θέλω (δεν θυμάμαι αν έγινε πράγματι κάτι τέτοιο).

Τέλος, για να μην έχω πρόβλημα, μετέτρεψα όλα τα πρωτεύοντα κλειδιά σε INTEGER 
με αυτόματη εισαγωγή δεδομένων, και πρόσθεσα ένα άλλο πεδίο, με τίτλο patient, 
όπου θα βάζω ένα μοναδικό κωδικό για τον κάθε ασθενή. Στη συνέχεια δοκίμασα να 
ορίσω σχέσεις μεταξύ των πιν

Re: (Αλλαγή δικαιωμάτων αρχείου) Πίνακες «μόνο ανάγνωση» στο LibreOffice Base

[Kostas Oikonomou]

Απο: Pantelis  Koukousoulas 

Προς: Kostas Oikonomou  
Κοιν.: Ubuntu Λίστα ; us...@el.libreoffice.org 
Στάλθηκε: 11:53 π.μ. Παρασκευή, 18 Ιανουαρίου 2013
Θέμα: Re: Αλλαγή δικαιωμάτων αρχείου
 
Με συγχωρείς φίλε Κώστα που σε ξέχασα αλλά οι 2 τελευταίες μέρες ήταν
κάπως φορτωμένες ...

Κάνω CC και τη λίστα του LibreOffice καθώς το πρόβλημα είναι ανεξάρτητο
του Ubuntu αλλά είναι σχετικό με τη Base οπότε καλό είναι να μπορούν να
το δουν όλοι οι ενδιαφερόμενοι.

2013/1/16 Kostas Oikonomou :
>Επισυνάπτω την εικόνα όπου φαίνονται τα δικαιώματα μιας βάσης δεδομένων
>LibreOffice Base σε περιβάλλον Ubuntu 12.10 64bit. Δεδομένου ότι μπορώ και
>ανοίγω τη βάση χωρίς να μπορώ να προσθέσω δεδομένα, βρήκα ότι φταίνε τα 
>δικαιώματα της βάσης.
[...]
>προσπάθησα να ανοίξω το αρχείο και από το περιβάλλον των Windows με το 
>LibreOffice,
>και είχε την ίδια ακριβώς συμπεριφορά: άνοιγε χωρίς να με αφήνει να προσθέσω 
>δεδομένα.
[...]
> Ευχαριστώ πολύ για την προσφορά σου να μου φτιάξεις το αρχείο. Δεδομένου ότι
> δεν έχω καταχωρήσει περιστατικά (το αρχείο είναι άδειο, μόνο οι πίνακες και
> οι φόρμες) είναι μικρό, και το επισύναψα στο παρών μήνυμα.

Λοιπόν σε εμένα το αρχείο που έστειλες δεν φάνηκε να έχει κάποιο πρόβλημα
corruption ή lock ή κάτι τέτοιο.

Αυτό που διαπίστωσα ήταν ότι απλά ορισμένοι πίνακες ήταν μόνο για ανάγνωση
στο γραφικό περιβάλλον της Base. Αυτό κατά συνέπεια έκανε και τις αντίστοιχες
φόρμες καταχώρησης μη λειτουργικές (δε με άφηνε να προσθέσω κάτι σε αυτές).

Ο λόγος φαίνεται ότι είναι το γεγονός ότι η Base θέλει υποχρεωτικά ένας πίνακας
να έχει πρωτεύον κλειδί (primary key) και οι πίνακες αυτοί δεν είχαν. Το bug στο
GUI της Base (που είναι γνωστό) είναι ότι δε σε αφήνει γενικά να ορίσεις ένα
πεδίο ως πρωτεύον κλειδί αν ο τύπος του δεν είναι integer (προσπάθησα
να ορίσω τα υπάρχοντα "ID" πεδία ως primary keys και δεν τα δεχόταν).

Αυτό που έκανα λοιπόν ήταν απλά να προσθέσω σε αυτούς τους πίνακες
από ένα επιπλέον Integer πεδίο "ID" το οποίο όρισα ως primary key και
autoincrement και όλα δούλεψαν μια χαρά (δηλ. οι φόρμες τώρα δουλεύουν).

Ρίξε κι εσύ μια ματιά αν θέλεις στο επισυναπτόμενο αρχείο και πες αν
έχεις κάποια επιπλέον απορία.

Χαιρετισμούς,
Παντελής

Φίλε Παντελή,

Σε ευχαριστώ πολύ για τη δουλειά σου στο αρχείο μου. Εκμεταλλεύομαι την 
εισήγηση σου για επίλυση αποριών.

Είναι απαραίτητο, στο ID, να προσθέτει το πρόγραμμα κάτι από μόνο του; Όταν έχω 
πάνω από ένα πίνακα, και θα πρέπει απαραίτητα να ορίσω σχέσεις, θέλω το 
πρωτεύων κλειδί να το ορίζω εγώ. Ο λόγος είναι ότι ποτέ μου δεν τα πήγα καλά με 
τις σχέσεις των πινάκων.

Η διαδικασία που ακολουθώ έχει ως εξής. Ανοίγω την πρώτη φόρμα και καταχωρώ τα 
δεδομένα μου, καταχωρώντας και τον κωδικό του ασθενούς, σαν πρωτεύων κλειδί. 
Αφού τελειώσω από αυτή τη φόρμα, που συνήθως καταγράφει τα δεδομένα σε ένα 
πίνακα, πριν πάω σε κάποια άλλη φόρμα που καταγράφει δεδομένα σε ένα άλλο 
πίνακα, ανοίγω πρώτα τον πίνακα, από τους πίνακες, προσθέτω τον κωδικό του 
ασθενούς-πρωτεύων κλειδί, στο δεύτερο πίνακα. Στη συνέχεια βγαίνω από τον 
πίνακα και ανοίγω την καινούργια φόρμα, που παίρνει και καταγράφει δεδομένα σε
 αυτόν, και προσθέτω τα δεδομένα μου, στην εγγραφή εκείνη που θα έχει σαν 
πρωτεύων κλειδί-κωδικός του ασθενούς που όρισα. Αυτή η αυτόματη εισαγωγή 
αύξοντος αριθμού σαν πρωτεύων κλειδί, με μπερδεύει. Μπορεί στον ένα πίνακα ο 
«α» ασθενείς να έχει πρωτεύων κλειδί «5» και στον άλλο πίνακα, ο ίδιος ασθενής 
να έχει πρωτεύων κλειδί «3».

Και μια δεύτερη απορία. Που έκανα λάθος όταν σχεδίασα το αρχείο; Η ερώτηση 
αποσκοπεί στο να αποφύγω το «δις εξ' αμαρτείν».

Και πάλι πολλές ευχαριστίες τόσο για την επιδιόρθωση του αρχείου μου, όσο και 
για το χρόνο σου αλλά και για τη σπαζοκεφαλιά.

Φιλικά

Κώστας Οικονόμου
-- next part --
An HTML attachment was scrubbed...
URL: 

-- 
Ubuntu-gr mailing list
Ubuntu-gr@lists.ubuntu.com

If you do not want to receive any more messages from the ubuntu-gr mailing 
list, please follow this link and choose unsubscribe:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr