καλησπερα. απο το calendar στην asp.net η ημερομηνια βγαινει με τη μορφη ηη/μμ/εεεε αλλα ο sql server 2005 την δεχεται ως μμ/ηη/εεεε οποτε μου βγαζει λαθος. γνωριζετε αν υπαρχει καποια ρυθμιση ή αν υπαρχει κάποιος αλγόριθμος για την μετατροπή?
ευχαριστω

Διάβασε αυτό το αρθράκι... Ελπίζω να σε βοηθήσει.

---

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

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

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

Από το calendar, διαβάζεις την ημερομηνία με την calendar1.SelectedDate (που επιστρέφει DateTime). Για να την κάνεις string που δέχεται ο SQL Server, μετατρέπεις με την date1.ToString("yyyy-MM-dd").

---

Aris

H date1.ToString("yyyy-MM-dd") δεν είναι σίγουρο ότι θα δουλέψει, γιατί μπορεί ο SQL Server να χρησιμοποιεί κάποιο locale που θεωρεί ότι το δεύτερο νούμερο είναι ημέρα αντί για μήνας. Πιο ασφαλές είναι το 'yyyyMMdd', αν και πάλι μπορεί κάποιος να έχει αλλάξει τις ρυθμίσεις του SQL Server.

Γενικά, η μόνη σωστή λύση είναι να ΜΗΝ περνάς τις ημερομηνίες σαν strings αλλά παραμέτρους. Ούτε να αλλάξει κανείς τα setting του Sql Server, ούτε του Client, ούτε να κάνει μετατροπές. Κάθε άλλη περίπτωση σε αφήνει ανοικτό σε bugs, τα οποία συνήθως είναι πολύ δύσκολο να εντοπιστούν. Μερικές φορές μάλιστα ο μόνος τρόπος να καταλάβεις τί έγινε είναι να πας στον πελάτη και να διαπιστώσεις ότι τα settings που έχει είναι διαφορετικά από αυτά που νόμιζες.

Το μόνο που χρειάζεται να γράψει κανείς είναι 2-3 γραμμές παραπάνω, αλλά θα έχει το κεφάλι του ήσυχο. Άσε που ο κώδικας γίνεται πολύ πιο ξεκάθαρος, καθώς δεν μπλέκει κανείς πλέον με ατελείτωτα string concatenations.

---

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

Δεν βλέπω λόγω να μην αλλάξεις SQL Server Settings εφόσον ξέρεις ότι το instance που έχεις φτιάξει απευθύνεται αποκλειστικά και μόνο σε μια (δική σου) εφαρμογή η οποία κρατάει data σε ελληνικά. Για του client ναι συμφωνώ..

---

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

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

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

pkefal wrote:

Δεν βλέπω λόγω να μην αλλάξεις SQL Server Settings εφόσον ξέρεις ότι το instance που έχεις φτιάξει απευθύνεται αποκλειστικά και μόνο σε μια (δική σου) εφαρμογή η οποία κρατάει data σε ελληνικά. Για του client ναι συμφωνώ..

- Εγώ δεν βλέπω κανένα λόγο να το κάνεις

- Μεθαύριο που θα χρειαστεί να μπει μια ακόμη βάση για μια άλλη εφαρμογή τι θα κάνεις; θα σηκώσεις άλλο instance?

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

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

---

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

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

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

ok, απλά έσπασα τα μούτρα μου για να μάθω κάποια πράγματα να μην τα πειράζω. Και σε αυτό με έχεις βοηθήσει πολύ κι εσύ, οπότε ανησύχησα πολύ ...

Σωστός! Κι απο σπασμένα μούτρα, να φανε και οι κότες φίλε μου..

---

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

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

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

Δεν αλλάζεις τα settings γιατί απλά δεν χρειάζεται. Έτσι και γράφεις σωστά τα queries, δεν χρειάζεται να αναρωτιέσαι τί settings έχει ο server.

Είναι πανεύκολο να μπλέξεις αν π.χ. στηθεί λάθος ο server, αν ο πελάτης έχει κι άλλη βάση επάνω, αν θέλει να βάλει μετά κάποια βάση, αν κάνεις εσύ ο ίδιος λάθος στη βιασύνη σου, αν, αν

---

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

Συμφωνώ με τον pkavanos για την χρήση παραμέτρου, είναι η σωστή λύση.

Το format που έγραψα είναι το ODBC std και παίζει για πρόσβαση μέσω ADO, OLE DB, ODBC. Επίσης, το format που δίνει ο pkavanos παίζει, είναι το unseparated string format.

Ακόμα καλύτερα, για 2005, το ISO 8601 (http://msdn2.microsoft.com/en-us/library/ms190977.aspx)

 

---

Aris

Επανέρχομαι στο θέμα, καθώς αυτή τη στιγμή λύνω άλλο ένα bug που έχει να κάνει με λανθασμένες μετατροπές ημερομηνιών. Για τον SQL Server το ODBC date format δεν σημαίνει απολύτως τίποτε αν δωθεί ως απλό string, δηλαδή με τη μορφή '2007-02-01'. Το string αυτό θα μετατραπεί σε ημερομηνία χρησιμοποιώντας το locale του server όπως και σε όλες τις άλλες περιπτώσεις. Αντί για αυτό, θα πρέπει κανείς να γράψει {d '2007-02-01'}, η οποία είναι η πραγματική μορφή του ODBC standard date format. To unseparated string format παίζει πάντα, δηλαδή το '20070201' θα μεταφραστεί πάντα ως 1η Φεβρουαρίου 2007. Αυτά περιγράφονται στο Writing International Transact-SQL Statements

---

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