|
Στοιχεία απο πίνακα σε πίνακα Καλημέρα σε όλα τα παιδιά! Θέλω να φτιάξω ένα γράφημα που να υπολογίζει τις παραγγελίες ανα μήνα. Έχω έναν πίνακα όπου εισάγονται όλα τα στοιχεία μιας παραγγελίας (ημ/νια, ειδος, τιμη κλπ κλπ). Έχω φτιάξει ενα γράφημα επάνω σε αυτόν τον πίνακα, αλλά άν διαγράψεις μια εγγραφή, τροποιποιείται το γραφημα (φυσιολογικό...) Θέλω να φτιάξω έναν πίνακα όπου θα κρατάει τις ημερομηνίες χωρις να επειρεάζεται απο τον αρχικό πίνακα. Δηλ αν διαγράφω μια παραγγελία στον πίνακα Α η ημερομηνία της να παραμένει στον πίνακα Β για να υπολογίζω το σύνολο των παραγγελιών ανα μήνα. Ελπίζω να καταλάβατε...! Ευχαριστώ. |
Δεσποινα καλημερα Μια λυση που θα σου προτεινα εναι να φτιαξεις ενα αντιγραφο του πινακα Α που θα το ονομασεις πινακας Β και κατοπιν ενα ερωτημα προσαρτησης οπου θα ενημερωνεις τον πινακα Β απο τα στοιχεια του πινακα Α ετσι και να διαγραψεις κατι απο τον Α δεν επηρεαζει τον Β. Κατοπιν πανω στο Β δημιουργησε το γραφημα που θελεις και θα εχεις παντα τα σωστα στοιχεια για τις παραγγελίες σου |
Σε ευχαριστώ πολύ Χρήστο! |
Έχω κάνει την αντιγραφή του πίνακα και το ερώτημα προσάρτησης. Κάτι δεν κάνω καλά και οταν εκτελω το ερώτημα μου αντιγράφει όλες τις εγγραφές του πίνακα Α στον Β ξανα και ξανα (κάθε φορά που εκτελώ το ερώτημα). Πώς θα γίνει να εκτελείται το ερώτημα και να μεταφέρονται μόνο οι καινούριες εγγραφές στον πίνακα Β? |
Δέσποινα καλησπέρα Μια λύση που σου προτείνω είναι η παρακάτω : Αντί να καταχωρείς τα δεδομένα σου σε έναν πίνακα και μετά να εκτελείς ερώτημα για να τα πηγαίνεις στον δεύτερο μπορείς να φτιάξεις μια φόρμα να καταχωρείς τα α δεδομένα σου και μετά από κάθε καταχώρηση να έχεις μια εντολή η οποία θα αντιγράφει τα δεδομένα στον δεύτερο πινάκα. Έτσι θα ενημερώνονται αυτόματα και οι δυο πίνακες και θα μπορείς να σβήσεις όσες εγγραφές θέλεις από τον πρώτο πινάκα Αν δεν μπορείς να το κάνεις εσύ στείλε την βάση με τους πίνακες να στο φτιάξω. Δεν είναι παραπάνω από 10 λεπτά δουλειά. Καλή συνέχεια |
1 Συνημμένο(α) Καλημέρα! Δείτε ένα παραδειγματάκι στο παρακάτω συνημμένο όπου οι εγγραφές που δεν έχουν τσεκαριστεί, προσαρτώνται στον πίνακα "tblArchive", κατόπιν τσεκάρονται για να αγνοηθούν και να μην προσαρτηθούν ξανά: Φιλικά Τάσος |
Καλημέρα και από μένα! Με βάση το παράδειγμα του Τάσου, το ζητούμενο μπορεί να επιτευχθεί και με το παρακάτω ερώτημα προσάρτησης: Κώδικας: INSERT INTO tblArchive ( EntryID, EntryValue, EntryValue1 )και στη συνέχεια τις προσαρτά στον πίνακα tblArchive. Οπότε, πριν το άνοιγμα του διαγράμματος, αρκεί η εκτέλεση (προγραμματιστικά) του παραπάνω ερωτήματος. Φιλικά, Γιάννης. |
Παιδιά, σας ευχαριστώ για τις πληροφορίες που μου δώσατε. Θα δοκιμάσω οτι είπατε και αν δεν τα καταφέρω.... Πάλι εδω θα είμαι! και πάλι ευχαριστώ! |
Γεια σας Στον κύριο πίνακα (Α) πέρα από τις καταχωρήσεις νέων εγγραφών και διαγραφών, πιθανόν να γίνονται και διορθώσεις. Κατά την ενημέρωση του πίνακα αρχείου (Β) έχω την εντύπωση ότι η τελευταία περίπτωση (διορθώσεις) δεν αντιμετωπίζεται. Προτείνω εκτός από το ερώτημα προσάρτησης να εκτελείται και ερώτημα ενημέρωσης. Καλό βράδυ. Φιλικά/Γιώργος |
Γεια σας! Με τον τρόπο που εκφράστηκε το ζητούμενο της φίλης μας Δέσποινας, νομίζω ότι δεν χρειάζεται ενημέρωση ή διαγραφή δεδομένων στον πίνακα αρχείο αλλά μόνο προσθήκη (προσάρτηση ή Append). Αυτός είναι και ο λόγος ύπαρξης και χρήσης του πίνακα αρχείου. Καλό βράδυ! Τάσος |
Φίλε Τάσο, μάλλον δεν έγινα αντιληπτός. Φυσικά και δε θα γίνεται καμία επεξεργασία άμεσα από το χρήστη στον πίνακα αρχείο (Β). Ο χρήστης εργάζεται (προσθέτει, διαγράφει και τροποποιεί εγγραφές) στο βασικό πίνακα (Α). Όμως αφού μεταφέρουμε από τον (Α) κάποιες εγγραφές στον πίνακα (Β) και τις σημειώσουμε στον (Α) ως αρχειοθετημένες, ενδέχεται ο χρήστης να τις τροποιήσει (στον Α). Τότε οι εγγραφές αυτές δε θα είναι ίδιες στον (Α) και τον (Β). Για το λόγο αυτό προτείνω την ενημέρωση. Φιλικά/Γιώργος |
Καλησπέρα στην ομάδα! Μετά από μια δεύτερη (και πιο νηφάλια) ματιά, διακρίνω πως το θέμα προσεγγίστηκε λανθασμένα από το πρώτο κιόλας μήνυμα.:worry: Αγαπητή Δέσποινα, είναι πολύ κακή πρακτική να διατηρούμε σε πολλαπλά σημεία δεδομένα τα οποία χρησιμοποιούνται από την εφαρμογή μας. Τα προβλήματα αυτής της τεχνικής, αναδεικνύει και ο καπετάν Γιώργος στο τελευταίο του μήνυμα. Επίσης, η διαγραφή χρήσιμων δεδομένων, οδηγεί σε άγνοια δεδομένων και λανθασμένες αποφάσεις. Μια παραγγελία, δεν είναι τίποτε άλλο από ένα πραγματικό γεγονός που αναμένει την εξέλιξή του. Αυτή μπορεί να είναι ένα γεγονός ακύρωσης, αποστολής, πώλησης, ή ακόμα χειρότερα, επιστροφής. Σε διαφορετικούς πίνακες θα πρέπει να κρατάμε τα στοιχεία κάθε γεγονότος (εξέλιξης) που σχετίζεται με την κάθε παραγγελία και όχι την ίδια την παραγγελία. Κανένα γεγονός δεν θα πρέπει να διαγράφεται από τον πίνακα παραγγελιών αλλά να "εξελίσσεται". Με άλλα λόγια, μια παραγγελία πρέπει να επιδέχεται επεξεργασίας μόνο μέχρι να εμφανιστεί στον πίνακα αποστολών ή ακυρώσεων. Από τη στιγμή που αποσταλεί, μπορεί να εμφανιστεί στον πίνακα επιστροφών μόνο μέσα σε ένα αποδεκτό χρονικό διάστημα (δικαίωμα επιστροφής). Αν μια παραγγελία έχει αποσταλεί και δεν έχει επιστραφεί εντός του αποδεκτού διαστήματος σημαίνει πως έχει καταλήξει σε μια επιτυχημένη πώληση.:victory: Αυτή η φυσική ροή των γεγονότων θα πρέπει να εξασφαλίζεται μέσα από το περιβάλλον χρήστη της εφαρμογής σου. Νομίζω λοιπόν πως ένας τέτοιος σχεδιασμός, θα σου δώσει πολύ μεγαλύτερες δυνατότητες στην ανάλυση των δεδομένων σου, διατηρώντας την ασφάλεια και την ακεραιότητά τους σε πολύ υψηλά επίπεδα. :028: Τέλος, μπορεί να σου κάνω λίγο την καρδιά περιβόλι με τα παραπάνω αλλά πίστεψέ με… να βοηθήσω θέλω.:angel: Φιλικά, Γιάννης. |
Παράθεση:
από τον χρήστη όταν εκείνος κρίνει ότι είναι έτοιμα προς αρχειοθέτηση και όχι περεταίρω επεξεργασία! Αυτό ήταν το ζητούμενο του θέματος. Ο πίνακας Β δεν είναι ο "κλώνος" του πίνακα Α για να καταγράφει τις οποιεσδήποτε αλλαγές του δεύτερου. Αν οι επεξεργασίες ή διαγραφές πρέπει να περνούν και στον πίνακα Β, τότε γιατί να μην γίνονται κατευθείαν στον πίνακα Α; Ποιος ο λόγος ύπαρξης του πίνακα Β; Mε άλλα λόγια θα αρκούσε ένας πίνακας (A). :sneaky2: Πέραν αυτού, θέλω να τονίσω ότι τα προβλήματα που προκύπτουν κατά την ανάπτυξη μια εφαρμογής θα είναι ελάχιστα έως ανύπαρκτα αν προηγουμένως αφιερωθεί ο απαιτούμενος χρόνος για τη σωστή σχεδίαση της. Φιλικά Τάσος |
Καλημέρα Τάσο, αν το ζητούμενο είναι ο πίνακας-αποθήκη (Β) να περιέχει δεδομένα του (Α) συγκεκριμένων χρονικών στιγμών (όταν πατούμε το κουμπί), συμφωνώ απόλυτα. Επειδή όμως δεν ξέρω τι ακριβώς θέλει η Δέσποινα, της προτείνω να διαβάσει προσεκτικά τις απόψεις του Γιάννη. Υ.Γ Γιάννη εκείνο το "καπετάν" είναι υπερβολικό. Το σκέτο Γιώργος είναι μια χαρά. Φιλικά/Γιώργος |
Σε κάναμε και 'Καπετάνιο' :dft010::dft010: |
Αγαπητοί μου, διαβάζοντας προσεκτικά τα λόγια του Γιάννη, ομολογώ πως κάτι τέτοιο τι σκέφτηκα κι εγω. Δηλαδή, να μην διαγράφονται οι παραγγελίες. Απλά όταν έρθει η ώρα της αποστολής, απλά να ολοκληρώνονται σαν εργασία, να μην εμφανιζονται στις ενεργές, απλα να υπάρχουν για οποιαδήποτε χρήση τους. Μια τελευταία ερώτηση γιατι γεννιέται η απορία, πόσες εγγραφές μπορεί να δεχτεί ένας πίνακας? Για πόσο καιρό θα τον γεμίζω εγώ με εγγραφές? Να μην με απασχολεί? |
Καλημέρα Δέσποινα! Στα τοπικά πρότυπα της Access 2007 υπάρχει το αρχείο Northwind 2007 Πρόκειται για ένα παραδειγματικό αρχείο διαχείρισης παραγγελιών. Νομίζω ότι αξίζει τον κόπο να το μελετήσεις. Όσο για το πλήθος των εγγραφών δεν πρέπει να ανησυχείς εκτός και υπερβείς το όριο των 2 GB ανά Access αρχείο που έχει καθορίσει η Microsoft. Φιλικά Τάσος |
| Η ώρα είναι 20:20. |
Ms-Office.gr - ©2000 - 2026, Jelsoft Enterprises Ltd.