Καλησπέρα και πάλι.

Θα τρελαθώ. Όταν παο να κάνω ένα απλό

SELECT HD_dMeetingDate

FROM dbo.Header

WHERE HD_dMeetingDate LIKE '2%'

στον sql server 2005 δεν μου εμφανίζει αποτέλεσμα ενώ θα έπρεπε. Δεν κάνω κανένα λάθος. Όταν χρησιμοποιώ το like σε άλο πεδιο που ειναι String δεν έχει πρόβλημα κανένα. Το πεδίο HD_dMeetingDate είναι τύπου DateTime και έτσι θα παραμείνει.

Τι γίνεται βοηθήστε μεεεε......

LIKE σε ημερομινιες?xmmmm δεν μου καθεται καλα αυτο....

κοιτα μαλλον αποθηκευοντε η ημερομινιες με αμερικανικη μορφη Μηνας/Μερα/Ετος και οχι Μερα/Μηνας/Ετος και εσυ ψαχνεις παραδειγμα 2/11/2009 αλλα αυτο ειναι αποθηκευμένω μεσα στην βαση 11/2/2009 και καλα κανει δεν σου επιστρεφει αποτελεσματα! λογικο!

εσυ τωρα του ζητας οτι  ημ/νια Αρχίζει με το 2 μπροστα.... αλλα
ετσι για δοκιμη για βαλε '%2%' να δεις τι αποτελεσματα θα σου διξει.

μην ξεγελιεσαι αν βλεπεις στο προγραμμα σου την ημερομινια σε μορφηγ ηη/μμ/εεεε αλλα αποθηκευεται αναποδα στην βαση! πρεπει να ελεξεις τις ρυθμισεις του SQL server σου και του PC σου τα Regional Settings να ειναι ολα ομοια καλητερα.

---

This Business Is Binary. You are a 1 or a 0. Alive or Dead.-

Ακριβώς επειδή δουλεύεις με DateTime ΔΕΝ γίνεται να το χειριστείς σαν να είναι string (να κάνεις δηλαδή LIKE). Εάν θες να πάρεις αποτέλεσμα απο ενα DateTime πεδίο θα πρέπει να χρησιμοποιήσεις datetime functions του SQL Server. Ψάξε λίγο καλύτερα στο google και θα βρεις πάρα πολλά παραδείγματα για το πως μπορείς να το κάνεις.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Johnnyxp64:

LIKE σε ημερομινιες?xmmmm

.....

Είναι λάθος αυτό. Δεν ειναι σωστό να δουλεύεις με LIKE σε DateTime πεδίο.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Όπως είπαν και οι προλαλήσαντες, το like στο date δε κάνει. Από κει και πέρα μπορείς να ρίξεις μια ματιά εδώ

http://victoriayudin.com/2009/03/02/searching-for-strings-in-sql-server-using-like/

Μήπως είναι λάθος το syntax; Το default result που επιστρέφει νομίζω ότι είναι το (ημέρα/μήνας/έτος), πχ. 21/5/2008. Έχεις στη βάση κάποιο record που να αρχίζει η μέρα από "2";

Βρε παιδια τι δεν κανει????

θέλω όλες τις ημερομηνίες που αρχίζουν από 25 όπως 25η μαρτίου.

Και συμφωνήσατε και όλοι.

Το ψάχνω πάντως, ευχαριστώ

Το παλιό καλό DATEPART δεν μας κάνει;

SELECT DATEPART(day, '2008-03-25')

Το παραπάνω γυρνάει 25, οπότε μέσα σε ένα πίνακα είναι υπεραρκετό να βρούμε ημερομηνίες με την ίδια ημέρα. Γενικά με τις ημερομηνίες παίζουμε με το BETWEEN και με το DATEPART. Το LIKE είναι για τα string...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Πρέπει να καταλάβεις ότι ο τελεστής LIKE δουλεύει ΜΟΝΟ με strings. Ένα πεδίο datetime ΔΕΝ είναι string. Μόνο αν το μετατρέψεις εσύ σε string π.χ. με την CAST ή την CONVERT θα γίνει string. Αν το κάνεις όμως αυτό θα έχεις σαν αποτέλεσμα άθλιες επιδόσεις, καθώς ο SQL Server θα αναγκαστεί να ελέγξει μία-μία όλες τις εγγραφές στη βάση, να τις μετατρέψει σε string και μετά να κάνει τη σύγκριση.

Άσε που δεν έχει ΚΑΝ νόημα το LIKE σε ημερομηνία. Με τί συγκρίνεις? Τί είναι το 2? Ημέρα? Μήνας? Χιλιετία? Γιατί θεωρείς ότι αν μετατρέψεις ένα datetime σε string, θα μετατραπεί σε κάποιο format όπου η χιλιετηρία θα είναι στην αρχή?

Αν θέλεις να βρεις όλες τις ημερομηνίες από 1/1/2000 και μετά, γράψε ακριβώς αυτό. Where HD_dMeetingDate >= '20000101'. Η μορφή yyyymmdd μετατρέπεται αυτόματα σε datetime χωρίς να υπάρχει ασάφεια στο ποιό κομμάτι είναι ημερομηνία, μέρα ή μήνας. Η σύγκριση που γίνεται είναι μεταξύ ημερομηνιών και όχι strings. Και επειδή δεν πειράζεις την τιμή του HD_dMeetingDate, ο SQL Server μπορεί να χρησιμοποιήσει άνετα όποιο index υπάρχει σε αυτή τη στήλη αι να σου επιστρέψει γρήγορα τα αποτελέσματα.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Η απάντηση στο πρόβλημά σου είναι να κανεις convert to datetime  πεδίο σου

SELECT HD_dMeetingDate

FROM dbo.Header

WHERE convert(varchar(10),HD_dMeetingDate,103) LIKE '2%'

το παραπάνω convertion μορφοποιεί την ημερομηνία σέ dd/mm/yyyy

έτσι θα σου επιστρέψει όσες ημερομηνίες αρχίζουν από 2

---

Ιωάννης Μανουσάκης

imanos:

Η απάντηση στο πρόβλημά σου είναι να κανεις convert to datetime  πεδίο σου

SELECT HD_dMeetingDate

FROM dbo.Header

WHERE convert(varchar(10),HD_dMeetingDate,103) LIKE '2%'

Ρε παιδιά συγνώμη, αλλα πρωτού ποστάρετε δεν διαβάζετε παραπάνω τι έχουν γράψει οι άλλοι; Έχουμε αναφέρει 15817 λόγους γιατί δεν πρέπει να το κάνουμε αυτό (performance, indexes, locale bugs) και παρόλα αυτά ποστάρετε μια λάθος λύση; Μπορεί να δουλεύει αλλα ΔΕΝ είναι σωστή απο καμιά απολύτως πλευρά.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Κανένας δέν είπε ότι είναι η καλύτερη λύση.

  Όσο για το Performance αυτό έχει σχέση με το πλήθος τών εγγραφών που υπάρχουν στον πίνακα. Πάντως σέ πίνακα με 250000 εγγραφές δέν έκανε ούτε ένα δευτερόλεπτο για να επιστραφούν οι 1500 εγγραφές δεδομένων σε δοκιμή που έχω κάνει (Σημείωση δέν υπήρχε index στο πεδίο της ημερομηνίας).
 
  Γι αυτό αν χρησιμοποιήσουμε τέτοιυ είδους μέθοδο πρέπει πρώτα να ελέγξουμε αν μας κάνει ή θα δημιουργηθεί πρόβλημα και όχι την την απορρίπτουμε συλύβδην).

---

Ιωάννης Μανουσάκης

imanos:

Κανένας δέν είπε ότι είναι η καλύτερη λύση.

  Όσο για το Performance αυτό έχει σχέση με το πλήθος τών εγγραφών που υπάρχουν στον πίνακα. Πάντως σέ πίνακα με 250000 εγγραφές δέν έκανε ούτε ένα δευτερόλεπτο για να επιστραφούν οι 1500 εγγραφές δεδομένων σε δοκιμή που έχω κάνει (Σημείωση δέν υπήρχε index στο πεδίο της ημερομηνίας).
 
  Γι αυτό αν χρησιμοποιήσουμε τέτοιυ είδους μέθοδο πρέπει πρώτα να ελέγξουμε αν μας κάνει ή θα δημιουργηθεί πρόβλημα και όχι την την απορρίπτουμε συλύβδην).

σωστος! πες τα εσυ βρε ιΜανος γιατι εμενα ειχε μαλιασει η γλωσσα μου με το "σωστο" και το "οχι και τοσο σωστο".
Σωστο ειναι οτι μου λυνει το προβλημα,σε ευλογο χρονικο διαστημα, χωρις να μου γεννά άλλα.-
και για τον καθένα διαφέρει αλλά αυτο δεν θα πει οτι ολοι ειναι σκαρτοι και μονο ενας ο "θεος". Respect people Respect!

αμα ειναι να κανει η κοπελα 5 μερες για να φτιαξει μια αναζητηση με τον "απολυτα" σωστο τροπο, καληνυχτα!

---

This Business Is Binary. You are a 1 or a 0. Alive or Dead.-

Δεν πάει έτσι σε καμιά απο τις δύο περιπτώσεις που αναφέρατε. Δεν θα ξανα-αναλύσω γιατί είναι λάθος και δεν πρέπει να γίνεται έτσι και ποια είναι όλα τα προβλήματα που αντιμετωπίζεις, γιατί σίγουρα θα ξεκινήσει flame. Ο τρόπος για να δουλεύεις σωστά με ημερομηνίες δεν είναι το casting σε string. Γι'αυτό είναι DateTime κι όχι string. Το ότι δουλεύει δεν σημαίνει ότι είναι και ο σωστός τρόπος. Και ένα καλώδιο ρεύματος μπορείς απλά να το δέσεις γυμνό με ένα άλλο και το σίδερο να παίζει μια χαρά, αλλά εάν δεν το περάσεις με μονωτική ταινία sooner or later θα πάρεις είτε φωτιά είτε θα πάθεις ηλεκτροπληξία.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

H τεχνική με τη μετατροπή της ημερομηνίας είναι λανθασμένη. Καταρχήν δεν μπορούμε να βγάλουμε συμπεράσματα από εμπειρικές μετρήσεις του τύπου "στο pc μου με X εγγραφές κάνει Y χρόνο". Όταν το ίδιο query το τρέξουν 10 άτομα; Όταν ο server θα τρέχει με μεγάλο φόρτο εργασίας; Αν το query αυτό τρέξει στα πλαίσια ενός transaction και κλειδώσει όλες τις εγγραφές; Εξάλλου, μπορεί να παίζει στη συγκεκριμένη περίπτωση όταν το LIKE είναι "2%" αλλά αν άλλάξουμε και θέλουμε να ψάξουμε ας πούμε για το έτος 2005 και γίνει "______2005" τότε σίγουρα δεν χρησιμοποιούνται τα indexes και γίνεται table scan. Άρα εκτενή κλειδώματα.

Αντί λοιπόν να κατηγορούμε τις σωστές λύσεις ώς "puristic" καλύτερα να θέτουμε ερωτήματα και προπαντώς να μην ξεχνάμε ότι στα πρώτα βήματα, οι προτάσεις που κάνουμε σε αυτούς που ρωτούν γίνονται πολλές φορές τυφλοσούρτης. Αν η maria_papan μάθει να το κάνει με αυτόν τον τρόπο, θα το κάνει πάντοτε έτσι. Έχει διαφορά σε σχέση με έναν έμπειρο developer που επιλέγει να το κάνει έτσι ξέροντας τις παγίδες αλλά το διαλέγει γιατί ξέρει ότι στη συγκεκριμένη περίπτωση δεν θα πέσει σε αυτές.

---

Vir prudens non contra ventum mingit